[cabfpub] More changes to proposed policy update

[Ryan Hurst]

I agree with Chris and others on this topic.

The intent of a standard is to document the desired end state, only sometimes do they bother themselves with the transition problem (which is why so many never really get fully deployed IMHO).

In this case the only downside of doing this is not complying with a clause in some document, the upside is materially reducing the risk of those that rely on us.

We are actively moving our customers to this model.

Ryan

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer
Sent: Thursday, May 24, 2012 1:38 PM
To: 王文正
Cc: public at cabforum.org
Subject: Re: [cabfpub] More changes to proposed policy update

On Thu, May 24, 2012 at 6:42 AM, 王文正 <wcwang at cht.com.tw> wrote:

> For the criticality of the Name Constraints extension, the text in the 
> ITU-T X.509 standard reads "It is recommended that it be flagged critical; otherwise, a certificate user may not check that subsequent certificates in a certification path are located in the constrained name spaces intended by the issuing CA."

Sure, but otherwise-acceptable certificate chains fail in some clients when the client sees critical fields it doesn't understand. That effectively stops us from deploying name-constrained certificates without an Internet Flag Day where everyone fixes their clients. Since that is not going to happen, the way to get incremental improvement is to allow non-critical name constraints, and for the vendors of smart clients to enforce them where present.

That is, to smart clients they will be effectively critical, but dumb clients at least won't explode. That's not ideal, but it is significantly Better Than Nothing. Name constraints are so wonderfully good that it's still very nice to get their benefits in some clients, even if not in all clients.

So Google would most likely vote for it and implement it.


--
If it's not safe, is it really usable?
_______________________________________________
Public mailing list
Public at cabforum.org
http://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4276 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120524/6510f762/attachment-0002.p7s>