[cabfpub] More changes to proposed policy update

Fri May 25 14:44:35 UTC 2012

Unfortunately not 100% of browsers or email clients support enforcing name constraints, with that they all support honoring the  <http://www.ietf.org/rfc/rfc3280.txt> RFC 3280 behavior for critical extensions (see section 4.2), which states:

A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize

This means by marking the Name Constraints extension Critical those implementations that do not support the concept will “fail-closed”. While this does mean that a certificate issued by a constrained CA may not work in some limited cases where it might have otherwise, it does mean that it can be used as a secure mechanism to restrict the damage that can happen if that CA is compromised.

With that said, support for name constraints is actually quite good as the following table illustrates.

Honor Criticality

Support Basic Constraints 

Supports DNS Name Constraints

Supports RFC 822 Name Constraints

Supports Policy Constraints

Supports constrained EKU

Successfully enforces

IE [1]

Yes

Yes

Yes

N/A

Yes

Yes

Yes (Open)

Outlook1

Yes

Yes

Yes

Yes

Yes

Yes

Yes (Open)

Firefox1

Yes

Yes

Yes

Yes

Yes

No

Yes (Open)

Thunderbird1

Yes

Yes

Yes

Yes

Yes

Yes

Yes (Open)

Opera1

Yes

Yes

No[2]

No2

No2

Yes (SSL only) [3]

Yes (Closed)

Windows / Safari1

Yes

Yes

Yes

Yes

Yes

Yes

Yes (Open)

OSX / Safari[4]

Yes

Yes

No[5]

No5

No5

No

Yes (Closed)

What this table shows is:

1.    It is possible to rely on the name constraints extension as an effective enforcement technique if the extension is marked as critical.

2.    It is possible to rely on the Basic Constraints extension as an effective enforcement technique.

3.    In the case of Safari and Opera that this success is due to these browsers support of honoring the semantics for critical extensions vs. understanding the constraints.

For customers this means if you must interoperate with Opera or Safari the use of a certificate with a “Critical” “Name Constraints extension” in it will result in the certificate chain looking invalid; Thankfully according to  <http://gs.statcounter.com> StatCounter these represent less than 6% of all browsers on the Internet and antidotal evidence shows almost no use in the enterprise.

[1] Tests on Windows were completed with Windows 7, IE 9.0, Outlook 2007, Safari 5.05, Opera 11.61, Firefox/Thunderbird 10.0.2.

2  <http://www.openssl.org> OpenSSL supports name constraints for both name forms as well as policy constraints, Opera has chosen not to enable thee capabilities until demand was present. This work was done in OpenSSL in 2008 as part of a contract to Google.

3 Opera uses  <http://www.openssl.org> OpenSSL which supports restricting a CA from issuing valid SSL server certificates if it’s parent did not place the SSL EKU  in it’s certificate.

4 Tests on OSX were completed with Lion and Safari 5.05

5 Safari on the Mac uses the PKITS <http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html>  tests so they are aware of the deficiency in their validation logic, they have not publically stated they will support them but we expect support in the future.

-----Original Message-----
From: Bruce Morton [mailto:bruce.morton at entrust.com] 
Sent: Friday, May 25, 2012 7:24 AM
To: '???'; 'Rob Stradling'; 'Ryan Hurst'; 'Steve Roylance'; 'Chris Palmer'
Cc: 'public at cabforum.org'
Subject: RE: [cabfpub] More changes to proposed policy update

Does anyone know what major browsers/operating systems will properly support non-critical Name Constraints?

Thanks, Bruce.

-----Original Message-----

From:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org  <mailto:[mailto:public-bounces at cabforum.org]> [mailto:public-bounces at cabforum.org] On Behalf Of ???

Sent: Friday, May 25, 2012 9:42 AM

To: Rob Stradling; Ryan Hurst; Steve Roylance; 'Chris Palmer'

Cc:  <mailto:public at cabforum.org> public at cabforum.org

Subject: Re: [cabfpub] More changes to proposed policy update

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:[mailto:rob.stradling at comodo.com]> [mailto:rob.stradling at comodo.com]

Sent: Friday, May 25, 2012 7:12 PM

To: 王文正

Cc: Ryan Hurst; 'Chris Palmer';  <mailto:public at cabforum.org> 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:[mailto:ryan.hurst at globalsign.com]> [mailto:ryan.hurst at globalsign.com]

> Sent: Friday, May 25, 2012 6:15 AM

> To: 'Chris Palmer'; 王文正

> Cc:  <mailto:public at cabforum.org> 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:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org  <mailto:[mailto: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:  <mailto:public at cabforum.org> public at cabforum.org

> Subject: Re: [cabfpub] More changes to proposed policy update

> 

> On Thu, May 24, 2012 at 6:42 AM, 王文正< <mailto:wcwang at cht.com.tw> 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

>  <mailto:Public at cabforum.org> Public at cabforum.org

>  <http://cabforum.org/mailman/listinfo/public> http://cabforum.org/mailman/listinfo/public

> _______________________________________________

> Public mailing list

>  <mailto:Public at cabforum.org> Public at cabforum.org

>  <http://cabforum.org/mailman/listinfo/public> 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

 <http://www.comodo.com> 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.

_______________________________________________

Public mailing list

 <mailto:Public at cabforum.org> Public at cabforum.org

 <http://cabforum.org/mailman/listinfo/public> http://cabforum.org/mailman/listinfo/public

  _____  

[1] Tests on Windows were completed with Windows 7, IE 9.0, Outlook 2007, Safari 5.05, Opera 11.61, Firefox/Thunderbird 10.0.2.

[2]  <http://www.openssl.org> OpenSSL supports name constraints for both name forms as well as policy constraints, Opera has chosen not to enable thee capabilities until demand was present. This work was done in OpenSSL in 2008 as part of a contract to Google.

[3] Opera uses  <http://www.openssl.org> OpenSSL which supports restricting a CA from issuing valid SSL server certificates if it’s parent did not place the SSL EKU  in it’s certificate.

[4] Tests on OSX were completed with Lion and Safari 5.05

[5] Safari on the Mac uses the  <http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html> PKITS tests so they are aware of the deficiency in their validation logic, they have not publically stated they will support them but we expect support in the future.

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