Subject: Re: [pkix] Way Forward: Name Constraints Criticality

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 1 Jun 2012 13:09:58 +0000

On 5/31/12 12:30 PM, "Adam Langley" <[email-masked]> wrote:

>On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J. <[email-masked]>
>wrote:
>> I guess I just don't see why you'd include NC in a cert but *not* mark
>>it
>> critical.  Non-critical NC basically says "Beyond this point you should
>> {only see/never see} the following names, but we don't actually care if
>> you pay attention."
>
>The alternative is an intermediate CA certificate without any Name
>Constraints at all. By including non-critical Name Constraints the
>world benefits from fewer, all-powerful certificates as most clients
>will enforce them. However, given the size of the Internet these days,
>we can't reasonably deploy things that cause significant breakage.
>
>This is not ideal. Ideally we wouldn't start from where we are but,
>given that we have to, I believe that this is a positive step.

If NC is always critical, a conforming implementation that omits NC
processing will throw errors.  Implementors will have concrete incentives
to fix this.

Non-critical NC permits implementations to omit NC processing and still be
conforming.  The incentive to fix this is what, exactly?

I fail to see how this is "a positive step" but maybe that's just me.

-- T

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 15:31:11 +0200 (CEST)

> processing will throw errors.  Implementors will have concrete incentives

About as reasonable as switching off the IPv4 internet today in order
to incentivize the use of IPv6, or blocking of port 80 on internet backbone
routers to incentivize the use of "HTTP-over-TLS".

> conforming.  The incentive to fix this is what, exactly?

Not implementing NC processing is *fully* conforming.

> I fail to see how this is "a positive step" but maybe that's just me.

It would create a much higher market demand for a feature (NC processing)
without instantly breaking the installed base.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Fri, 01 Jun 2012 14:31:59 +0100

On 01/06/12 14:09, Miller, Timothy J. wrote:
> On 5/31/12 12:30 PM, "Adam Langley"<[email-masked]>  wrote:
>
>> On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J.<[email-masked]>
>> wrote:

Implementors will have concrete incentives to fix this *if* they 
actually ever encounter any certificates that contain Critical Name 
Constraints!

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

-- 
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

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.

---

From: Carl Wallace <[email-masked]>
Date: Fri, 01 Jun 2012 09:37:10 -0400

On 6/1/12 9:09 AM, "Miller, Timothy J." <[email-masked]> wrote:
>conforming. 

No, it does not.  A path validation implementation that does not support
name constraints is non-conformant whether the extension is required to be
critical or not.  The proposed change allows CAs to generate certificates
that contain name constraints extensions that will be ignored by
non-conforming implementations that do not support name constraints.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 1 Jun 2012 13:50:35 +0000

>without instantly breaking the installed base.

Really?  How?  Fairy dust?  Non-critical NCs will throw no errors in all
implementations (conforming or not).  How will *anyone* know to pressure
the implementor to add NC processing?

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 1 Jun 2012 13:57:01 +0000

On 6/1/12 8:37 AM, "Carl Wallace" <[email-masked]> wrote:

>critical or not.  

Fair enough.  Edit to read "otherwise conforming."  :)

>The proposed change allows CAs to generate certificates

Of course, non-conformant implementations can ignore critical NCs as
easily as non-critical NCs, so I still don't really see why a change is
needed.

-- T

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 16:30:57 +0200 (CEST)

> the implementor to add NC processing?

When Apples i/OS ignored the BasicConstraint "cA=TRUE", and this fact
was publicly reported as being a security problem, it did result
in a fairly quick change of the implementation -- without breaking
any of the installed base.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Fri, 1 Jun 2012 17:45:54 +0300

> processing will throw errors.  Implementors will have concrete incentives

If the only non-supporting implementation was, say, iCab for Mac or even Opera, you would be right.

As it's the default browser on iPhone, people won't say "the iPhone is broken because it doesn't work with this site", but "this site is broken because it doesn't work with iPhone".

The perception of which one is broken does not depend on compliance with some RFC, and perception drives the incentives to fix this.

Now if there were a lot of websites that would be broken, then people would blame the iPhone, but this NC feature is for corporate sub-CAs issuing certificates for (mostly) intranet websites. I don't see the pressure going in Apple's direction.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Jun 2012 12:51:22 -0400

