[cabfpub] More changes to proposed policy update

[Rich Smith]

Wen-Cheng,
I think if you see Phillip's post on this from April 4, pasted below, you will better understand the reasoning behind this:

"The Criticality Flag is actually mis-named. It does not mean 'important', it should be called the 'Compatibility flag'.

If a client processes the NC extension it is obliged to either process the extension or reject the cert regardless of whether the flag is set or not. 
The criticality flag does not affect the semantics of an extension, the sole and only purpose is to break backwards compatibility."

Currently no one is willing to break backward compatibility because it would adversely affect too many end users.  In simple terms, allowing name constraints to be set non-critical for the short term will allow them to be used and the client software that supports them will process them and those which don't support them will simply ignore them.  However if they are set critical, there is no change from the stand point of the clients that do support them, however for the clients that do not support them, any certificates containing them will fail.  

The alternatives currently available are:

Allow them to be set non-critical, and the clients which support them get the benefit, those that don't behave the same as they would if name constraints were not present, OR;

Don't allow them to be set non-critical, which will mean that they won't be used at all until such time as a critical mass of clients support them.  If no one is actually using them, supporting them will likely not be seen as a high priority by the vendors who don't currently support them, so they may never be added and that critical mass may never be reached.

-Rich

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of ???
> Sent: Friday, May 25, 2012 6:43 AM
> To: Ryan Hurst; 'Chris Palmer'
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] More changes to proposed policy update
> 
> I do not get the logic here.
> 
> Since the purpose of adding the Name Constraints extension is to
> technically constrain the name space the externally-operated
> subordinate CA is allowed to issue subsequent certificates, I do not
> see how this purpose can be accomplished if we allow clients to ignore
> the Name Constraints extension (by marking it non-critical).
> 
> To those smart clients, marking the Name Constraints extension critical
> cause no problem because that extension is recognized. To those dumb
> clients, if they do not understand the meaning of the Name Constraints
> extension, it is dangerous for them to blindly accept the certificate.
> It comes naturally that those dumb clients should reject constrained
> certificate they do not understand. I do not see why allowing clients
> to blindly accept certificates which may be out of the allowed name
> space can materially reduce the risk of those that rely on us.
> 
> I do not oppose the use of the Name Constraints extension, but I want
> that extension to be used in the correct way.
> 
> Wen-Cheng Wang
> 
> -----Original Message-----
> From: Ryan Hurst [mailto:ryan.hurst at globalsign.com]
> Sent: Friday, May 25, 2012 6:15 AM
> To: 'Chris Palmer'; 王文正
> Cc: public at cabforum.org
> Subject: RE: [cabfpub] More changes to proposed policy update
> 
> 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
> _______________________________________________
> 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/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
Url : http://cabforum.org/pipermail/public/attachments/20120525/6308d7a8/attachment-0001.bin