On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote:

> On 29/03/12 21:05, Rob Stradling wrote:
> > RFC5280 says:
> > "4.2.1.10. Name Constraints
> > ...Conforming CAs MUST mark this extension as critical"
> >
> > Can anyone explain the reason for this requirement?
>
> Everyone, thanks for your comments.  There is certainly no consensus to change RFC5280 so that it doesn't advocate that Name Constraints be critical.
>
> However, I wonder if we could arrive at a compromise...
>
>
> PROPOSAL: Change the "MUST" to "SHOULD".
>
>
> RFC2119 says:
> '3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.'
>
> Now, I would say that the desire to avoid breaking all Apple devices is a "valid reason"!  And I think "SHOULD" would still send the appropriate message to implementers that they need to think very carefully about these things.
>
> Comments?  Votes?

Fully disagree. A number of people gave security reasons for the current wording. Watering down the security of the protocol because a vendor made a bad decision and no one is doing conformance testing (which would have trivially picked this up) is not a good response.

Paul, Erwann,

Aside from maybe petitioning Apple to fix their code, what would you advise Mozilla to do?

a) Require critical Name Constraints for "external" Sub-CAs ASAP, thereby causing currently deployed Apple products to reject all certs issued by these Sub-CAs.
b) Require Name Constraints, but specify that the critical flag need not be set and mention that this requirement breaks RFC5280.
c) Not require Name Constraints.  Instead, require all "external" Sub-CAs to undergo a "full" audit.
d) Other.

On 02/04/12 14:06, Erwann Abalea wrote:

I agree with Paul (and thus disagree with Rob).

This is a constraint. If this constraint is set by the CA, the CA wants
it to be enforced (else, why would it set this constraint?).

Not so long ago, Apple had to correct a pretty bad behaviour with X.509
certificates, not enforcing basicConstraints:CA=False set to critical.
Nobody then thought of changing a MUST into a SHOULD to allow this
behaviour. Apple choosed the only realistic solution, update its code.
This is the same situation here. If Apple can't correctly handle a
constraint imposed by the CA, or can't reject a certificate because of a
critical-but-unknown extension, that's their problem, and they're
putting their users at risk.

That said, I'm an Apple user, and in the Mozilla context I'm following,
Rob's proposition was not a bad one at first thought. Only at first.

2012/4/2 Paul Hoffman <paul.hoffman <at> vpnc.org <mailto:paul.hoffman <at> vpnc.org>>

   On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote:

    > On 29/03/12 21:05, Rob Stradling wrote:
    > > RFC5280 says:
    > > "4.2.1.10. Name Constraints
    > > ...Conforming CAs MUST mark this extension as critical"
    > >
    > > Can anyone explain the reason for this requirement?
    >
    > Everyone, thanks for your comments.  There is certainly no
   consensus to change RFC5280 so that it doesn't advocate that Name
   Constraints be critical.
    >
    > However, I wonder if we could arrive at a compromise...
    >
    >
    > PROPOSAL: Change the "MUST" to "SHOULD".
    >
    >
    > RFC2119 says:
    > '3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
   there
    >   may exist valid reasons in particular circumstances to ignore a
    >   particular item, but the full implications must be understood and
    >   carefully weighed before choosing a different course.'
    >
    > Now, I would say that the desire to avoid breaking all Apple
   devices is a "valid reason"!  And I think "SHOULD" would still send
   the appropriate message to implementers that they need to think very
   carefully about these things.
    >
    > Comments?  Votes?

   Fully disagree. A number of people gave security reasons for the
   current wording. Watering down the security of the protocol because
   a vendor made a bad decision and no one is doing conformance testing
   (which would have trivially picked this up) is not a good response.



--
Erwann.

_______________________________________________
pkix mailing list
pkix <at> ietf.org
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.

On Apr 2, 2012, at 8:06 AM, Erwann Abalea wrote:

This is the same situation here. If Apple can't correctly handle a constraint imposed by the CA, or can't reject a certificate because of a critical-but-unknown extension, that's their problem, and they're putting their users at risk.

Heh.  See attached screenshot.  

So it's not Apple who can't get it right, it's the iOS team.  :)

(The extension in question is the MS Application Policies OID [1.3.6.1.4.1.311.21.10].)

It's CryptoAPI that ignores critical extensions:

http://technet.microsoft.com/en-us/library/cc700843.aspx

"The CryptoAPI engine does not enforce critical extensions in certificates, only Certificate Revocation Lists (CRLs). The CryptoAPI engine and programming model places the burden of parsing critical extensions on to the calling application. Therefore, an application must understand and enforce a critical extension when evaluating a certificate. The CryptoAPI revocation provider, however, does evaluate critical extensions in CRLs and therefore would reject a CRL with a critical extension that is not known or understood."