In the parlance that has become fashionable. Legacy Android and Safari are
too big to fail. We cannot issue certs that are incompatible with the
deployed base, Apple has no incentive to deploy code that checks NCs that
will never appear in issued certs.

If you want NCs implemented, the only way to do that is either (1) to make
it possible for CAs to start issuing them now and then persuade Apple to
take advantage of a control that is already being implemented in deployed
certs or (2) persuade them that they would like to provide native support
for bridge CA in Safari.

The CAs cannot lead the market in technical standards in the way you seem
to think. We can't even shut off SHA1 or RSA1024 without going through a
huge amount of hassle.

We can tell people what we think they SHOULD do but we can't force them to
do that by refusing to issue certs that support their products.

-- 
Website: http://hallambaker.com/

---

From: Michael StJohns <[email-masked]>
Date: Fri, 01 Jun 2012 14:52:33 -0400

>As it's the default browser on iPhone, people won't say "the iPhone is broken because it doesn't work with this site", but "this site is broken because it doesn't work with iPhone".

There are plenty of sites that are broken with respect to the iPhone - the ones that have FLASH instead of Quicktime or HTML5.

Please don't use the iPhone as an excuse here.

And I was told a while back that the uptake for iPhone patches is near 100% within 2 weeks of release. So if enough things break maybe Apple will "do the right thing" quickly.

Mike

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 01 Jun 2012 21:15:57 +0200

On Fri, 01 Jun 2012 20:52:33 +0200, Michael StJohns <[email-masked]>  
wrote:

>> As it's the default browser on iPhone, people won't say "the iPhone is  
>> broken because it doesn't work with this site", but "this site is  
>> broken because it doesn't work with iPhone".
>
>
> There are plenty of sites that are broken with respect to the iPhone -  
> the ones that have FLASH instead of Quicktime or HTML5.

I think there is a "slight" difference between a *site operator* breaking  
interoperability, in part or completely, with any browser (they might not  
consider those browser users relevant markets, or they might not know  
better, in any case it is their loss), and the site's *certificate  
provider* breaking the site's current interoperability with a significant  
or large portion of their market by effectively denying service to those  
visitors.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Michael StJohns <[email-masked]>
Date: Fri, 01 Jun 2012 16:29:32 -0400

You're looking at the wrong end of things.  In both cases, the "breaking" is not due to the site operator (who chooses to use FLASH or gets their cert from someone who includes an NC), but in the support available at the browser.

I.e. the *site* chooses the *site certificate provider*.  The *site* chooses the technology.

Mike

---

From: Rob Stradling <[email-masked]>
Date: Fri, 01 Jun 2012 23:01:11 +0100

FWIW, Apple just voted in favour of allowing non-critical Name 
Constraints (in the CABForum ballot currently being conducted on the 
public CABForum list).

On 01/06/12 17:51, Phillip Hallam-Baker wrote:
> In the parlance that has become fashionable. Legacy Android and Safari
> are too big to fail. We cannot issue certs that are incompatible with
> the deployed base, Apple has no incentive to deploy code that checks NCs
> that will never appear in issued certs.
>
> If you want NCs implemented, the only way to do that is either (1) to
> make it possible for CAs to start issuing them now and then persuade
> Apple to take advantage of a control that is already being implemented
> in deployed certs or (2) persuade them that they would like to provide
> native support for bridge CA in Safari.
>
>
> The CAs cannot lead the market in technical standards in the way you
> seem to think. We can't even shut off SHA1 or RSA1024 without going
> through a huge amount of hassle.
>
> We can tell people what we think they SHOULD do but we can't force them
> to do that by refusing to issue certs that support their products.
>
>
> On Fri, Jun 1, 2012 at 9:50 AM, Miller, Timothy J. <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 6/1/12 8:31 AM, "Martin Rex" <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 4 Jun 2012 13:08:57 +0000

>Constraints (in the CABForum ballot currently being conducted on the

I could be cynical and interpret this as Apple saying "We're not going to
fix our code."

Ah well.  At least I can still beat Apple up when they fail on bridged
trust test suites.

-- T