[cabfpub] More changes to proposed policy update

Fri May 25 18:15:02 UTC 2012

In environments where such clients exist you can go through the work and
costs to :

1)      Fix/replace such clients

2)      Use a private (non-public) CA

3)      Meet the full requirements of a public CA.

Are you aware of such clients? Do they represent a statistically significant
% of the clients on the internet?

Ryan

From: 王文正 [mailto:wcwang at cht.com.tw] 
Sent: Friday, May 25, 2012 10:33 AM
To: Rob Stradling
Cc: Ryan Hurst; Steve Roylance; 'Chris Palmer'; public at cabforum.org
Subject: RE: [cabfpub] More changes to proposed policy update

Rob,

Believe it or not. Even the Name Constraints extension is marked
non-critical, there still exist dumb clients that will explode when
encountering it.

Dumb clients might explode simply because they never saw this kind of
extensions rather than because they are marked critical.

In that situations, what can you do?

Currently, if major browsers/operating systems all can live peacefully with
"Critical" Name Constraints extensions, why bother making the BR
inconsistent with RFC5280?

Wen-Cheng Wang

  _____  

From: Rob Stradling [rob.stradling at comodo.com]
Sent: Friday, May 25, 2012 9:56 PM
To: 王文正
Cc: Ryan Hurst; Steve Roylance; 'Chris Palmer'; public at cabforum.org
Subject: Re: [cabfpub] More changes to proposed policy update

On 25/05/12 14:41, 王文正 wrote:
<snip>
 > On the contrary, I think marking the Name Constraints extension
 > critical is the way to provide the motive power. If dumb clients
 > explode, their users will ask the implementers to support it.

I don't think that that is what would happen.  I think the actual 
scenario would be closer to this...

Dumb client explodes when encountering a Critical Name Constraints 
extension.  User complains to the Certificate Holder that the 
certificate is broken.  Certificate Holder complains to the CA.  CA 
blames the dumb client software, but neither the Certificate Holder nor 
the User accepts this explanation (even though the explanation is 
correct!)  Certificate Holder asks for a refund and then obtains a new 
certificate from a different CA that doesn't use the Name Constraints 
extension.  Very quickly every CA realizes that it is not commercially 
viable to use Critical Name Constraints.  Back to square one.

On 25/05/12 14:41, 王文正 wrote:
> Dear Rob, Steve, Ryan and Chris,
>
> Thank you all for your patience in explain your logic.
>
> Now I understand your rationale goes like this: If we turn the Name
Constraints extension into an 'informative' extension first by marking it
non-critical, hopefully it will become a real constraint-type extension in
the end.
>
> Making it as an informative extension is better than nothing. Maybe you
are right. However, my guess is it will stay as an informative extension
forever. I do not believe allowing the non-critical Name Constraints
extension can help pushing the world to reach the desired end state (I mean
all clients become supporting the critical Name Constraints extension.).
Since it is non-critical, it will not provide the motive power to push those
dumb clients to change themselves because they can simply ignore it. On the
contrary, I think marking the Name Constraints extension critical is the way
to provide the motive power. If dumb clients explode, their users will ask
the implementers to support it. Otherwise, the users will switch to more
smart clients. I do understand that if we goes this way, the process to
reach the desired end state might be bloody. If your goal is to reach the
desired end state, this is the way that can really accelerate the process.
>
> If the forum finally decide to approve the motion of allowing non-critical
Name Constraints extension, then we should ask ourselves a question: when
will we turn back to change the BR to require marking the Name Constraints
extension as critical? Until 100% of clients become smart? Or 95% (whatever)
is acceptable? Can we really reach the so-called "desired end state" in this
way?
>
> Wen-Cheng Wang
>
> -----Original Message-----
> From: Rob Stradling [mailto:rob.stradling at comodo.com]
> Sent: Friday, May 25, 2012 7:12 PM
> To: 王文正
> Cc: Ryan Hurst; 'Chris Palmer'; public at cabforum.org
> Subject: Re: [cabfpub] More changes to proposed policy update
>
> On 25/05/12 11:43, 王文正 wrote:
>> I do not get the logic here.
>
> I think Ryan's post explained the logic clearly and succinctly.
>
> You're looking only at the "desired end state".  Please consider the
"transition problem".
>
> Security versus Usability.  If we can't ever Use it in practice, we won't
ever benefit from the Security it offers.
>
> Today, Critical Name Constraints are considered undeployable by many CAs,
because too much relying party software would break.  Therefore, using the
Name Constraints extension _at all_ is not an option for us.
>
> Non-critical Name Constraints are better than No Name Constraints!
>
> The "desired end state" is...
> 1. Name Constraints always Critical.
> 2. Name Constraints actually used!
>
> If you can suggest an alternative way to solve the "transition problem"
> so that we can reach the "desired end state", we would love to hear it!
>
> Nobody is suggesting that CAs should be prohibited from setting the Name
Constraints extension to Critical.  All we are saying is that CAs should be
allowed to use non-critical Name Constraints instead of No Name Constraints
at all.
>
>> 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
>
> --
> Rob Stradling
> Senior Research&  Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com <http://www.comodo.com/> 
>
> COMODO CA Limited, Registered in England No. 04058690 Registered Office:
>     3rd Floor, 26 Office Village, Exchange Quay,
>     Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to this
email may be monitored by COMODO for operational or business reasons. Whilst
every endeavour is taken to ensure that e-mails are free from viruses, no
liability can be accepted and the recipient is requested to use their own
virus checking software.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com <http://www.comodo.com/> 

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120525/b8a83256/attachment-0004.html>
-------------- 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/20120525/b8a83256/attachment-0002.p7s>