Subject: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD

From: Rob Stradling <[email-masked]>
Date: Mon, 02 Apr 2012 10:23:49 +0100

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?

Thanks.

> Mozilla are currently considering requiring CAs in their Root Program to
> include the Name Constraints extension in "external" subordinate CA
> certificates (i.e. where the holder of the sub-CA private key is a
> different organization to the Root CA).
> Setting the critical flag would cause any software that doesn't
> recognize the Name Constraints extension to barf. I'm told that Apple's
> iOS and OSX platforms are among those that don't recognize the Name
> Constraints extension, so specifying critical Name Constraints is a
> non-starter. Therefore, Mozilla's current plan is to recommend that Name
> Constraints be non-critical.
>
> Should RFC5280 be updated to specify that Name Constraints need not be
> critical?
>
> Thanks.
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Apr 2012 05:32:02 -0700

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

> Everyone, thanks for your comments.  There is certainly no consensus to change RFC5280 so that it doesn't advocate that Name Constraints be critical.
> 
> 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 Hoffman

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 2 Apr 2012 15:06:02 +0200

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 <[email-masked]>

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

---

From: Rob Stradling <[email-masked]>
Date: Mon, 02 Apr 2012 14:24:59 +0100

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:
> 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?).
>
> critical-but-unknown extension, that's their problem, and they're
> putting their users at risk.
>
> 2012/4/2 Paul Hoffman <[email-masked] <mailto:[email-masked]>>
>
>      > Everyone, thanks for your comments.  There is certainly no
>     consensus to change RFC5280 so that it doesn't advocate that Name
>     Constraints be critical.
>      >
>      > 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
> [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: "Jim Schaad" <[email-masked]>
Date: Mon, 2 Apr 2012 15:46:59 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rob Stradling
> Sent: Monday, April 02, 2012 3:25 PM
> To: Erwann Abalea; Paul Hoffman
> Cc: PKIX; Kathleen Wilson
> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name
> Constraints from MUST to SHOULD
> 
> Paul, Erwann,
> 
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.
be set
> and mention that this requirement breaks RFC5280.

For what it is worth this is basically what you suggested by making it non
critical

Jim

> > 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.
> > 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
> > 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.
> COMODO CA Limited, Registered in England No. 04058690 Registered Office:
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: "Miller, Timothy J." <[email-masked]>
Date: Mon, 2 Apr 2012 13:51:33 +0000

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

I understand MS's reasoning behind this design, but I've never liked it.  Too many applications get it wrong.

-- T

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 2 Apr 2012 16:06:30 +0200

Rob,

Apple may not support the nameConstraints extension, I haven't tested it
but I trust you in saying so.
What I haven't seen is a test of this constraint placed and set to
critical, giving a wrongly rejected certificate because of the critical
bit. From what I know, before the summer-2011 correction, maybe Apple
didn't enforce the unknown-but-critical logic and let the certificate pass
the validation. Maybe it's still the case, and that's their problem.

I'd go for the a) answer. This constraint MUST be set critical since
RFC2459 (dated 01/1999), and it's also recommended to be set critical since
1997 edition of X.509.
With my "respect of standards and security practices" hat, that's the most
logical answer.

With my "CA" hat, I may have some problems. But we (as CAs) have others,
laxism of CAs and editors, and bad public perception of CAs is also an
important one. Answer a) can help solve it.

2012/4/2 Rob Stradling <[email-masked]>

> these Sub-CAs.
> c) Not require Name Constraints.  Instead, require all "external" Sub-CAs
> to undergo a "full" audit.
> d) Other.
>
>
>> 2012/4/2 Paul Hoffman <[email-masked] <mailto:
>> [email-masked]>**>
>>
>>
>> ______________________________**_________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/pkix<https://www.ietf.org/mailman/listinfo/pkix>
>>
>
> --
> Rob Stradling
> 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.
>

-- 
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 2 Apr 2012 16:09:28 +0200

2012/4/2 Miller, Timothy J. <[email-masked]>

Thanks.

>  "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."
>
>
Awful. In the vast majority, application developers don't know anything
about certificate validation, and should not have to care about it.

-- 
Erwann.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 2 Apr 2012 10:13:16 -0400

The first change would be from "maybe" petitioning Apple to "definitely"
calling their attention to the problem and requesting a fix.

DoD has encountered similar issues when deploying systems based on
commercial products.  For example our policy is to use "Suite B"
cryptographic algorithms (ECC + AES) which are sometimes not supported
in the products we need to use.  The acquisition process includes a
scheme for designating requirements as "Threshold" (required) and
"Objective (desired).  CJCSM 3170.01
(http://www.dtic.mil/cjcs_directives/cdata/unlimit/m317001.pdf) says:

   "Threshold values should be based on what is achievable through
    the current state of technology as a minimum. The objective values
    may be defined based on a goal for the end-state of the system."

If we were acquiring a system using Apple products, the objective would
be to comply with RFC 5280, and the threshold would be to comply with
RFC 5280 "except for requirements A, B, and C".   Our solution would NOT
be to change technical standards such as 5280 to dilute requirements
based on the capabilities of current products.

As for what to do to get a system working using broken products, whether
you choose option b), c), or d) is not a matter for PKIX to decide.  If
you think issuing non-standard certs is the most effective way to
transition from current to target systems, then by all means choose b).

Dave

-----Original Message-----
Sent: Monday, April 02, 2012 9:25 AM

Paul, Erwann,

critical.

> following, Rob's proposition was not a bad one at first thought. Only
at first.
>      > '3. SHOULD   This word, or the adjective "RECOMMENDED", mean
that
>     there

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Apr 2012 16:17:09 +0200 (MEST)

I've got the slight feeling that folks are significantly talking
past each other.

What Rob is asking for is permissing for the CA(!) to issue a name
constraint non-critical in order to express its intention with respect
to enforcement of that name constraint.  To me, that looks like a
perfectly valid request, and PKIX (rfc5280) is in violation of
rfc2119 of requiring this extension to be always made critical
by the CA (instead of leaving that decision to the CA to express
its intention).

Apple's implementation seems to be correct, in that it rejects
critical name constraints because it does not implement them.
I don't know whether that rejection applies to *ALL* name constraints
(including directory names), or only to name constraints on SubjectAltNames
of type DNSName, because not implementing subjectAltName constraints
and rejecting all certs that contain such marked critical seems OK
and conforming to rfc5280.

Not implementing name constraints on directory names, while not
exactly conforming with rfc5280 (where this is inappropriately
declared a MUST), looks pretty sensible to me, because the use
of hierarchical directory structures of DNames with only one
single trust anchor is a fairly unrealistic usage scenario,
so it makes no sense that this hardly usable feature is a
MUST in the first place.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Mon, 02 Apr 2012 16:14:05 +0100

> but I trust you in saying so.

Hi Erwann.  To be honest, I haven't tested it myself.  I'm relying on 
statements made over at mozilla.dev.security.policy.
e.g. Kathleen wrote a few days ago:
"For instance, Apple does not currently support name constraints in iOS 
and OS X, and they will not commit to a certain time frame to have this 
support available."

> didn't enforce the unknown-but-critical logic and let the certificate
> pass the validation. Maybe it's still the case, and that's their problem.
>
> RFC2459 (dated 01/1999), and it's also recommended to be set critical
> since 1997 edition of X.509.
> With my "respect of standards and security practices" hat, that's the
> most logical answer.
>
> 2012/4/2 Rob Stradling <[email-masked]
> <mailto:[email-masked]>>
>
>     Paul, Erwann,
>
>     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.
>         following,
>         2012/4/2 Paul Hoffman <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>__>
>
>
>         _________________________________________________
>         pkix mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/pkix
>         <https://www.ietf.org/mailman/listinfo/pkix>
>
>
>     --
>     Rob Stradling
>     Office Tel: +44.(0)1274.730505 <tel:%2B44.%280%291274.730505>
>     Office Fax: +44.(0)1274.730909 <tel:%2B44.%280%291274.730909>
>     www.comodo.com <http://www.comodo.com>
>
>     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.
>
>
>
>
> --
> Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 2 Apr 2012 17:51:09 +0200

2012/4/2 Martin Rex <[email-masked]>

> to enforcement of that name constraint.

Not exactly. Mozilla is looking for a way to counter the lack of
constraints on externally-operated sub-CAs of their root CA program. The
goal is to protect their userbase. In my opinion, Rob was asking for advice
on how a non-critical nameConstraints extension would be perceived by
IETF-PKIX members.

> To me, that looks like a

How could PKIX be in violation of anything by requiring the extension to be
critical, and why the RFC2119? Is PKIX also in violation of RFC2119 when
requiring the serial number to be a positive integer not longer than 20
octets?

> critical name constraints because it does not implement them.

That's not what happened before summer-2011 when Apple corrected iOS.
Before that patch, a certificate containing a *critical* basicConstraints
extension with the CA element set to false was still able to sign another
certificate. That either means the basicConstraints wasn't correctly
enforced or the unknown-but-critical rejection rule wasn't correctly
enforced. I don't have any precise information about what has been
corrected, so the later explanation can still hold true.

-- 
Erwann.

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Apr 2012 19:13:35 +0200 (MEST)

> requiring the serial number to be a positive integer not longer than 20

http://tools.ietf.org/html/rfc2119#section-6

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Requiring a CA to always make name constraints critical will very probably
impair/break interop with implementations that do not support that
particular type of name constraints.

Since the CA is the entity which defines the policy of whether RPs
enforcing this name constraints is a problem or not, the MUST can
*NOT* be justified with security.  There for the "MUST always be critical"
in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID.
That is pretty simple math.

The only reason that this is there is a desire for some organizations
to procure specific features in COTS, rather than having to pay extra
for it.  Deserves to be ignored by the marketplace.

The discussion of the purpose of both critical and non-critical uses of a
constraints extension is much more reasonably explained here:

  http://tools.ietf.org/html/rfc3647#section-3.3.1

and the very same reasoning can be applied to name constraints.
It must be up to the CA that puts name constraints into a subCA cert
to determine whether these should be critical or not.  It is invalid
for rfc5280 to unconditionally require name constraints to be marked
critical by CAs.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 2 Apr 2012 13:17:18 -0400

Martin,

You miss the security implication of this.

CA can always make it NC and the clients that do not process name constraints will be exposed if the Sub CA is rogue, compromised or RAs it trusts go rouge or are compromised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, April 02, 2012 1:14 PM
To: Erwann Abalea
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Erwann Abalea wrote:
> > rfc2119 of requiring this extension to be always made critical by 
> > the CA (instead of leaving that decision to the CA to express its 
> > intention).
> >
> 
> How could PKIX be in violation of anything by requiring the extension 
> to be critical, and why the RFC2119? Is PKIX also in violation of 
> RFC2119 when requiring the serial number to be a positive integer not 
> longer than 20 octets?

Requiring a CA to always make name constraints critical will very probably impair/break interop with implementations that do not support that particular type of name constraints.

Since the CA is the entity which defines the policy of whether RPs enforcing this name constraints is a problem or not, the MUST can
*NOT* be justified with security.  There for the "MUST always be critical"
in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID.
That is pretty simple math.

The only reason that this is there is a desire for some organizations to procure specific features in COTS, rather than having to pay extra for it.  Deserves to be ignored by the marketplace.

The discussion of the purpose of both critical and non-critical uses of a constraints extension is much more reasonably explained here:

and the very same reasoning can be applied to name constraints.
It must be up to the CA that puts name constraints into a subCA cert to determine whether these should be critical or not.  It is invalid for rfc5280 to unconditionally require name constraints to be marked critical by CAs.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Apr 2012 10:27:42 -0700

> That is pretty simple math.

No, it is absurd. You might not realize it, but there are dozens, maybe hundreds, of RFCs that have similar requirements. Martin Rex declaring them all "NULL and VOID" is a bit over the top. Last I checked, no one made you an IESG member, nor the RFC Editor.

> for it.  

It is more than a bit insulting for you to ascribe a single motivation to the hundreds of people who worked on RFC 5280 and its predecessors, as well as to everyone who has read it and didn't notice this problem.

Criticality bits have caused problems for PKIX and other IETF standards. Some people probably agree with you that there should not be a requirement that the writer (CA) must set it; other people disagree with you.

> Deserves to be ignored by the marketplace.

Feel free to ignore it, then. It is still in the standard.

> for rfc5280 to unconditionally require name constraints to be marked

So far, not many people on this list have agreed with you. Without consensus of the WG, the document will remain the same.

--Paul Hoffman

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 2 Apr 2012 19:44:27 +0200

> particular type of name constraints.

That's shouldn't be taken into account. The behaviour of a compliant RP is
clear, if an extension is not known and set critical, the certificate must
be considered invalid. The fact that applying the rule breaks
implementations written way later than the publication of RFC2459 (which
states the same) doesn't say that the rule is NULL and VOID.

> That is pretty simple math.

Ok, I see the argument. Let's extend it to other extensions. For example
the deltaCRLIndicator extension, which also MUST be set critical. You
probably know why it is dangerous for a RP to receive a CRL with such an
extension non critical. Following your logic, the CA defines what is secure
and what isn't, so this extension could be set non critical. Is that right?
What about the X.509 which states that this extension is always set
critical?
Can your argumentation be applied to every extension defined in the
recommendation and the PKIX profiles?

> for it.  Deserves to be ignored by the marketplace.

I need you (or someone else) to rephrase this paragraph, I don't understand
it, it seems.

For me, a constraint needs to be set critical, or it can be considered
nonexistent (a RP is free to ignore any unknown non critical extension,
therefore free to declare non critical extension as unknown).

The logic behind the RFC5280 choice is security for the end-user. And this
discussion has been brought here because of end-user security problems.

-- 
Erwann.

---

From: Sean Leonard <[email-masked]>
Date: Mon, 02 Apr 2012 10:49:08 -0700

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

+1 for Paul's comment.

-1 for voting. Keep it "MUST".

-Sean

---

From: Michael Myers <[email-masked]>
Date: Mon, 2 Apr 2012 11:01:03 -0700

Toward WG consensus, keep it MUST.

SHALL would be even better, but that's a semantic thing on my part.

Mike

On Apr 2, 2012, at 10:49 AM, Sean Leonard wrote:

>> 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.
>
> +1 for Paul's comment.
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Apr 2012 20:48:14 +0200 (MEST)

Santosh Chokhani wrote:
> CA can always make it NC and the clients that do not process name
> constraints will be exposed if the Sub CA is rogue, compromised
> or RAs it trusts go rouge or are compromised.

This discussion seems to be lost some deep in the woods.

RPs that implement name constraints have to process them when present
independent whether they're marked critical or not, so we can safely
exclude these from the discussion, they simply do not matter here.

Now for the remaining RPs that do not support a particular name
constraint that a higher level CA intends to impose on a subCA.
When it marks that constraint critical, the certificates issued
by the subCA will not be acceptable _at_all_ to RPs that do not implement
the particular name constraints the CA wants to use.  If the name
constraints are marked non-critical, then the certificates issued
by the subCA will be usable with those RPs (not implementing the
name constraints) under ignorance of the name constraints.

Whether the subCA "goes rogue" is irrelevant for the RPs that implement
the name constraints, because they will process the name constraints even
when not critical.  For the RPs that do not implement the name constraints,
they continue to not care about the name constraints, so whether the CA
is honest or rogue (with respect to the name constraints) is irrelevant
to them _as_well_.

Now where is your problem letting CAs decide for themselves whether
they want to make the name constraints extension critical or not,
similar to leaving it up to CA to make policy constraints critical or not.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Apr 2012 20:51:26 +0200 (MEST)

Paul Hoffman wrote:
> No, it is absurd. You might not realize it, but there are dozens,
> maybe hundreds, of RFCs that have similar requirements.  Martin Rex
> declaring them all "NULL and VOID" is a bit over the top.
> Last I checked, no one made you an IESG member, nor the RFC Editor.

rfc2119 is something like our "constitution" for standards.

The requirement that CAs MUST mark name constraints extension critical
is in clear conflict with rfc2116 section 6, and therefore "unconstitutional"
for an IETF Standard, which makes that requirement NULL and VOID.

Specifications, and in particular those that are proposed, must be
assumed to contain defects.  That is just one of the defects of rfc5280.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Apr 2012 12:31:14 -0700

> rfc2119 is something like our "constitution" for standards.

No, it is not. No one has pretended that until now. It is a set of definitions that is widely used, and is also nearly as widely abused, in RFCs. Note the difference?

Next topic, please.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Apr 2012 22:21:07 +0200 (MEST)

Paul Hoffman wrote:
> No, it is not. No one has pretended that until now. It is a set of
> definitions that is widely used, and is also nearly as widely abused,
> in RFCs. Note the difference?

Most RFC (and that includes 5280) contain this disclaimer:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

rfc2119 section 6 defines which are valid used of these imperatives,
and which are invalid uses.  When talking about conformance,
invalid uses of imperatives are simply defects of the spec and
irrelevant.  YMMV.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Mon, 02 Apr 2012 16:28:55 -0400

>invalid uses of imperatives are simply defects of the spec and

The short paragraph from 2119 you cited allows MUST to be used "to limit
behavior which has potential for causing harm".  That applies here.

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Apr 2012 01:42:30 +0200 (MEST)

> behavior which has potential for causing harm".  That applies here.

Nope, it clearly does NOT apply here.  A CA which does not want a
certificate to be accepted by RPs that do not implement a particular
name constraints extension that the CA wants to add to a subCA cert
can mark that name constraints as critical.

The description in

about the semantics of critical and non-critical certificate policies
makes sense, whereas the requirement that CAs must mark name constraints
critical is in clear conflict with rfc2119 section 6 and can therefore
be ignored by implemenations without becoming non-compliant.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Apr 2012 01:45:18 +0200 (MEST)

> be ignored by implemenations without becoming non-compliant.

An "Implementation" of "must mark name constraints critical" means
that a CAs can issue certs with non-critical name constraints and
still be conforming to rfc5280, because that particular MUST is
invalid per rfc2119 section 6.

-Martin

---

From: Piyush Jain <[email-masked]>
Date: Mon, 2 Apr 2012 17:00:27 -0700

> From: [email-masked]
> To: [email-masked]
> Date: Tue, 3 Apr 2012 01:42:30 +0200
> CC: [email-masked]; [email-masked]
> So you are saying that RPs are not subjected to any security risk by ignoring the NC extension. That would be a very interesting claim.Just lay out a scenario where a CA includes the NC extension and the security implications are same for RPs who ignore it and the RPs who process it. And then ask the question if the the CA needs to include the NC at all in such a scenario.

> be ignored by implemenations without becoming non-compliant.
Most people in this group disagree with this interpretation. So, obviously the conflict (if any) is not clear.

---

From: Tom Gindin <[email-masked]>
Date: Mon, 2 Apr 2012 21:09:10 -0400

I'm obviously outvoted, but I'm in favor of MAY rather than MUST 
or even SHOULD.  Leaving this extension as MUST be critical won't get it 
widely adopted any more than in the past decade, and IMHO the security 
difference between the CA's omitting this extension for compatibility 
reasons and it being non-critical is greater than that between it being 
non-critical and critical.

Tom Gindin

From:   Michael Myers <[email-masked]>
To:     Sean Leonard <[email-masked]>, 
Cc:     [email-masked]
Date:   04/02/2012 02:00 PM
Subject:        Re: [pkix] Proposal: Change the Criticality Requirement of 
Name    Constraints from MUST to SHOULD
Sent by:        [email-masked]

Mike

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 2 Apr 2012 19:45:29 -0700 (Pacific Daylight Time)

On Thu, Mar 29, 2012 at 1:14 PM, Adam Langley <[email-masked]> wrote:
> On Thu, Mar 29, 2012 at 4:05 PM, Rob Stradling <[email-masked]> wrote:
> I'm not aware of any software that enforces this requirement and agree
> that the MUST in RFC 5280 is unhelpful and support the idea that it
> should be removed.

I disagree.  Name Constraints is integral to understanding the semantic of a CA certificate, and really has to be be critical.  This is the same reason why Basic Constraints must be critical (to determine if it's even a CA certificate).  I query, how is it unhelpful?  How does it get in the way?  How does it cause problems?  It seems that the only motivation for this is the removal of language in the Basic Requirements.

There is, however, a MUST in the same clause which I think should be gotten rid of: "The Name Constraints extension, which MUST only appear in CA certificates, [...]".

The only time a person should need the action of the CA should be when his identity is being verified, when his identity is subpoenaed, when he's renewing, and when he needs to rekey/revoke.  Why should a person be prohibited from issuing certificates to his own devices using his certified key?  (I must point out, 100 CAs is not going to be enough to handle the demand of individuals when the barriers against their adoption of cryptographic security are removed.  Do we want to spam them with requests for additional device keys on top of that?)

I would like to allow device certificates to be issued by end entity certificates.  To do this with any effective DNS-related control, Name Constraints must be in end entity certificates.  I would suggest that End Entity Name Constraints be non-critical to avoid disrupting current deployment (since EE NC doesn't change any semantics if it's not understood).

-Kyle H

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Apr 2012 11:59:40 +0300

> non-critical and critical.

Going back to Rob's original question, this is putting the CAs in a serious vise.

If they issue an external sub-CA certificate without name constraints or with non-critical name constraints, they might be rejected by Mozilla.
If they issue them with a critical name constraints, the EE certificates may not work in some of the installed base.

I really don't like us telling Mozilla to force the CAs to break some of the installed base. If Apple can be convinced to change their implementation, all the better. Couldn't such a decision be better arrived at in the CA/Browser Forum?

Yoav

---

From: Ben Laurie <[email-masked]>
Date: Tue, 3 Apr 2012 11:03:31 +0100

On Mon, Apr 2, 2012 at 10:23 AM, Rob Stradling <[email-masked]> wrote:
> 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

It doesn't break them - they correctly refuse to process the certificates :-)

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 3 Apr 2012 09:44:40 -0400

Martin,

The answer is in your own response.  The CA wants to protect those relying parties who do not understand the semantics of the extension.  If the RP is hell-bent on accepting the certificate, it can choose to ignore critical extensions as well.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, April 02, 2012 2:48 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh Chokhani wrote:
> constraints will be exposed if the Sub CA is rogue, compromised or RAs 
> it trusts go rouge or are compromised.

RPs that implement name constraints have to process them when present independent whether they're marked critical or not, so we can safely exclude these from the discussion, they simply do not matter here.

Now for the remaining RPs that do not support a particular name constraint that a higher level CA intends to impose on a subCA.
When it marks that constraint critical, the certificates issued by the subCA will not be acceptable _at_all_ to RPs that do not implement the particular name constraints the CA wants to use.  If the name constraints are marked non-critical, then the certificates issued by the subCA will be usable with those RPs (not implementing the name constraints) under ignorance of the name constraints.

Whether the subCA "goes rogue" is irrelevant for the RPs that implement the name constraints, because they will process the name constraints even when not critical.  For the RPs that do not implement the name constraints, they continue to not care about the name constraints, so whether the CA is honest or rogue (with respect to the name constraints) is irrelevant to them _as_well_.

Now where is your problem letting CAs decide for themselves whether they want to make the name constraints extension critical or not, similar to leaving it up to CA to make policy constraints critical or not.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 3 Apr 2012 09:45:37 -0400

Kyle,

5280 does not have the concept of end entity signing certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kyle Hamilton
Sent: Monday, April 02, 2012 10:45 PM
To: Adam Langley
Cc: [email-masked]; Kathleen Wilson
Subject: Re: [pkix] Criticality of Name Constraints in 5280

On Thu, Mar 29, 2012 at 1:14 PM, Adam Langley <[email-masked]> wrote:
>> Should RFC5280 be updated to specify that Name Constraints need not 
>> be critical?
>

-Kyle H

---

From: Michael Jenkins <[email-masked]>
Date: Tue, 3 Apr 2012 11:19:07 -0400

I'm a bit confused by the way this is being talked about. If I get this
wrong, I suspect Santosh will set me right :)

The discussion so far has made it seem that the CA who sets name
constraints is the the same one issuing the certificate the RP is going to
rely on. But it's not; the CA who is going to set the name constraints is
the Root CA; it sets in in the Sub CA certificate as a promise to the RP
that the Sub CA will not issue outside its constraint.

Making this extension critical is the only way the Root CA can ensure that
if the Sub CA tries to issue a certificate outside its constraint on the
sly, the client will at least raise the issue to the RP. If at that point
the RP wants to accept the certificate anyway (perhaps based on other
information), that's the RP's business - the Root CA's promise has been
fulfilled.

If the extension is not marked critical, the client is free to ignore the
extension, and the Root CA has no way to bring any violation to the RP's
attention. Not that a client couldn't do it, but that puts the fulfillment
of the Root CA's promise in the hands of the client, not the Root CA.

It seems the original problem is that Mozilla wants to require Root CAs
that are put in its trust anchor list to include name constraints, but that
creates a third party problem - if the Root CAs are then issuing Sub CA
certificates that are going to break (non-Mozilla) clients, then Mozilla
has created a problem for the Root CA that Mozilla doesn't have to suffer
for. I appreciate this is a bum deal for the Root CA and one that Mozilla
would like to avoid.

However, the proposed solution (making name constraints non-critical) only
assuages Mozilla's guilt about unintended consequences; it isn't consistent
with the system problem. That is, Mozilla is saying that because their
client properly processes the extension (right?) they can uphold the
promise for the
Root CAs in their trust anchor list. But, Root CAs - in order to solve the
problem we've created for you, we're going to remove your ability to make
good on your promise for certain other clients.

This seems like an equally bum deal for the Root CAs.

Mike Jenkins

On Tue, Apr 3, 2012 at 9:44 AM, Santosh Chokhani <[email-masked]>wrote:

> Martin,
>
> The answer is in your own response.  The CA wants to protect those relying
> parties who do not understand the semantics of the extension.  If the RP is
> hell-bent on accepting the certificate, it can choose to ignore critical
> extensions as well.
>
> Now for the remaining RPs that do not support a particular name constraint
> that a higher level CA intends to impose on a subCA.
> When it marks that constraint critical, the certificates issued by the
> subCA will not be acceptable _at_all_ to RPs that do not implement the
> particular name constraints the CA wants to use.  If the name constraints
> are marked non-critical, then the certificates issued by the subCA will be
> usable with those RPs (not implementing the name constraints) under
> ignorance of the name constraints.
>
> they continue to not care about the name constraints, so whether the CA is
> honest or rogue (with respect to the name constraints) is irrelevant to
> them _as_well_.
>
> Now where is your problem letting CAs decide for themselves whether they
> want to make the name constraints extension critical or not, similar to
> leaving it up to CA to make policy constraints critical or not.
>
>
> -Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 3 Apr 2012 12:05:35 -0400

Why the smiley? - this serious!  :-)

The purpose of critical is to achieve this behavior.  If the PKI is set up so that CA A certifies names in *.mycompany.com and CA B certifies *.yourcompany.com, I don't want CA B to be able to forge certificates for my websites.  Meaning I don't want the universe of Internet users to be fooled by such forgeries, which means that it is correct for all applications that recognize that they are unable to detect forgeries to refuse to process the certificates.

If name constraints are not useful (i.e. there is not a relationship between a CA and the domains it is authorized to certify) then don't include the extension in the certificate at all.  If constraints are useful (i.e. I want to ensure that my servers cannot be impersonated by others using different CAs) then the constraints should be processed or the user warned ("Warning: This site's certificate contains unrecognized critical security information - Abort or Continue (not recommended)?)".

Under what business scenario is it desirable for the PKI include information to detect impersonation but mark it so that it is silently ignored?

Dave

-----Original Message-----
From: Ben Laurie
On Mon, Apr 2, 2012 at 10:23 AM, Rob Stradling <[email-masked]> wrote:
>
> 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

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 3 Apr 2012 12:49:35 -0400

Amen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Tuesday, April 03, 2012 12:06 PM
To: [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD

Dave

-----Original Message-----
From: Ben Laurie

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Apr 2012 22:39:53 +0300

On Apr 3, 2012, at 6:19 PM, Michael Jenkins wrote:

> I'm a bit confused by the way this is being talked about. If I get this wrong, I suspect Santosh will set me right :)
> 
> The discussion so far has made it seem that the CA who sets name constraints is the the same one issuing the certificate the RP is going to rely on. But it's not; the CA who is going to set the name constraints is the Root CA; it sets in in the Sub CA certificate as a promise to the RP that the Sub CA will not issue outside its constraint. 
> 
> Making this extension critical is the only way the Root CA can ensure that if the Sub CA tries to issue a certificate outside its constraint on the sly, the client will at least raise the issue to the RP. If at that point the RP wants to accept the certificate anyway (perhaps based on other information), that's the RP's business - the Root CA's promise has been fulfilled.

True, but I think we are personifying bunches of bits here. The root CA is not a certificate, it's a company, and companies have contracts and people. If we take Rob to personify Comodo, Rob can avoid having sub CAs issuing the wrong certificates by other means, such as writing that in a contract, or only giving subCA certificates to trustworthy people.

> If the extension is not marked critical, the client is free to ignore the extension,

Not quite. A client that understands the extension MUST process it anyway.

> and the Root CA has no way to bring any violation to the RP's attention. Not that a client couldn't do it, but that puts the fulfillment of the Root CA's promise in the hands of the client, not the Root CA.

Promise to whom?

> It seems the original problem is that Mozilla wants to require Root CAs that are put in its trust anchor list to include name constraints,

Only for those sub-CAs that are owned by someone other than the owner of the root CA.

> but that creates a third party problem - if the Root CAs are then issuing Sub CA certificates that are going to break (non-Mozilla) clients, then Mozilla has created a problem for the Root CA that Mozilla doesn't have to suffer for. I appreciate this is a bum deal for the Root CA and one that Mozilla would like to avoid.
> 
> However, the proposed solution (making name constraints non-critical) only assuages Mozilla's guilt about unintended consequences; it isn't consistent with the system problem. That is, Mozilla is saying that because their client properly processes the extension (right?) they can uphold the promise for the 
> Root CAs in their trust anchor list. But, Root CAs - in order to solve the problem we've created for you, we're going to remove your ability to make good on your promise for certain other clients.
> 

It would force them to choose between not working on Firefox and not working on iOS. Tough call, and only Apple can solve it.

Yoav

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 3 Apr 2012 16:32:00 -0400

See line.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2012 3:40 PM
To: Michael Jenkins
Cc: Santosh Chokhani; [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

On Apr 3, 2012, at 6:19 PM, Michael Jenkins wrote:

> I'm a bit confused by the way this is being talked about. If I get 
> this wrong, I suspect Santosh will set me right :)
> 

True, but I think we are personifying bunches of bits here. The root CA is not a certificate, it's a company, and companies have contracts and people. If we take Rob to personify Comodo, Rob can avoid having sub CAs issuing the wrong certificates by other means, such as writing that in a contract, or only giving subCA certificates to trustworthy people.
[Santosh] You can do most things by contract.  The purpose of PKI is to provide security and the sub CA doing something on purpose is not the only scenario.  It, its agent could be compromised.

Not quite. A client that understands the extension MUST process it anyway.
[Santosh] I suspect the comment was made in the context of clients that do not understand the extension.

> and the Root CA has no way to bring any violation to the RP's attention. Not that a client couldn't do it, but that puts the fulfillment of the Root CA's promise in the hands of the client, not the…

Promise to whom?
[Santosh] To all those rely on the certificates issued by it.

> It seems the original problem is that Mozilla wants to require Root 
> CAs that are put in its trust anchor list to include name constraints,

> However, the proposed solution (making name constraints non-critical) 
> only assuages Mozilla's guilt about unintended consequences; it isn't consistent with the system problem. That is, Mozilla is saying that because their client properly processes the extension (right?) they can uphold the promise for the Root CAs in their trust anchor list. But, Root CAs - in order to solve the problem we've created for you, we're going to remove your ability to make good on your promise for certain other clients.
> 

Yoav

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 03 Apr 2012 16:40:53 -0400

While it may be true in a hierarchical PKI that a hierarchically 
superior CA may procedurally impose restrictions on the certificates 
that may be issued by its subordinate CAs and then may include 
constraints extensions that reflect those restrictions, it would be 
incorrect to suggest that constraints extensions always work this way.

As an example, the cross-certificate from the DoD Root CA to the Federal 
Bridge CA includes a policyConstraints extension.  This is not a promise 
to the RP that CAs in the Federal PKI (i.e., those that can be reached 
through the Federal Bridge CA) will not issue outside the constraint.  
It is a restriction imposed by DoD on DoD relying parties to only accept 
a subset of those (legitimate) certificates issued within the Federal 
PKI that satisfy the policy constraints specified in the extension.

Similarly, if DoD (hypothetically) wanted to restrict its relying 
parties to only accept U.S. government-issued certificates, it could 
place a nameConstraints extension in its cross-certificate to the 
Federal Bridge CA.  The nameConstraints extension in the 
cross-certificate would not be a promise to the RP that no CA in the 
Federal PKI will issue outside of the constraint, nor is it an 
indication that any certificates issued outside the constraint are 
illegitimate or a "violation."  The nameConstraints extension would only 
indicate that DoD does not want its relying parties to accept 
certificates that are outside of the constraint.

I also disagree with your statement:
> constraints is the the same one issuing the certificate the RP is 
> going to rely on. But it's not;

The relying party relies on every certificate in the certification path, 
so it most definitely does rely on the certificate that includes the 
nameConstraints extension.

On 04/03/2012 11:19 AM, Michael Jenkins wrote:
> constraints is the the same one issuing the certificate the RP is 
> going to rely on. But it's not; the CA who is going to set the name 
> constraints is the Root CA; it sets in in the Sub CA certificate as a 
> promise to the RP that the Sub CA will not issue outside its constraint.
>
> Making this extension critical is the only way the Root CA can ensure 
> that if the Sub CA tries to issue a certificate outside its constraint 
> on the sly, the client will at least raise the issue to the RP. If at 
> that point the RP wants to accept the certificate anyway (perhaps 
> based on other information), that's the RP's business - the Root CA's 
> promise has been fulfilled.
>
> If the extension is not marked critical, the client is free to ignore 
> the extension, and the Root CA has no way to bring any violation to 
> the RP's attention. Not that a client couldn't do it, but that puts 
> the fulfillment of the Root CA's promise in the hands of the client, 
> not the Root CA.
>
> but that creates a third party problem - if the Root CAs are then 
> issuing Sub CA certificates that are going to break (non-Mozilla) 
> clients, then Mozilla has created a problem for the Root CA that 
> Mozilla doesn't have to suffer for. I appreciate this is a bum deal 
> for the Root CA and one that Mozilla would like to avoid.
>
> only assuages Mozilla's guilt about unintended consequences; it isn't 
> consistent with the system problem. That is, Mozilla is saying that 
> because their client properly processes the extension (right?) they 
> can uphold the promise for the
> Root CAs in their trust anchor list. But, Root CAs - in order to solve 
> the problem we've created for you, we're going to remove your ability 
> to make good on your promise for certain other clients.
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2012 16:50:30 -0400

A
>...
>
>I really don't like us telling Mozilla to force the CAs to break 
>some of the installed base. If Apple can be convinced to change 
>their implementation, all the better. Couldn't such a decision be 
>better arrived at in the CA/Browser Forum?
>
>Yoav

The CA/Browser forum is a good place to discuss the issue and for
CAs and browser vendors to decide how to proceed.  However, that forum
does not have responsibility for PKIX standards.

Steve

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Apr 2012 07:12:06 +0300

> does not have responsibility for PKIX standards.

Fully agree. And conversely, this is not the place to tell Mozilla how to run their CA validation program, or to tell Apple what parts of what standards they have to implement. With everyone here being an individual rather than a representative of their company, whatever we say here is not binding on either Mozilla or Apple, while the CA/Browser forum seems to have had some success in getting such organizations to do things.

As far as the PKIX standards go, I think it's really obvious that there is a rough consensus against relaxing the MUST requirements, so I think we (the PKIX list) have done all we can in this matter. It's likely that ignoring the standard and making a non-critical extension will work with all browsers, so I'm guessing that that is what they'll do regardless of what we say.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Wed, 04 Apr 2012 09:43:08 +0100

Replying to several messages at once in an effort to close this thread...

On 03/04/12 17:05, Kemp, David P. wrote:
<snip>
> Under what business scenario is it desirable for the PKI include
 > information to detect impersonation but mark it so that it is
 > silently ignored?

If CA X's certs work with Apple's software, but CA Y's certs are 
rejected by Apple's software, which CA is likely to generate the most sales?

The (sad) fact is that Critical Name Constraints is a non-starter for 
the public CAs for the foreseeable future.  However, non-critical Name 
Constraints would be better than avoiding using Name Constraints at all.

On 04/04/12 05:12, Yoav Nir wrote:
 > As far as the PKIX standards go, I think it's really obvious that
 > there is a rough consensus against relaxing the MUST requirements, so
 > I think we (the PKIX list) have done all we can in this matter.

Agreed.

 > It's likely that ignoring the standard and making a non-critical
 > extension will work with all browsers, so I'm guessing that that is
 > what they'll do regardless of what we say.

Yep, almost certainly.

 > does not have responsibility for PKIX standards.

Agreed.  I'll take the discussion to the CABForum.

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Apr 2012 23:16:51 +0200 (MEST)

Yoav Nir wrote:
> 
> It would force them to choose between not working on Firefox and not
> working on iOS. Tough call, and only Apple can solve it.

The name constraints will _not_ appear in RootCA certs (=trust anchors),
and probably _neither_ in the subCAs directly below the rootCAs, but rather
in organizational subCAs signed by subCAs of RootCAs.

PKI software that rejects CA certs with name constraints that
are _not_ marked critical can be considered broken (because it is
_not_ listed as something to check when processing a cert in a
certification path in rfc5280 section 6, and rfc5280 explicitly
discourages making other conformance checks on attributes from
rfc5280 sections 4&5 during certificate path validation).
So unless Apple's implementation aborts upon seeing _any_ name
constraints (even non-critical ones), non-critical name constraints
might interoperate with most of the installed base.

But you will really have to test interop, and probably for several
dozen independent PKI implementations (and different releases thereof)
rather than just looking only at the most recent implementations
shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Java.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Apr 2012 00:48:03 +0300

> in organizational subCAs signed by subCAs of RootCAs.

Yes. And if Mozilla requires that those have critical names constraints, then the CAs have two options:
 - Not comply and get removed from Mozilla's trust anchor store - breaking compatibility with Firefox for the root CA
 - Comply and get the organizational subCA-signed certificates rejected by iOS

> might interoperate with most of the installed base.

They probably will. But a certification path that contains such a certificate is not compliant with RFC 5280, so it may be considered invalid (if your policy requires all certificates on the certification path to comply with 5280)

> shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Java.

Who's "you"?
If I'm implementing an RP, I should accept all certificates (and paths) that comply with current standards, and also with the certificates that are "out there" if broken certificates are out there in significant numbers.
If I'm a CA, I should issue certificates that comply with RFC 5280, and probably refrain from using features that don't work on my target RPs. If that means that nameConstraints as in RFC 5280 are currently unusable that's a problem, because the constraints that it provides are now seen as needed.

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Apr 2012 00:41:24 +0200 (MEST)

>  - Comply and get the organizational subCA-signed certificates rejected by iOS

So is Mozilla going to purge the Equifax TrustAnchor because it signed
a GoogleCA organizational cert without critical name constraints?
.. or require them to revoke it an re-issue with name constraints
for ~200 DNS Domains?  I believe Microsoft is also operating an
organizational CA below one of the "well-known" roots without
name constraints.  And those are the two that I happen to know,
there are probably more of them out there.

> They probably will. But a certification path that contains such a
> certificate is not compliant with RFC 5280, so it may be considered
> invalid (if your policy requires all certificates on the certification
> path to comply with 5280)

You're misreading rfc5280.  A subCA cert with name constraints that is
marked non-critical SHOULD be accepted by RPs per rfc-5280.

What is non-compliant is the "CA issuing procedure", but that is irrelevant
to certificate path validation conforming to rfc5280.

> If I'm implementing an RP, I should accept all certificates (and paths)
> that comply with current standards, and also with the certificates that
> are "out there" if broken certificates are out there in significant
> numbers.
> If I'm a CA, I should issue certificates that comply with RFC 5280,
> and probably refrain from using features that don't work on my target
> RPs. If that means that nameConstraints as in RFC 5280 are currently
> unusable that's a problem, because the constraints that it provides
> are now seen as needed.

Correct, name constraints as "envisioned" by rfc5280 are unusable,
in case that you find yourself unable to ignore that invalid MUST.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Apr 2012 02:07:19 +0300

> there are probably more of them out there.

That is an idea that Mozilla is thinking about. Not purge Equifax for what they have done, but require them to use critical name constraints in the future.

> marked non-critical SHOULD be accepted by RPs per rfc-5280.

The RFC is silent about non-critical nameConstraints, but I guess it doesn't say that it should be rejected. So requiring that the certificates be issued according to the profile in RFC 5280 is not a requirement of RFC 5280, but it may be policy. 

> in case that you find yourself unable to ignore that invalid MUST.

Would we be having this discussion if iOS did not reject critical nameConstraints?  If all popular browsers processed them correctly, would you still claim they were unusable?

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Apr 2012 01:49:10 +0200 (MEST)

Yoav Nir wrote:
> 
> Would we be having this discussion if iOS did not reject critical
> nameConstraints?  If all popular browsers processed them correctly,
> would you still claim they were unusable?

Yes.  Because the name constraints relevant for browsers would
be those applying to subjectAltNames, and support for name constraints
on subjectAltNames is purely optional.  So some conforming implementations
would reject certificate paths with such certs in them, some less anal
implementations would ignore the constraints in-spite of being marked
critical, and subCAs could still evade the constraints by issuing
certs with only CN-IDs and no subjectAltNames...

Whether a feature is usable is determined by the level of non-interoperability
the use of that feature creates.

An attitude "if it works in the most recent releases of the 5
most-used browsers" seems like a bad idea.

We do have customers (running web shops) that care about continued
interop with MSIE version 6, because the amount of their customers
still using that browsers is non-marginal and they do not want to
risk lost sales trying to force their customers to upgrade their
clients.

If Mozilla would adopt a policy of the kind that you're describing,
it would probably turn away users of that browser, or cause them
to dig in on a version of the browser where things still work.
A non-marginal amount of users seems to prefer FF 3.6.x to any of
the update-crazy successors already.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 4 Apr 2012 20:47:03 -0400

This is quite silly conversation. RP should NOT reject certificate because the criticality flag was not per the standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, April 04, 2012 5:48 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

On Apr 5, 2012, at 12:16 AM, Martin Rex wrote:

> The name constraints will _not_ appear in RootCA certs (=trust 
> anchors), and probably _neither_ in the subCAs directly below the 
> rootCAs, but rather in organizational subCAs signed by subCAs of RootCAs.

> PKI software that rejects CA certs with name constraints that are 
> _not_ marked critical can be considered broken (because it is _not_ 
> listed as something to check when processing a cert in a certification 
> path in rfc5280 section 6, and rfc5280 explicitly discourages making 
> other conformance checks on attributes from

Who's "you"?

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 4 Apr 2012 20:49:17 -0400

The RFC does not require you to reject a certificate because name constraint was marked non critical.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, April 04, 2012 7:07 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

On Apr 5, 2012, at 1:41 AM, Martin Rex wrote:

> Yoav Nir wrote:
>> 
>> Martin Rex wrote:
>>> 
>>> Yoav Nir wrote:
>>>> 
>>>> It would force them to choose between not working on Firefox and 
>>>> not working on iOS. Tough call, and only Apple can solve it.
>>> 
>> - Not comply and get removed from Mozilla's trust anchor store - 
>> breaking compatibility with Firefox for the root CA
> .. or require them to revoke it an re-issue with name constraints for 
> ~200 DNS Domains?  I believe Microsoft is also operating an 
> organizational CA below one of the "well-known" roots without name 
> constraints.  And those are the two that I happen to know, there are 
> probably more of them out there.

>>> listed as something to check when processing a cert in a 
>> invalid (if your policy requires all certificates on the 
>> certification path to comply with 5280)
> 

> 
> What is non-compliant is the "CA issuing procedure", but that is 
> irrelevant to certificate path validation conforming to rfc5280.
> 
> 
>> 
>>> dozen independent PKI implementations (and different releases 
>>> thereof) rather than just looking only at the most recent 
>>> implementations shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Java.
>> 
>> Who's "you"?
>> If I'm implementing an RP, I should accept all certificates (and 
>> paths) that comply with current standards, and also with the 
>> certificates that are "out there" if broken certificates are out 
>> there in significant numbers.
> Correct, name constraints as "envisioned" by rfc5280 are unusable, in 
> case that you find yourself unable to ignore that invalid MUST.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 13:54:50 -0400

>to certificate path validation conforming to rfc5280.

yes, 5280 does not mandate that Rps enforce constraints imposed on CAs. Howver,
I am aware of at least one implementation that does enable an RP to check for
5280 CA compliance :-).

>in case that you find yourself unable to ignore that invalid MUST.

nonsense. name constraints can be used in any PKI where there there
are clear lines of authority for issuing certs relative to a name 
space.  The fact that the public TTP trust model, at the top, does 
not meet that criterion,
is merely an indication of a collision between a business model and technology.
Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 13:56:46 -0400

At 8:47 PM -0400 4/4/12, Santosh Chokhani wrote:
>This is quite silly conversation. RP should NOT reject certificate 
>because the criticality flag was not per the standard.

I think the technically correct statement replaces "should not" with 
"need not."

Steve

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Apr 2012 22:40:39 +0200 (MEST)

> I think the technically correct statement replaces "should not" with 

The behaviour standardized by rfc5280 is equivalent to SHOULD NOT:

   rfc5280 section 6.1 Basic Path Validation, 2nd paragaph:

   http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Apr 2012 19:31:23 -0400

Santosh,

This is the second time that you have tried to pull rank on other
members of the working group in the past month. I should point out
that in my view you are really not qualified to pull rank as you
appear to believe you are entitled.

If you cannot treat others here with respect I suggest that the chairs
inform you that your contributions are no longer desirable.

The security issue here is that we cannot issue a certificate that
does not work with the deployed Apple clients. Thus the only way it is
possible to use the name constraints is to make them non-critical.
Therefore this is what we are going to be doing.

The proposal is to fix an obvious bug in the specification to meet a
real world operational requirement.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Apr 2012 19:36:47 -0400

More importantly, nobody made the IESG nor the PKIX working group the
authority for the industry.

The WG only advised by consent and that consent has now been
withdrawn. This particular argument has proved to be the last straw
for many.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Apr 2012 20:00:50 -0400

Let us start from the beginning and forget the specification for a moment.

The objective here is to reduce risk exposure in the deployed Internet
PKI infrastructure by constraining the issue capabilities of
enterprise CAs. Any proposal must be fully backwards compatible with
deployed code.

Given those constraints it is obvious that no extensions intended to
support the name constraints can be marked critical. Thus there are
three options:

1) Develop a new extension that duplicates the functionality of the
existing PKIX extensions but does not require being marked critical.

2) Use the existing extension and modify the PKIX specifications to
remove the requirement to mark the extension critical.

3) Use the existing extension and ignore the opinion of the PKIX working group.

(1) is not an option so the choice for the WG is between (2) and (3).

Now I should point out that if the WG wants to retain any influence in
the industry whatsoever it should have a REALLY AMAZINGLY IMPORTANT
REASON for forcing the industry to choose option 3.

Perhaps what we should do is to shut down PKIX, wait for CABForum to
fix the specs and then spin up a new WG some time in the future to
write up the new system. But the current arrangement is clearly not
working.

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Apr 2012 02:04:11 +0200 (MEST)

Stephen Kent wrote:
> not meet that criterion, is merely an indication of a collision
> between a business model and technology.

To me it appears that name constraints might be underspecified.
>From how I understand the design of X.509, subject Name and subjectAltNames
are alternative unique representations of the name of the subject.
So in order to use name constraints securely, all name forms present
in a cert would have to be subject to constraints, and all unconstrained
name forms would have to be unconditionally ignored, otherwise the
constraints could be evaded.

looking at this example structure
(using "aaaa" instead of "com" to avoid collisions with mapped DNS space)

                     well-known trust anchor
                               |
                               |
                  CN=premium subCA, O=pubTC, C=Y
                         public subCA
                       /              \
                      /                \
                     /                  \
  CN=org-CA, OU=Foo, O=pubTC, C=Y    CN=org-CA, OU=Bar, O=pubTC, C=Y
        organizational subCA FOO      organizational subCA BAR
        with name constraint on       with name constraint on
         dNSName SAN "foo.aaaa"        dnsName SAN "bar.aaaa"

What is lacking in this example is name constraints on the subject name
(DirectoryName).  Without it, certain certificate processing, based on
an unconstrained name forms, can evade the name constraints.

e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert)
with a subject DName of the Foo org-CA and using it to fabricate CRLs
(with an AIA extension in the CRL, distinguishing the "forged"
CRL signer cert from the real Foo org-CA cert by including and
AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension
that RPs expect) ?

Such a concoction would fulfil the "CRL Signer cert must validate
under the same trust anchor" requirement.  And PKIX software that
is bold enough to perform forward path discovery based on AIA for the
CRL signer might be tricked to accept CRLs forged by org-CA Bar during
validation of certs issued by org-CA Foo, I assume.

Another problem arises from the fact that there may exist SANs
(such as KRB5PrincipalName  http://tools.ietf.org/html/rfc4556#page-16)
or the MS-UPN SAN for which name constraints have either not been
defined or not been published, so that support for name constraints
for such names is fairly unlikely exist in the installed base,
yet the only reason to put alternate subject names into certs is to
use them (and exclusively) for authentication.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 Apr 2012 20:48:33 -0400

PHB,

You should do what you deem appropriate.

My recommendation is for 5280 and those who get security.

BTW, this is not the second time, it is umpteenth time and third time in recent memory.  I suppose you rather forget about that e-mail about EC DH parameters asserted by a cross certified CA.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Thursday, April 05, 2012 7:31 PM
To: Santosh Chokhani
Cc: [email-masked]; Erwann Abalea; [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

This is the second time that you have tried to pull rank on other members of the working group in the past month. I should point out that in my view you are really not qualified to pull rank as you appear to believe you are entitled.

If you cannot treat others here with respect I suggest that the chairs inform you that your contributions are no longer desirable.

The security issue here is that we cannot issue a certificate that does not work with the deployed Apple clients. Thus the only way it is possible to use the name constraints is to make them non-critical.
Therefore this is what we are going to be doing.

The proposal is to fix an obvious bug in the specification to meet a real world operational requirement.

On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani <[email-masked]> wrote:
> Name

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Apr 2012 20:50:28 -0400

The intention of the critical flag was to provide a mechanism that
could be used to implement extensions that required backwards
compatibility to be broken. That is all.

Marking an extension critical does not mean 'important'. An extension
can be marked non critical and be very very important.

Nor should applications make any use of the critical flag other than
to reject certificates marked critical that they do not understand. If
the application understands the extension the setting of the
criticality flag MUST NOT affect the semantics of the extension.

I do not care what the specification documents say on the matter,
really I don't. If the specifications say that criticality means
important then they are stupid and wrong and should be fixed.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Apr 2012 21:01:45 -0400

Santosh,

As I stated in my message to the ADs explaining the reason why we are
breaking from the PKIX work, your role has been corrosive here. I do
not mind people attacking me, but I see you all behaving like a bunch
of high school heathers attacking anyone else you disagree with in the
same terms.

I don't particularly see that I have a need to justify my credentials
to you. In fact I am really not aware of any substantial contribution
you have made to the field, positive or negative. I value the opinion
of the people I have worked with, a list that includes multiple Turing
award winners besides many other notable contributors to the field. I
do not value the opinion of people who attempt to preen themselves by
putting other down.

You are certainly not the only person that gets security here, not by
a long way. In fact I would suggest that anyone who argues in the
fashion you do, through appeals to their own authority are the people
who 'don't get it'.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 5 Apr 2012 21:31:11 -0400

Martin:

        Actually, the way in which name constraints are most clearly 
underspecified is their handling of x400Address.  Implementers MUST be 
able to process one of the GeneralName forms, and SHOULD be able to 
process four more.  Three of the remaining four forms are explicitly 
excluded from this specification, but there's no reference to how 
x400Address should be processed (if anyone still uses it) although there's 
a SHOULD NOT for the CA putting in a name constraint of that form.
        I think that an RP is conformant if it simply rejects any 
certificate whose subject Alt Name has a member of type x400Address, if 
either permitted_subtrees or excluded_subtrees have any member of type 
x400Address during the processing of section 6.1.3 B and C.  I have no 
idea whether it's intended that having permitted_subtrees contain 
organization-name but not teletex-organization-name means that names with 
teletex-organization-name (an Extension attribute) should be banned.  I 
suspect that it is, and I wonder how many RP's enforce anything like that.
        In your examples, you'd have to restrict the name forms to ones 
covered by permitted subtrees.  Otherwise, CA's could put in a single 
excluded subtree of each name form, covering entities which no longer 
exist or an IP which can't be routed.  Those are constraints, but they 
protect very little.

Tom Gindin

P.S. - The opinions above are mine, and not necessarily those of my 
employer.

From:   Martin Rex <[email-masked]>
To:     [email-masked] (Stephen Kent), 
Cc:     [email-masked]
Date:   04/05/2012 08:04 PM
Subject:        Re: [pkix] Proposal: Change the Criticality Requirement of 
Name
Sent by:        [email-masked]

                     well-known trust anchor
                               |
                               |

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Fri, 6 Apr 2012 08:42:43 +0300

Hi Phil

> Therefore this is what we are going to be doing.

I understand your position, and I would probably do the same if I were making decisions for a CA. However, I object to this treating of deployed iOS clients as some part of nature that we just have to live with. Apple issues regular updates to iOS that get pushed to all users. Those clients are not unfixable. If Apple was willing to fix this, then the RFC 5280 would still be quirky, but we wouldn't be having this conversation.

> real world operational requirement.

I think the bug is in iOS. There is a large group of people here who believe that breaking the BC with non-compliant browsers is intentional and a good thing. 

I agree that the current specification is a barrier to deployment. Fortunately for you, there is an easy way to work around it in this specification.

Yoav

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 6 Apr 2012 07:45:03 -0400

PHB,

I understand why you are bothered.

My advice to you is focus on what is being said and not on who is saying it.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Thursday, April 05, 2012 9:02 PM
To: Santosh Chokhani
Cc: [email-masked]; Erwann Abalea; [email-masked]; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

As I stated in my message to the ADs explaining the reason why we are breaking from the PKIX work, your role has been corrosive here. I do not mind people attacking me, but I see you all behaving like a bunch of high school heathers attacking anyone else you disagree with in the same terms.

I don't particularly see that I have a need to justify my credentials to you. In fact I am really not aware of any substantial contribution you have made to the field, positive or negative. I value the opinion of the people I have worked with, a list that includes multiple Turing award winners besides many other notable contributors to the field. I do not value the opinion of people who attempt to preen themselves by putting other down.

You are certainly not the only person that gets security here, not by a long way. In fact I would suggest that anyone who argues in the fashion you do, through appeals to their own authority are the people who 'don't get it'.

On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani <[email-masked]> wrote:
>>> How could PKIX be in violation of anything by requiring the 
>>> extension to be critical, and why the RFC2119? Is PKIX also in 
>>> violation of
>>> RFC2119 when requiring the serial number to be a positive integer 
>>> not longer than 20 octets?
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 08:12:09 -0400

On Fri, Apr 6, 2012 at 1:42 AM, Yoav Nir <[email-masked]> wrote:
> I understand your position, and I would probably do the same if I were making decisions for a CA. However, I object to this treating of deployed iOS clients as some part of nature that we just have to live with.

Well tough Cnut, that is the problem that has to be solved.

PKIX was made for the Internet, not the Internet for PKIX.

>Apple issues regular updates to iOS that get pushed to all users. Those clients are not unfixable. If Apple was willing to fix this, then the RFC 5280 would still be quirky, but we wouldn't be having this conversation.

Those wont reach all the users. Not acceptable. We can only turn on
the constraints if there is 100% backwards compatibility.

> I think the bug is in iOS. There is a large group of people here who believe that breaking the BC with non-compliant browsers is intentional and a good thing.

You are entitled to your opinion. But is is completely nuts.

What you are saying is that the opinion of this group matters more
than the hundreds of thousands of Internet users that you are
proposing to break their clients for no good reason other than to
massage the collective ego of this group.

That is not a viable approach.

> I agree that the current specification is a barrier to deployment. Fortunately for you, there is an easy way to work around it in this specification.

Yes, ignore PKIX and the IETF and set up our own standards
organization in which the views of the stake holders like the end
users actually matter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 08:37:20 -0400

How people were saying was rather more instrumental in the fork than
what they were saying. I can't remember the last time I came here with
a proposal and someone said 'hey how can we achieve that better'.
Instead the response is always 'well thats not the way the spec works,
tough noogies for you'.

If you understood why I was bothered you would apologize to me and the
group for your behavior.

Participation in PKIX has shrunk because people just don't like
interacting with a group that is considered to be needlessly
obstructionist and sinks to personal insults to drive people away.

I do not pull rank except when I see others doing so.

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Apr 2012 08:42:52 -0400

Phillip:

All IETF standards are voluntary.  While the mission of the IETF is to make the Internet work better, let me remind you that no one is “in charge” of the Internet.  Rather, many people cooperate to make the Internet work.

Each IETF participant brings a unique perspective of the Internet, and that diversity is quite visible in this thread.  As usual diversity sometimes makes it difficult to reach consensus.  In my experience, respectful discussion is the best way to understand the perspective of each participant.

When rough consensus is achieved, there will probably be some people that are not completely happy.  The IETF process does not seek unanimous consensus.  Once rough consensus is achieved, in my experience, the outcome is better, more clearly explained, and more strongly supported than the initial position of any participant.  And, this support is what leads to wide deployment.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Apr 2012 08:46:50 -0400

RFC 5280 is pretty clear about the processing.  Recognized extensions cannot be ignored, regardless of the criticality.

RFC 5280 says:

   ...  Each extension in a
   certificate is designated as either critical or non-critical.  A
   certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized.

Russ

---

From: Carl Wallace <[email-masked]>
Date: Fri, 06 Apr 2012 08:52:30 -0400

>Instead the response is always 'well thats not the way the spec works,

Are you serious?  You came here with a proposal to modify OCSP (while
breaking backwards compatibility) just a few weeks ago.  You offered no
spec, just email. There was interest.  Discussion followed.  Several ideas
were floated (including alternatives that preserved backwards
compatibility).  Does such discussion not fall into the 'hey how can we
achieve that better' bucket?  It would seem to.  Did you welcome such
discussion?  No, you had a fit.  Much like this one.  This problem is even
easier to deal with.  If Apple's implementation is broken (recall the
original comment came from someone who had not tested this and was relying
on hearsay) they should fix it.  In the meantime, add something to the
Mozilla policy to allow a grace period of non-compliance with 5280 so you
can work around the problem.  However, the bugs might get fixed faster if,
for example, Android is working fine and iOS is not.

>>breaking from the PKIX work, your role has been corrosive here. I do not
>>mind people attacking me, but I see you all behaving like a bunch of
>>high school heathers attacking anyone else you disagree with in the same
>>terms.
>>
>>
>>you have made to the field, positive or negative. I value the opinion of
>>the people I have worked with, a list that includes multiple Turing
>>award winners besides many other notable contributors to the field. I do
>>not value the opinion of people who attempt to preen themselves by
>>putting other down.
>>
>> You are certainly not the only person that gets security here, not by a
>>long way. In fact I would suggest that anyone who argues in the fashion
>>you do, through appeals to their own authority are the people who 'don't
>>get it'.
>>
>>
>>
>>
>>
>>> BTW, this is not the second time, it is umpteenth time and third time
>>>in recent memory.  I suppose you rather forget about that e-mail about
>>>EC DH parameters asserted by a cross certified CA.
>>>
>>>members of the working group in the past month. I should point out that
>>>in my view you are really not qualified to pull rank as you appear to
>>>believe you are entitled.
>>>
>>>> Requiring a CA to always make name constraints critical will very
>>>>probably impair/break interop with implementations that do not support
>>>>that particular type of name constraints.
>>>>
>>>> The discussion of the purpose of both critical and non-critical uses
>>>>of a constraints extension is much more reasonably explained here:
>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 09:57:56 -0400

I am absolutely serious.

Arguing that it is more important to preserve the spec than solve real
world problems without breaking stuff is not constructive comment in
my view.

My proposal was totally backwards compatible. Just define an extension
to allow the OCSP servers that can to report 'certificate not issued'.
The response was that this should be done using SCVP, a protocol the
industry has no interest in supporting.

Apple's implementation is 100% compliant. They are entitled to not
implement the feature. As Russ also points out, marking an extension
critical does not affect the semantics.

So what is the reason for not changing the spec here to enable the
extension to be used? I dont see you even bother to try to answer
that. You just assume that the simplest course is to do as little to
the spec as possible.

The driving function here is that Mozilla are proposing making use of
name constraints mandatory in enterprise CAs within the next few
months. There is a clear industry consensus that this is a good idea
provided we can arrive at an understanding of the consequences for
deployed code and we break as little as possible.

I would have hoped that the view of the WG was 'hey we want people to
use name constraints, how can we make that work'. Instead we have you
and others trying to make a point of principle on an arbitrary detail
of the specification.

I still have not heard anyone give a good reason for marking the
extension critical in this application.

What is going to happen here is:

1) Mozilla makes name constraints a requirement
2) CAs deploy certs with the constraints marked non-critical
3) The PKI specifications are eventually corrected to match practice.

The only option here is what the specifications end up being called.
If the WG learns from this outcome and becomes more reasonable then it
is possible that we can come back into sync. But if no lessons are
learned then we are going to end up with two PKIX specifications, the
IETF one and the one that matters.

---

From: Carl Wallace <[email-masked]>
Date: Fri, 06 Apr 2012 10:27:52 -0400

>industry has no interest in supporting.

There were many responses in that thread, including some that supported
your proposal and some that offered alternatives in an effort to improve
upon it.  My point was that your claim below about there never being
constructive discussion is false.  There was plenty of constructive
discussion.  There was no attempt to last call your email proposal.

>critical does not affect the semantics.

This is simply false.  How is Apple's implementation compliant with
section 6 or with the next to last paragraph of section 4.2?  The
requirements for name constraints are not new.  Excellent test suites have
been available for many years.  Many implementations get it more or less
right.  

>that. You just assume that the simplest course is to do as little to

I'm indifferent to changing the spec w.r.t. criticality since, as you
note, implementations that recognize the extension must process it anyway.
 I don't think the legalistic RFC2119 arguments are the least bit
persuasive and I think it's a slippery slope to start editing the spec to
accommodate incomplete or incorrect implementations.  Where is the harm in
announcing the policy change, allowing a grace period of non-compliance
and working with vendors to ensure name constraints are enforced in
more/most cases?  The aim is to make sure name constraints are enforced,
right?

>deployed code and we break as little as possible.

Understood and probably long overdue.

>3) The PKI specifications are eventually corrected to match practice.

Assuming the aim is for name constraints to actually be enforced, 3) might
be "Applications add support for enforcing name constraints."  That the
internet PKI has been operated with minimal constraints so long is the
problem.  Carving out room to continue lousy practices is not really the
answer.    

>IETF one and the one that matters.

Nonsense.  There are far more than two "PKIX specifications" kicking
around.  Else we'd not be having this discussion at all.

>>>On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani
>>><[email-masked]>
>>>wrote:
>>>> PHB,
>>>>
>>>>not
>>>>of
>>>>do
>>>>a

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 6 Apr 2012 10:47:03 -0400

Phill,

Different assumptions are (as usual) the source of disagreement
regarding conclusions drawn.  Your assumptions are as you stated below.
Mine are:

1) The objective here is to reduce risk exposure in the Internet PKI
infrastructure built according to the specifications.  (In the real
world there will always be systems that don't meet spec; the purpose of
a spec is to support unambiguous testable criteria for what it means to
meet it).

2) Any proposal must specify conditions that support secure
interoperability.  (Systems that do not meet those conditions are not
guaranteed to interoperate, but the steps needed to become interoperable
are clearly stated).

In the real world of U.S. highways, the speed limit spec is 55 mph.
That spec is clearly incompatible with the behavior of a majority of
drivers.  Using your assumptions, any posted speed limit must be
compatible with driver behavior (73? 85? 90?).   Under my assumptions,
posted speed limits are based on highway safety (and other more
political) considerations.  The spec (posted speed limit) makes it
unambiguously clear that a driver going 56 mph is non-compliant.  But
jurisdictions have the freedom to interpret the spec as they choose,
only enforcing violations that exceed their thresholds (5 miles over?
10?).  Automated cameras in DC are set to trigger only at 12mph above
the posted speed.

There are no internet police and no mechanism to enforce PKIX standards.
Compliance is completely voluntary, based on a desire to interoperate.
For that reason, the standards should specify what is necessary to
interoperate securely, and implementations can make exceptions to the
standard whenever necessary to interoperate with other implementations
that do not meet the standard.

My fundamental assumption is that PKIX should document correct behavior,
not document existing, incorrect behavior.

Dave

-----Original Message-----
From: Phillip Hallam-Baker

Let us start from the beginning and forget the specification for a
moment.

The objective here is to reduce risk exposure in the deployed Internet
PKI infrastructure by constraining the issue capabilities of enterprise
CAs. Any proposal must be fully backwards compatible with deployed code.

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 6 Apr 2012 10:52:23 -0400

Tom,

In my reading 5280 is reasonably clear.  It could always be made clearer.

I would consider the following implementations secure:

1.  If the name constraint is critical and you do not recognize one or more name forms, reject the certificate.

2.  If the name constraint is critical and you do not recognize one or more name forms, accept the certificate if none of the unrecognized name forms appear in the certification path, else reject the certificate.  (this is against the RFC, but I see no harm)

3,  If the name constraint is non-critical and you do not recognize one or more name forms, accept the certificate.

I agree that there is some ambiguity in terms of application behavior if you assume that application behavior must be the same regardless of criticality if an extension is recognized.  This is due to inability to process all name forms.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Gindin
Sent: Thursday, April 05, 2012 9:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

        Martin:

        Actually, the way in which name constraints are most clearly underspecified is their handling of x400Address.  Implementers MUST be able to process one of the GeneralName forms, and SHOULD be able to process four more.  Three of the remaining four forms are explicitly excluded from this specification, but there's no reference to how x400Address should be processed (if anyone still uses it) although there's a SHOULD NOT for the CA putting in a name constraint of that form.
        I think that an RP is conformant if it simply rejects any certificate whose subject Alt Name has a member of type x400Address, if either permitted_subtrees or excluded_subtrees have any member of type x400Address during the processing of section 6.1.3 B and C.  I have no idea whether it's intended that having permitted_subtrees contain organization-name but not teletex-organization-name means that names with teletex-organization-name (an Extension attribute) should be banned.  I suspect that it is, and I wonder how many RP's enforce anything like that.
        In your examples, you'd have to restrict the name forms to ones covered by permitted subtrees.  Otherwise, CA's could put in a single excluded subtree of each name form, covering entities which no longer exist or an IP which can't be routed.  Those are constraints, but they protect very little.

Tom Gindin

P.S. - The opinions above are mine, and not necessarily those of my employer.

                     well-known trust anchor
                               |
                               |

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 6 Apr 2012 12:00:40 -0400

Marking it critical has nothing to do with a cargo-cult desire to
worship a spec without making any changes.  It has to do with secure
operation of the Internet (where both "secure" and "operate" are
important).

If 100% of CAs and 90% of RPs follow the existing spec calling for
marking the extension critical, a CA that issues a forged certificate
(for a server in some other CA's authorized namespace), 90% of RPs will
correctly detect the forgery and 10% will correctly reject the
certificate and ask the user for guidance because they cannot determine
whether it is forged or not.

With the same RP population, if 100% of CAs mark the extension
non-critical, 90% of RPs will detect the forgery because they can, and
10% of RPs will accept the forged certificate without any hint to the
user that something fishy is going on.

In my book "correct" behavior is detecting a forgery and asking the user
whether to proceed anyway.  That is the technical, not religious, reason
for marking the extension critical.

When you change the RP percentage to 40% non-compliant applications from
a sexy, popular supplier, it changes the market dynamics for whether CAs
should mark the extension critical.  CAs have good justification for
weighting "operate without inconveniencing casual users" more highly
than "secure" in that situation.  But it does not change the
specification of the correct way to achieve both interoperability and
security.

Dave

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 12:54:47 -0400

There are two approaches to a slippery slope. One is crampons the other is skis.

I have picked skis for all of us. See you at the bottom.

---

From: Carl Wallace <[email-masked]>
Date: Fri, 06 Apr 2012 13:16:01 -0400

Indeed.  Enjoy the race.

On 4/6/12 12:54 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>>Behalf
>>>>>>>> Of Martin Rex
>>>>>>>>>by

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 06 Apr 2012 13:49:29 -0400

Santosh,

Actually, this not against the RFC:

    If a name constraints extension that is marked as critical
    imposes constraints on a particular name form, and an instance of
    that name form appears in the subject field or subjectAltName
    extension of a subsequent certificate, then the application MUST
    either process the constraint or reject the certificate.

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 6 Apr 2012 13:58:18 -0400

David,

Thanks for correcting me.  I read the same language, but must have skipped over part of the sentence.

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Friday, April 06, 2012 1:49 PM
To: Santosh Chokhani; [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 14:40:58 -0400

As has been pointed out by Russ the specification requires that the
client process all extensions that it understands regardless of
whether they are marked critical or not.

The only function of the critical flag is to specify cases in which it
is desirable for a client to break rather than accept a certificate it
may not understand correctly. Since we want the opposite behavior here
there is no reason to mark the extension critical.

So your example 3 describes a client that is non-compliant with the
specification.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 14:44:23 -0400

The function of the critical bit is to state cases where it is better
to break interoperability than accept a certificate that may be
misinterpreted.

This condition does not apply here. Ergo the bit shall not be set.

Now maybe if you ever get to STANDARD status then you can wave it as
us and tell us we are wrong but until then all you have is a Request
For Comments and our comment is we intend to do what makes sense, not
what is written in the DRAFT.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2012 15:14:51 -0400

As I read the specifications it appears to me that they already
mandate precisely the desired behavior of relying apps:

* If the extension is marked critical and not understood, reject the cert

* If the extension is understood and present it MUST be processed [or
the cert rejected].

The only part that there is a problem with is the instruction that the
name constraints MUST be marked critical. Drop that down to a SHOULD
and the problem goes away completely.

Note that while a client app could in theory reject a cert if there is
a name constraint present and not marked critical that this is not a
requirement of the spec. The fact that a cert is not compliant with
the PKIX profile does not mean it has to be rejected.

As Martin points out, this particular MUST is not motivated by a
security requirement, nor is it motivated by an interoperability
requirement.

The only valid reason for not changing the spec that I can see is that
the group would like to avoid the IETF overhead that would incur. So
now we have got to the point where a major browser provider is going
to mandate a non-PKIX compliant profile as a pre-condition for
inclusion in their root program.

I am not trying to persuade here. I am merely trying to impress upon
you all that what is about to happen is entirely your fault and that
being unreasonable has consequences.

On Fri, Apr 6, 2012 at 1:49 PM, David A. Cooper <[email-masked]> wrote:
>> 2.  If the name constraint is critical and you do not recognize one or
>> more name forms, accept the certificate if none of the unrecognized name
>> forms appear in the certification path, else reject the certificate.  (this
>> is against the RFC, but I see no harm)
>
>
> Santosh,
>

---

From: Max Pritikin <[email-masked]>
Date: Fri, 6 Apr 2012 16:09:51 -0600

Why isn't it the CA vendor's responsibility to decide if the Name Constraints is "critical" or just "best effort"? Why is this codified in the standard?

I absolutely agree with the perspective that a "best effort" name constraint is weak-sauce, particularly when a lot of clients are understood not to actually check this field. But isn't it the responsibility of the CA vendor, or maybe the CABF, to decide what makes the most sense in their problem space? Just because I wouldn't want to implement a "fail-open" solution doesn't mean they don't have every right to reduce their security. Especially since their alternative is to not use name constraints at all (aka "always fail-open with no recourse for improvement"). 

It sounds like the main concern about non-critical name constraints is that they're weak and that their use is a concession to weak clients. 

Even if true I find it difficult to argue with the idea that adding them is a "step in the right direction". And once a significant number of products are checking these constraints it becomes possible to publicly humiliate the vendors that don't properly check this field -- because those venders have demonstrable security vulnerabilities.

I'm sure I'm missing something. What is it?

Thanks,

- max

---

From: Tom Gindin <[email-masked]>
Date: Fri, 6 Apr 2012 18:43:55 -0400

Dave:

        That's not the actual CA behavior which is likely, or which we've 
observed to date.  The alternatives are closer to having 20% of CA's mark 
it critical and 80% omit it with the current rules, while 10% mark it 
critical, 50% mark it non-critical, and 40% omit it with my proposed 
change.  If you assume that no CA which would prefer to emit a 
non-critical constraint chooses to omit the constraint entirely when 
criticality is required, then requiring criticality improves global 
security.  I consider that assumption to have been disproved by 
experience.
        As an example, the trust store of one of my workstations has 
collected 28 intermediate certificates.  Only four of them have name 
constraints extensions - two with excluded subtrees, and two others with 
permitted ones.  Every entry in those subtrees is a directory name 
referring to an entity under the control of the US Department of Defense. 
The other 24 intermediates don't use name constraints.

Tom Gindin

From:   "Kemp, David P." <[email-masked]>
To:     <[email-masked]>, 
Date:   04/06/2012 12:01 PM
Subject:        Re: [pkix] Proposal: Change the Criticality Requirement of 
Name
Sent by:        [email-masked]

Dave

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Apr 2012 09:40:29 +0300

> specification of the correct way to achieve both interoperability and

I disagree. The E in IETF in engineering. A spec that considers only the "secure" and not the "operate without inconveniencing casual users" is bad engineering. Engineering has to consider the operating environment and constraints of those who need to follow the spec.

The requirement to mark certain extensions as critical means that you cannot use those extensions with relying parties that do not support those extensions. This misses the operating environment of commercial CAs, that have to work with all deployed browsers, so it's not good engineering. Until now, they just didn't use name constraints. Mozilla is the first to require name constraints of the CAs, and they don't mind if the extension is not critical (because they understand it). Why should we think we know better than those making the requirements?

I think in this particular case, it could be fixed without changing the spec, because there's only one implementation out there that fails, and that one regularly pushes updates to all users. I would similarly be not concerned about working around a bug in Chrome or recent Firefox, because those also update automatically. I *would* be concerned about working around IE on WinXP, or Firefox 3.5 or Safari on MacOS prior to the current version, because those don't get updated. But iOS?  Apple could fix it tomorrow.

Yoav

---

From: "Ryan Sleevi" <[email-masked]>
Date: Sat, 7 Apr 2012 00:49:52 -0700

>
>  I think in this particular case, it could be fixed without changing the
>  spec, because there's only one implementation out there that fails, and
>  that one regularly pushes updates to all users. I would similarly be not
>  concerned about working around a bug in Chrome or recent Firefox, because
>  those also update automatically. I *would* be concerned about working
>  around IE on WinXP, or Firefox 3.5 or Safari on MacOS prior to the current
>  version, because those don't get updated. But iOS?  Apple could fix it
>  tomorrow.
>
>  Yoav

Just to chime in here on the whole criticality thing:

While Apple's OS X (desktop) implementation will not choke if Name
Constraints is marked critical, it does not support processing name
constraints and will not enforce them - critical or not. It does not quite
implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require
that it fail processing if it does not process a critical extension
(although 5280 does).

So while we can talk at length about the intent of the critical bit, what
it means for security, and why it should be there, in practice, deployed
clients and deployed implementations will happily ignore processing these
critical extensions and carry on their merry way. While OS X will fail on
critical extensions that it does not know how to *parse*, it applies very
little to actual path building and verification, and will happily accept
critical extensions it recognizes but does not know how to *process*
without compliant or signal. Not to mention all of the many, many
scripting languages and toolsets (such as OpenSSL), which by default do
not enforce name constraints BUT, because they support parsing them, will
not raise any signals.

The actual sources for OS X's trust module can be found at
http://opensource.apple.com/, and is named libsecurity_apple_x509_tp. The
core function is called tp_policyVerify, located in lib/tpPolicies.cpp.

In the spirit of 3280 -> 5280, which saw both policy constraints and
policy mappings go from MUST to RECOMMDED criticality, I would see name
constraints do the same. Further, I support the assertions that Phillip
Hallam-Baker has made thus far, and strongly believe that name
constraints, as measured by the market of RPs and CAs that most Internet
users interact with, have failed to provide meaningful security by being
marked critical. As Yoav has pointed out, Name Constraints applying to
subjectAltNames is optional for RPs, even within RFC 5280, so that is yet
another failing of actually usable security.

If the opponents to making it non-critical believe that requiring they be
marked critical somehow leads to more secure RPs, than they should be
disabused of the notion, as it simply does not match the reality of the
RPs today. Requiring it be critical will break some clients entirely,
while others will continue to happily (and silently) ignore them with
relation to subjectAltNames, and thus their actual value for Internet PKI
will be diminished.

Meanwhile, the opportunity to actually begin deploying name constraints
will be missed, because of the staunch refusal to consider making it
non-critical. In the worst case, a non-critical name constraint offers no
worse security today than the unconstrained sub-CAs that any major CA is
issuing. In the best, and more likely, case, non-critical name constraints
afford better security for the clients/RPs that implement them (and apply
them to the subjectAltName), which allows market forces such as users and
negative publicity to name and shame the non-implementing vendors into the
wonderful world of RFC 5280 and half-way sane implementations.

I suspect and support the argument that browsers and other root store
operators will simply require non-critical name constraints, and in the
end, the only casualty will be the idea that implementing RFC 5280 is
needed to operate on the Internet PKI - or even a good idea. Which will
be, understandably, unfortunate.

Cheers,
Ryan

---

From: Erwann Abalea <[email-masked]>
Date: Sat, 7 Apr 2012 12:24:09 +0200

2012/4/7 Ryan Sleevi <[email-masked]>

> that it fail processing if it does not process a critical extension

That's nitpicking.

4.2. RFC2459/3280 say this:
-----

A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension may be ignored if it is not recognized.

-----

while RFC5280 says this:
-----

A certificate-using system MUST reject the certificate if it encounters

-----

However, in the same chapter, 3 paragraphs below, the 3 RFCs agree on this:
-----

At a minimum, applications conforming to this profile MUST recognize
the extensions which must or may be critical in this specification.
These extensions are:  key usage (see sec. 4.2.1.3), certificate
policies (see sec. 4.2.1.5), the subject alternative name (see sec.
4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints
(see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
extended key usage (see sec. 4.2.1.13).

-----

+inhibitAnyPolicy for RFC{3,5}280.

So. This implementation "recognizes" it (it can parse it), but doesn't
"process" it. Or how to take only interesting bits of a standard.
Were these implementation details responsible for non enforcing critical
basicConstraints:CA=False?

The basic path validation algorithm in RFC2459 is also clear about
nameConstraints (see 6.1, steps j and k), and the algorithm has been
extended for less confusion in RFC3280.

> not enforce name constraints BUT, because they support parsing them, will

OpenSSL 1.0.0 does enforce nameConstraints. mod_ssl, when using older
versions of OpenSSL, rejects a certificate containing a critical
nameConstraints extension.

> policy mappings go from MUST to RECOMMDED criticality,

Wrong. The criticality of:
  policyMapping went from MUST NOT to SHOULD.
  policyConstraints went from MAY to MUST.

> I would see name

And how is marking this extension non critical going to help the cause?

-- 
Erwann.

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 7 Apr 2012 09:11:01 -0400

Section 4.2 of 2459 says: " A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize".

So, the implementation you mention is not compliant with 2459.

If the RP ignores criticality, why have a debate.

This is software and not laws of physics.  Anyone can write software that even does not verify signatures.

The reason for keeping it critical is that those RP who comply with the standard are afforded the security implied by the standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Saturday, April 07, 2012 3:50 AM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

>
>  I think in this particular case, it could be fixed without changing 
> the  spec, because there's only one implementation out there that 
> fails, and  that one regularly pushes updates to all users. I would 
> similarly be not  concerned about working around a bug in Chrome or 
> recent Firefox, because  those also update automatically. I *would* be 
> concerned about working  around IE on WinXP, or Firefox 3.5 or Safari 
> on MacOS prior to the current  version, because those don't get 
> updated. But iOS?  Apple could fix it  tomorrow.
>
>  Yoav

While Apple's OS X (desktop) implementation will not choke if Name Constraints is marked critical, it does not support processing name constraints and will not enforce them - critical or not. It does not quite implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require that it fail processing if it does not process a critical extension (although 5280 does).

So while we can talk at length about the intent of the critical bit, what it means for security, and why it should be there, in practice, deployed clients and deployed implementations will happily ignore processing these critical extensions and carry on their merry way. While OS X will fail on critical extensions that it does not know how to *parse*, it applies very little to actual path building and verification, and will happily accept critical extensions it recognizes but does not know how to *process* without compliant or signal. Not to mention all of the many, many scripting languages and toolsets (such as OpenSSL), which by default do not enforce name constraints BUT, because they support parsing them, will not raise any signals.

The actual sources for OS X's trust module can be found at http://opensource.apple.com/, and is named libsecurity_apple_x509_tp. The core function is called tp_policyVerify, located in lib/tpPolicies.cpp.

In the spirit of 3280 -> 5280, which saw both policy constraints and policy mappings go from MUST to RECOMMDED criticality, I would see name constraints do the same. Further, I support the assertions that Phillip Hallam-Baker has made thus far, and strongly believe that name constraints, as measured by the market of RPs and CAs that most Internet users interact with, have failed to provide meaningful security by being marked critical. As Yoav has pointed out, Name Constraints applying to subjectAltNames is optional for RPs, even within RFC 5280, so that is yet another failing of actually usable security.

If the opponents to making it non-critical believe that requiring they be marked critical somehow leads to more secure RPs, than they should be disabused of the notion, as it simply does not match the reality of the RPs today. Requiring it be critical will break some clients entirely, while others will continue to happily (and silently) ignore them with relation to subjectAltNames, and thus their actual value for Internet PKI will be diminished.

Meanwhile, the opportunity to actually begin deploying name constraints will be missed, because of the staunch refusal to consider making it non-critical. In the worst case, a non-critical name constraint offers no worse security today than the unconstrained sub-CAs that any major CA is issuing. In the best, and more likely, case, non-critical name constraints afford better security for the clients/RPs that implement them (and apply them to the subjectAltName), which allows market forces such as users and negative publicity to name and shame the non-implementing vendors into the wonderful world of RFC 5280 and half-way sane implementations.

I suspect and support the argument that browsers and other root store operators will simply require non-critical name constraints, and in the end, the only casualty will be the idea that implementing RFC 5280 is needed to operate on the Internet PKI - or even a good idea. Which will be, understandably, unfortunate.

Cheers,
Ryan

---

From: "Miller, Timothy J." <[email-masked]>
Date: Sat, 7 Apr 2012 14:40:55 +0000

So let's see if I can summarize, since this has been a long thread and I'm still trying to think it through:

Current spec:

Operative clauses:

	If NC is present:
		- it MUST be marked critical
		- SHOULD NOT apply NC to x400Address
		- MUST NOT be empty
		- MUST only appear in a CA cert
		- minimum MUST be zero
		- maximum MUST be absent

	Implementations:
		- MUST process NC for DNs
		- SHOULD process for IP, DNS, email, and URI name types
		- MUST process NC for a matching name type if present in the chain or reject if NC is present and critical
		- MUST process minimum and/or maximum if present with any value or reject if NC is present and critical

Pseudo-operative clauses (not using RFC 2119 language):

	- NC only apply when a name type is present that matches a name type in the NC extension
	- NC are not applied to self-signed certs unless the cert is a TA
	- excluded takes precedence over included

(I've left out the clauses relating to applying NC rules for specific name forms; I'm only looking at the extension itself here.)

Proposal:

- Change "MUST be marked critical" to "SHOULD be marked critical" or "MAY be marked critical".

Pro:

- Permits issuers to assert NC without causing rejection by conformant RPs that may not be able to process NC at all or are unable to process NC for a specific name type.

Con:

- Reduces the issuer's assurance guarantees because the RP won't reject the certificate if a name type can't be processed.

Neutral:

- Non-conformant application behavior remains undefined with this change (i.e., a non-conformant application may process NC and reject or accept without reference to the specification)

Is this an accurate summary?

Assuming so, I think I have to come down on the "con" side.  The problem is the RP code that processes a certificate *is not always* responsible for extracting and using names included in the cert. 

Consider an implementation of an S/MIME client using an X.509 library that implements NC but does not implement the RFC822 NC rules.  Assume this client receives a signed email where the signature chain asserts a permitted-subtree NC for rfc822Name, but the signature cert has a name that is outside this subtree.  What happens at the RP?  Under the proposal, NC is not critical; the RP is correct to accept this cert because it cannot process the name type; the S/MIME client will then match the rfc822Name to the sender and tell the user the signature is valid.  That would be a Potentially Bad Thing.

(Yes, this is an artificial case, but you get the point?)

-- T

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Apr 2012 12:00:15 -0400

Why do you imagine that you are the right person to decide whether the
pro outweighs the con rather than the issuer?

This is something that CAs are going to decide for themselves.
Compliance with the DRAFT PKIX profile is not a requirement that the
Browser providers seem interested in enforcing.

As I read the Mozilla requirement it does not force Comodo to make an
immediate change to operating procedures as we retain control of the
private key for the systems in question. To the extent that there is a
direct commercial interest it would be nice to be able to employ name
constraints as an additional control even if this is not a
requirement.

It should be obvious that no CA is going to do that if doing so would
break backwards compatibility with even 1% of the deployed base. That
is twenty million users that will be inconvenienced. And don't forget
that most cell phones cannot even be updated.

People switch their cell phones regularly in the developed world of
course. Have you ever given a thought to what happens to the old ones
that are traded in? Out in parts of Africa or India a second hand
smart phone is the basis for a person's livelihood in just the way
that a rickshaw or a scooter might be. Backwards compatibility matters
to those people.

As a CA I have a responsibility to those people. I do not have any
responsibility towards this group.

What drives the immediate concern is not the direct commercial
interest but an indirect one. An attack on one of us is an attack on
all. Like Mozilla we have an interest in mitigating risk exposure in
all issued certificates, not just those we issue directly.

This is not a decision that the industry is willing to leave to this group.

Perhaps it is time that PKIX was shut down and the plans for a OCSP
DRAFT and a bis on 5280 abandoned. Rather than attempting to make this
particular forum relevant again, make rapid progress in the new forum
and then when everything has settled down again spin up a new IETF WG
to document the new approach as bis RFCs.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Sat, 7 Apr 2012 17:58:53 +0000

> pro outweighs the con rather than the issuer?

Don't put words in my mouth.  I gave my goddamn opinion, that's all.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Sat, 7 Apr 2012 18:08:14 +0000

So maybe this needs clarification:  "Pro" is the current argument for the Proposal, "Con" is the argument against.  These are not strictly speaking statements evaluating the Proposal, rather are summations of the two apparent camps.

If that wasn't clear, my apologies.

-- T

---

From: Russ Housley <[email-masked]>
Date: Sat, 7 Apr 2012 15:30:35 -0400

> that it fail processing if it does not process a critical extension

RFC 2459 says:

   ...  A
   certificate using system MUST reject the certificate if it encounters
   a critical extension it does not recognize; however, a non-critical
   extension may be ignored if it is not recognized.  ...

So, this is not a concept that was added in RFC 3280 or 5280.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Apr 2012 15:39:25 -0400

Isn't it an X509v3 requirement in any case?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Apr 2012 15:42:40 -0400

Your opinion was that your opinion on the matter is so important that
we should not change the spec.

What is being discussed here is not what the idea state of PKI should
be but whether the PKIX specification should allow CAs the flexibility
to deal with real world security tradeoffs as they see best.

---

From: Russ Housley <[email-masked]>
Date: Sat, 7 Apr 2012 15:49:29 -0400

> Isn't it an X509v3 requirement in any case?

Indeed, but many people implement solely form the information in the RFCs.

This requirement has been in the RFCs from the beginning.

Russ

---

From: Kyle Hamilton <[email-masked]>
Date: Sat, 7 Apr 2012 13:43:53 -0700

On Tue, Apr 3, 2012 at 1:40 PM, David A. Cooper <[email-masked]> wrote:
> While it may be true in a hierarchical PKI that a hierarchically superior CA
> may procedurally impose restrictions on the certificates that may be issued
> by its subordinate CAs and then may include constraints extensions that
> reflect those restrictions, it would be incorrect to suggest that
> constraints extensions always work this way.
>  The nameConstraints extension in the cross-certificate would not be a
> promise to the RP that no CA in the Federal PKI will issue outside of the
> constraint, nor is it an indication that any certificates issued outside the
> constraint are illegitimate or a "violation."  The nameConstraints extension
> would only indicate that DoD does not want its relying parties to accept

X.509 itself doesn't mandate criticality.  Compliant parsers cannot
complain about it being non-critical.

I've changed my mind: I support dropping the MUST criticality
requirement.  There isn't anything out there that can legitimately
complain about its noncriticality, so there is very little sense in
destroying what modicum of interoperability actually does exist.

The reason why we're having so many problems here is because the
participants on this list have yet to realize that there is no One
True Profile.  Apple implemented X.509, not PKIX.

-Kyle H

---

From: Kyle Hamilton <[email-masked]>
Date: Sat, 7 Apr 2012 13:53:34 -0700

Nope.  X.509/2008 page 33, section 8.4.2.2:
[...]
This extension may, at the option of the certificate issuer, be either
critical or non-critical . 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 name space intended by the issuing CA.
[...]

The criticality mandate is all PKIX.

-Kyle H

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Apr 2012 14:04:27 -0700

> to deal with real world security tradeoffs as they see best.

Earlier, you said that the CABrowser forum was going to do this work. If you want the CABrowser forum to do the work, we don't have to discuss it in this WG. However, this text sounds like you want this WG to do the work (presumably under its current procedures, leadership, and history).

Can you be more specific about who you think is going to do the work?

--Paul Hoffman

---

From: Erwann Abalea <[email-masked]>
Date: Sat, 7 Apr 2012 23:15:05 +0200

I think the "X.509 requirement in any case" is to reject any certificate
containing an unknown critical extension.

2012/4/7 Kyle Hamilton <[email-masked]>

-- 
Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 08 Apr 2012 02:11:11 +0200

Being away for some days, it was quite a read before anyone cared to look
in the X.509 spec :)

I regret the flaming in this thread, enough said about that.

I believe PKIX made a mistake requiring CAs to mark this extension
critical, while X.509 allows it to be non-critical.

The requirement does not affect client behavior (thoroughly examined in
this thread). It just imposes policy on the CA that actually should be up
to the CA to decide. A CA that concludes that criticality is important,
can always set it critical.

IOS as well as OS X are clearly not compliant with RFC 5280, but that is
not a good argument to require criticality.

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 8 Apr 2012 15:09:24 -0400

Stefan,

Consider the following facts:

1.  X.509 does not require any of the certificate extensions to be critical.

2.  5280 is a profile of X.509 as the very first sentence of 5280 abstract says.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Saturday, April 07, 2012 8:11 PM
To: Kyle Hamilton; Phillip Hallam-Baker
Cc: IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Being away for some days, it was quite a read before anyone cared to look in the X.509 spec :)

I believe PKIX made a mistake requiring CAs to mark this extension critical, while X.509 allows it to be non-critical.

The requirement does not affect client behavior (thoroughly examined in this thread). It just imposes policy on the CA that actually should be up to the CA to decide. A CA that concludes that criticality is important, can always set it critical.

IOS as well as OS X are clearly not compliant with RFC 5280, but that is not a good argument to require criticality.

/Stefan

On 12-04-07 10:53 PM, "Kyle Hamilton" <[email-masked]> wrote:

>critical or non-critical . 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 name space 
>intended by the issuing CA.
>[...]
>
>On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker 
><[email-masked]>
>wrote:
>>>>constraints and will not enforce them - critical or not. It does not 
>>>>quite  implement all of RFC 2459, let alone 3280 or 5280, nor does 
>>>>2459 require  that it fail processing if it does not process a 
>>>>critical extension  (although 5280 does).
>>>
>>> RFC 2459 says:
>>>
>>>   ...  A

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 08 Apr 2012 22:47:12 +0200

Santosh,

I have considered that. Neither of these facts are in my mind any good
reason for requiring criticality.

/Stefan

On 12-04-08 9:09 PM, "Santosh Chokhani" <[email-masked]> wrote:

>Stefan Santesson

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 8 Apr 2012 17:53:05 -0400

Stefan,

What is your reason for making it non critical?

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Sunday, April 08, 2012 4:47 PM
To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker
Cc: IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

I have considered that. Neither of these facts are in my mind any good reason for requiring criticality.

/Stefan

On 12-04-08 9:09 PM, "Santosh Chokhani" <[email-masked]> wrote:

>this thread). It just imposes policy on the CA that actually should be 
>up to the CA to decide. A CA that concludes that criticality is 
>important, can always set it critical.
>
>IOS as well as OS X are clearly not compliant with RFC 5280, but that 
>is not a good argument to require criticality.
>
>/Stefan
>
>
>>>>>constraints and will not enforce them - critical or not. It does 
>>>>>not quite  implement all of RFC 2459, let alone 3280 or 5280, nor 
>>>>>does

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 09 Apr 2012 00:24:03 +0200

Santosh,

Not proposing making it non-critical. Relaxing the SHALL requirement to a
SHOULD would be appropriate.

The reason is what I recently posted. I see no cons with a SHALL
requirement. Neither from a security nor from an interop perspective.

Relaxing SHALL to SHOULD:
- Does not affect the way RPs process and enforce the extension
(regardless of criticality).
- RPs can protect their interests by correctly implementing the extension
- CAs can protect their interests by setting the extension critical.
- No harm is done to any defenseless third party.

What do you think is missing?
What, if anything, is your reasons for defending a SHALL requirement.

/Stefan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Apr 2012 19:13:54 -0400

Exactly, nobody is suggesting that the requirement prohibit setting
this extension critical.

If your think your security needs indicate it should be critical, then
mark it so. Our needs can only be met by not marking it critical so we
have the following choices:

1) Don't use name constraints at all
2) Use name constraints without marking them critical

The lack of understanding of the criticality flag in PKIX is the
reason that I wrote the SAML spec with 'Conditions' instead. The only
extensions that should ever be marked critical in my view are
extensions that specify conditions that affect the validity of the
assertion. In the case of X.509v3 that would be a revocation
condition.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Apr 2012 00:26:51 +0100

Hi Phill,

On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote:
>   Our needs can only be met by not marking it critical

I understand the need to work with deployed code. We
can (dis)agree about its relative importance here, but
I've a different question.

I do not understand how a non-critical NC meets the
need to prevent entreprise CAs issuing certs beyond the
relevant scope. (RPs that don't support NC will be
vulnerable, and presumably that's most-to-nearly-all RPs.)

If you're saying that you don't have a need to prevent
that, but only a need to detect it (e.g. via something like
the ssl-observatory) then that seems to require a bigger
change vs.5280. I've not looked at the text just now, but
as I recall it, NC is designed for prevention and not for
detection.

Defining a new typically non-critical NC-like extension
for detection would seem like the right thing to do. (And
I'd imagine the putative new extension could have simpler
syntax and more precise semantics for what is a now-real
use-case:-)

So, another question: why is not a new non-critical NC-like
extension not better here? The ssl-observatory approach would
work just as well with that.

Cheers,
S.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 09 Apr 2012 01:54:35 +0200

Stephen,

A non critical setting would ensure that any 5280 compliant RP would
enforce the NC, while allowing no conforming RPs to accept the cert chain
at their own risk.
Why would that never be a useful tradeoff?

Given that Apple has failed to correctly implement the current extension
in 10 years, I doubt that a new extension will solve the problems any
better.
Plus, I would hate to se two extensions solving the same problem in
slightly different ways.

/Stefan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Apr 2012 20:00:55 -0400

> vulnerable, and presumably that's most-to-nearly-all RPs.)

The spec is clear that either the extension must be processed or the
cert rejected regardless of the NC flag if the client understands the
extension. None of the clients checked appear to reject if the
extension is not marked critical.

> as I recall it, NC is designed for prevention and not for

The desired outcome here is:

* Clients that process NCs have protection
* Clients that do not process NCs do not reject valid certs

There are two issues here, false positives (reject a valid cert) and
false negatives (accept a bogus cert). Since the number of false
negatives has been negligible to date the false positives concern is
considerably greater than the false negatives. It is unacceptable for
a legacy client to reject a legitimate cert.

> syntax and more precise semantics for what is a now-real

That may be something that we would want to look at in addition. But
2012 is not 2010. We now have an active attacker and a very short time
horizon. There is deployed code that can be used to provide a degree
of protection now.

> work just as well with that.

If nobody had implemented the old NC system that would make sense. But
there are code paths we can and will use now.

Why not change the SHALL on the legacy NC scheme to a SHOULD so that
we can start using it now and then have a discussion on new proposals
for NC like things?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Apr 2012 01:07:40 +0100

So is this a fair summary?

The goal is prevention, but the proposal is recognised
to be an imperfect way to achieve that given the current
deployed codebase, (arguably better than the status quo
ante but with a known vulnerability).

Not saying what I think but just trying to help clarify
what's at issue.

S.

PS: All the above as a 5280 co-author/interested
party, in case that wasn't clear.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Apr 2012 17:18:00 -0700

> we can start using it now and then have a discussion on new proposals

Because it would break clients that check the MUST from 5280. Presumably, some do. Presumably from your earlier messages, none of the ones you care about do.

Why not just issue the certs you think you should issue and not worry so much about what the spec requires? You have done your analysis and have a business case for your actions. There are probably other parts of PKIX that various public CAs are not following exactly, and yet they are not removed from our root piles.

--Paul Hoffman

---

From: Tom Gindin <[email-masked]>
Date: Sun, 8 Apr 2012 20:37:18 -0400

The description of the processing of X.400 name constraints is not 
clear.  There's one quite clear statement that CA's SHOULD NOT set them, 
and a less clear one that RP's are permitted to follow your second point 
(the last sentence of page 40, quoted in Dave Cooper's earlier message). 
That permission is sufficiently unclear that you described it as "against 
the RFC", and I hedged on whether it's conformant.  If we don't think it's 
obvious, even though Dave Cooper does, how many implementors will?
        The actual processing of X.400 name constraints is almost 
unspecified in both RFC 5280 and X.509-2008.  This is far more of a 
weakness for X.509 than for RFC 5280, which at least makes it clear that 
it doesn't advocate such name constraints.  The issue I'm bringing up is 
that an RP may recognize an X.400 name form while not knowing how to fully 
implement name constraints for it.  IMHO would be much easier to implement 
meaningful name constraints for Registered ID or EDIPartyName than for 
X400Address.  It would also be simpler to implement constraints for the PI 
Other-Name.

Tom Gindin

From:   Santosh Chokhani <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, "[email-masked]" <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   04/06/2012 10:53 AM
Subject:        RE: [pkix] Proposal: Change the Criticality Requirement of 
Name

Tom,

1.  If the name constraint is critical and you do not recognize one or 
more name forms, reject the certificate.

3,  If the name constraint is non-critical and you do not recognize one or 
more name forms, accept the certificate.

I agree that there is some ambiguity in terms of application behavior if 
you assume that application behavior must be the same regardless of 
criticality if an extension is recognized.  This is due to inability to 
process all name forms.

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

        Martin:

Tom Gindin

Name

                     well-known trust anchor
                               |
                               |

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 09 Apr 2012 02:37:53 +0200

Stephen,

Just for clarity. What in your mind is the vulnerability?
Given that nothing prevents a CA from marking the extension critical.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 09 Apr 2012 02:46:23 +0200

Paul,

On 12-04-09 2:18 AM, "Paul Hoffman" <[email-masked]> wrote:

>Because it would break clients that check the MUST from 5280.

Exactly how would that happen in practice?

An RP will only see if the extension has criticality or not.
To break anything the RP client would have to reject the cert just because
it finds a NC with non-critical flag.
This is not a behavior caused by any existing RFC 5280 requirement.

Even if this would be the case. Isn't it up to the CA to decide what RP
clients they need to interoperate with?

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Apr 2012 01:50:12 +0100

> Given that nothing prevents a CA from marking the extension critical.

The vulnerability is that if an enterprise CA is issued a non-critical
NC for example.com by a public CA, then the enterprise CA can issue
certs for example.net and an RP that doesn't implement NC will accept
the cert for example.net from example.com. Setting NC critical avoids
that issue.

I understand that mitigating that exact vulnerability is the reason
that a browser want to introduce NC as a requirement for CAs, so this
is a non-trivial issue with the proposal.

If the argument for this proposal is that it'd help get over a
deployment hump then maybe it'd be better separated out from an 5280
update, since presumably widespread use would cause the non-complying
deployments to get fixed over time.

I've been told that other than one RP, most other that are widely
deployed do support NC.

In response to Paul's question, I'd be interested to know if
anyone's tested if any of those NC-supporting RP's barf on a
cert with a non-critical NC or not. If deployed NC-supporting
code did that then that'd be significant for the discussion I'd say.
(We'd have two sets of conflictingly different bad implementations
from the 5280-purist p-o-v, rather than one.)

S

>
> /Stefan
>
> On 12-04-09 2:07 AM, "Stephen Farrell"<[email-masked]>  wrote:
>
>>

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 8 Apr 2012 20:58:26 -0400

Tom,

I am not an expert on X.400.  So, I would not comment on it.

But, 5280 is clear (I just elided over parts of the sentence David Cooper cited) that you need not understand and process a name constraint for a name form that does not appear in the certificate subject name or subject alt name.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Sunday, April 08, 2012 8:37 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name

        The description of the processing of X.400 name constraints is not clear.  There's one quite clear statement that CA's SHOULD NOT set them, and a less clear one that RP's are permitted to follow your second point (the last sentence of page 40, quoted in Dave Cooper's earlier message). 
That permission is sufficiently unclear that you described it as "against the RFC", and I hedged on whether it's conformant.  If we don't think it's obvious, even though Dave Cooper does, how many implementors will?
        The actual processing of X.400 name constraints is almost unspecified in both RFC 5280 and X.509-2008.  This is far more of a weakness for X.509 than for RFC 5280, which at least makes it clear that it doesn't advocate such name constraints.  The issue I'm bringing up is that an RP may recognize an X.400 name form while not knowing how to fully implement name constraints for it.  IMHO would be much easier to implement meaningful name constraints for Registered ID or EDIPartyName than for X400Address.  It would also be simpler to implement constraints for the PI Other-Name.

Tom Gindin

Tom,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Gindin
Sent: Thursday, April 05, 2012 9:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

        Martin:

Tom Gindin

Name

                     well-known trust anchor
                               |
                               |

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 8 Apr 2012 21:09:53 -0400

Stefan,

Your logic can be applied to any of the certificate extensions identified as critical in 5280.  I do not think we write the standards so that they meet insecure implementations.

In my opinion PKIX standards are for secure interoperability.  What you say exposes some of the clients.

The harm it does is CAs will point to the RFC and mark the extension non critical and the RP software (browser) vendors will not have any reason or incentive to implement name constraints.  This will expose the consumers and businesses.

It is best for the CAs make their own determination and work with RP in CA browser forum,

We should not dilute the security of a security standard just because the largest market capitalization company in the history of human race has not implemented a long standing standard correctly.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Sunday, April 08, 2012 6:24 PM
To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker
Cc: IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

Not proposing making it non-critical. Relaxing the SHALL requirement to a SHOULD would be appropriate.

The reason is what I recently posted. I see no cons with a SHALL requirement. Neither from a security nor from an interop perspective.

- Does not affect the way RPs process and enforce the extension (regardless of criticality).

/Stefan

On 12-04-08 11:53 PM, "Santosh Chokhani" <[email-masked]> wrote:

>>The requirement does not affect client behavior (thoroughly examined 
>>in this thread). It just imposes policy on the CA that actually should 
>>be up to the CA to decide. A CA that concludes that criticality is 
>>>This extension may, at the option of the certificate issuer, be 
>>>either critical or non-critical . It is recommended that it be 
>>>subsequent certificates in a certification path are located in the 
>>>name space intended by the issuing CA.
>>>[...]
>>>
>>>>>> While Apple's OS X (desktop) implementation will not choke if 
>>>>>>Name Constraints is marked critical, it does not support 
>>>>>>processing name constraints and will not enforce them - critical 
>>>>>>or not. It does not quite  implement all of RFC 2459, let alone 
>>>>>>3280 or 5280, nor does

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Apr 2012 18:50:43 -0700

> An RP will only see if the extension has criticality or not.

Correct.

> it finds a NC with non-critical flag.

Correct.

> This is not a behavior caused by any existing RFC 5280 requirement.

If the RP only accepts certificates that it thinks fully conforms to 5280, and the RP sees a cert in the chain that does not fully conform to 5280, it is reasonable for the RP to say "that's a bad cert, it doesn't go in my chain" and thus fails to find a good chain. This is not required by 5280, but it certainly makes sense for picky RPs.

> clients they need to interoperate with?

Absolutely, and that's exactly what I said to Phill.

--Paul Hoffman

---

From: Piyush Jain <[email-masked]>
Date: Sun, 8 Apr 2012 18:50:55 -0700

> Date: Mon, 9 Apr 2012 02:46:23 +0200
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]

Existing requirement is that NC must be marked critical.
Believe it or not, there are implementations out there which check if a certificate complies with the profile or not, and reject  them upfront in case of failure.

> clients they need to interoperate with?

Sure. And they are free to mark NC as non critical. But they won't be able to claim compliance with 5280 and will need to explain their reason to break compliance to their customers.
The fact is that most people who are using PKI don't understand most things about PKI. They put their trust in the standards and as long as an implementation claims compliance to the standard they are happy to adopt it. When you start changing standards to accommodate insecure implementations you set a wrong precedence.

A while ago I came across a big PKI deployment where applications were not doing revocation checking because every cert that was issued was mapped to an active directory user. The customer was convinced (rightfully so), that revocation checking was not required because they could achieve the same outcome by removing the user from active directory. 
Does it mean that we should make revocation checking optional in 5280?

The point is that you will always find implementations/business cases where breaking compliance to a standard makes sense. But in those cases, the entities who make this decision should be able to justify/explain it instead of saying that they were just following the standard.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Apr 2012 10:41:24 +0300

On Apr 9, 2012, at 4:50 AM, Piyush Jain wrote:

Can you name them?

You could, but often certificates expire or get lost or compromised before the EE gets removed from the directory, so revocation makes sense in that case as well.

5280 is a profile for using PKI on the Internet. If there's a valid reason to make revocation checking optional on the Internet, then yes.

Maybe we need more than one profile.

---

From: Max Pritikin <[email-masked]>
Date: Mon, 9 Apr 2012 10:46:22 -0600

+1 (Well stated Stefan)

This is my position as well: The CAs should make this decision based on their own policy. PKIX documents should, as does the X.509 document, recommend the more secure option.

Any client that ignores a critical extension's contents should be publicly hounded as having a security vulnerability. 

- max

On Apr 7, 2012, at 6:11 PM, Stefan Santesson wrote:

>>>>> quite

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 Apr 2012 15:04:29 -0400

>> critical, while X.509 allows it to be non-critical.

This was discussed at length prior to the publication of RFC 2459, which says:

   Restrictions are defined in terms of permitted or excluded name
   subtrees.  Any name matching a restriction in the excludedSubtrees
   field is invalid regardless of information appearing in the
   permittedSubtrees.  This extension MUST be critical.

The thinking at the time was that certificates should be rejected when client does not recognize the name constraints extension.  I have not seen any discussion in this thread that changes my mind on this topic.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 09 Apr 2012 22:01:57 +0200

Russ,

At the time of creating RFC 2459, I would probably been on the side of
votes for mandating criticality.

After spending my past 9 years in development, trying to get these things
in practical use, my perspective has tend to gravitate more towards
pragmatism.
Unfortunately, today there is quite a gap between theoretical PKI and PKI
in practice.
A successful implementor need not only to be skilled in the theory, but
also in the parts where common deployment deviate from the standards.

This has caused many PKI deployment efforts to adapt a "trial and error"
approach to PKI.
You simply tweak your deployment until it passes the diverse clients and
servers that need to use it.

At my years at Microsoft it was quite an experience to discover how many
implementations out there that got broken every time we corrected a
non-conformant feature in the PKI stack of the Windows OS.

I believe the industry is best served if we, where it can be done
responsibly, try to at least reduce the gap between PKI theory and
practice, fully aware that it never will be fully closed.

On the issue at hand, I simply can't see that the matter of criticality
for NC is anything more than a policy decision by the CA.
Further, a policy decision that in no way puts standards compliant clients
at risk.
Fully respecting that others might disagree.

Just my 2 cents.

/Stefan

On 12-04-09 9:04 PM, "Russ Housley" <[email-masked]> wrote:

>The thinking at the time was that certificates should be rejected when
>client does not recognize the name constraints extension.  I have not
>seen any discussion in this thread that changes my mind on this topic.
>
>Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 9 Apr 2012 17:02:42 -0400

Stefan,

The very much the length of this debate and disagreement and rationale you provide is the reason in itself that the standard should not change.

With this debate we know the exposure and producers and consumers can come to agreement in an appropriate forum how to transition to secure implementation.

If the standard said this extension can be NC, folks would be happy to produce certificates with NC and some browsers will not implement name constraints processing.

It is important that we get where the RP enforce the CA defined constraints and making security critical extensions NC in a security standard is not the way to get their attention.  It is a way to tell folks that this is not important for security.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Monday, April 09, 2012 4:02 PM
To: Russ Housley
Cc: IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Russ,

At the time of creating RFC 2459, I would probably been on the side of votes for mandating criticality.

After spending my past 9 years in development, trying to get these things in practical use, my perspective has tend to gravitate more towards pragmatism.
Unfortunately, today there is quite a gap between theoretical PKI and PKI in practice.
A successful implementor need not only to be skilled in the theory, but also in the parts where common deployment deviate from the standards.

This has caused many PKI deployment efforts to adapt a "trial and error"
approach to PKI.
You simply tweak your deployment until it passes the diverse clients and servers that need to use it.

At my years at Microsoft it was quite an experience to discover how many implementations out there that got broken every time we corrected a non-conformant feature in the PKI stack of the Windows OS.

I believe the industry is best served if we, where it can be done responsibly, try to at least reduce the gap between PKI theory and practice, fully aware that it never will be fully closed.

On the issue at hand, I simply can't see that the matter of criticality for NC is anything more than a policy decision by the CA.
Further, a policy decision that in no way puts standards compliant clients at risk.
Fully respecting that others might disagree.

Just my 2 cents.

/Stefan

On 12-04-09 9:04 PM, "Russ Housley" <[email-masked]> wrote:

>This was discussed at length prior to the publication of RFC 2459, 
>which
>says:
>

---

From: Sean Leonard <[email-masked]>
Date: Mon, 09 Apr 2012 14:45:52 -0700

"When all is said and done, much more is said than done."
-Dave Cutler

As Ryan Sleevi pointed out, Apple's tpPolicy code is open source, 
governed by the Apple Public Source License 2.0. Would we really be 
having this argument over a standards body mailing list (which now 
stretches to 138 messages), if someone just fixed Apple's code? Any one 
of a number of commenters could use their Prodigious Corporate 
Resources(tm) to fix the problem, and post a fix to Apple. It seriously 
would not take more than 2 weeks of a senior engineer's time. That will 
accomplish your long-range business and security objectives much better 
than fiddling with the criticality bit.

As to any installed base argument that might crop up, Apple users are 
pretty good about getting updates in a timely fashion. See 
<http://david-smith.org/blog/2012/03/10/ios-5-dot-1-upgrade-stats/index.html> 
for iOS statistics.

-Sean

---

From: Ogle Ron <[email-masked]>
Date: Mon, 9 Apr 2012 16:59:37 -0400

I do not normally add my .02 to these types of discussions; however, this
time I will.  I run a set of Certificate Authorities that have easily
generated 100M+ certs for Cable Modems, DSL Gateways, and other consumer
electronics products.  Some of these PKIs run as subordinate to CableLabs
and Excentis (Euro version of CableLabs) Root CAs.

We try to run as close to PKIX RFCs as possible; however, we will deviate
when necessary (seldom).  From my perspective, NC is a business decision
not a technical problem with a specification.  I know that some on this
list view this as a security issue, and they are trying to save the RP
from themselves and the CA owners that they use.

Maybe the best decision for those who see this as a security issue is to
put in a note or caveat to the RFC that explains why this extension is
important.  However, the RFC has to reflect that this extension is a
business decision by using "SHOULD" or "MAY" instead of "MUST" for the
critical flag.  The CA owners and RPs have to determine what is best for
them, and how much security they need to do the job.

Use education instead of the stick for this extension and the critical
flag.

FYI, if I do something with one of my subordinate CAs, CableLabs/Excentis
will revoke me.  It is a business decision that doesn't rely upon a
certificate extension.  The same can be done with any other subordinate
under other roots.  If the Enterprise CA is providing invalid certs, then
the Root CA owner can revoke the subordinate.  Of course, this too would
be a business decision, but it is a very strong dis-incentive.

BTW, it would not be a bad idea for Mitre, NSA, or NIST to provide
guidance to us mere mortals on how CA owners can be evaluated for levels
of assurance/trust.  Right now the CA Root providers see this as simple
commercial offerings instead of necessarily a security structure to
provide commerce.  As such they may not take the appropriate actions to
provide a high level of assurance (but then again not everyone needs or
wants a high level of assurance).

I would really like to see these super smart demi-gods come up with a way
for us mortals to see which Root providers can be evaluated at a specific
level.  Then us poor security worker bees can tell our IT brethren to
remove certain CA Roots from our infrastructure because they don't make
the grade.  (I think that you'll see the market rapidly change when Roots
are dropped.)

Ron Ogle
My thoughts are my own, and do not necessarily reflect those of my
organization for whom I am employed.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 10 Apr 2012 09:56:01 +1000

Santosh,

> If the standard said this extension can be NC (non-critical),
> folks would be happy to produce certificates with NC and some
> browsers will not implement name constraints processing.
>
> It is important that we get where the RP enforce the CA defined
> constraints and making security critical extensions NC in a
> security standard is not the way to get their attention.
> It is a way to tell folks that this is not important for security.

At the moment, there is little incentive for an implementation (such as Safari) to implement name constraints as there are almost no certificates using them. A browser is equally secure with or without support.

If name constraints can be non-critical, certificates using them can appear far more easily and there will be an explicit security difference between browsers that do or do not implement those constraints. That will provide a tangible incentive for software (such as Safari) to implement name constraints. Otherwise it doesn't protect its users from a threat that other browsers do, which will look very bad if (or when) the threat becomes an attack.

I am in favour of removing the PKIX requirement that name constraints be marked critical.

--
James Manger

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 21:14:16 -0400

>constraints could be evaded.

Not necessarily.  In a specific context only certain name forms may be
relevant. The presence of other name forms may be harmless and thus they
need not be constrained. no need to go through your example.

I agree that not all name forms will ever be covered by name constraints,
and if these name forms are of concern, then custom RP software would 
be required.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 21:01:26 -0400

>    RECOMMENDS against including such checks.

yes, and here is an example of where I think we got it wrong.

If RPs checked for CAs violating 5280, it would have provided 
feedback to those CAs and that might have reduced the non-compliant 
behavior that we see.

The RPKI specs require RPs to verify the syntactic constraints 
imposed on CAs, in an effort to avoid this faiulure mode.  We'll see 
if we have better luck this time.

Steve

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Apr 2012 07:38:11 +0300

Hi James,

> If name constraints can be non-critical, certificates using them can appear far more easily and there will be an explicit security difference between browsers that do or do not implement those cons…

+1

> I am in favour of removing the PKIX requirement that name constraints be marked critical.

I am not in favor of revving 5280. All the arguments for mandatory criticality are about generic relying parties. All the examples people give against requiring criticality are from the commercial CA / browser use case.  I think we need another profile, one that is not aimed at the "Internet" like 5280, but specifically for browsers and CAs on the world wide web.

It doesn't have to be a 150-page behemoth like 5280, either. More like

Abstract
  This document specifies a profile for web browsers and CAs

1. Introduction
  [RFC5280] specifies a profile for PKI on the Internet. This document specifies 
  a profile for web browsers and CAs. It inherits all the requirements from 
  RFC 5280, with the exceptions listed in the following sections.

2. Name Constraints
   RFC 5280 requires name constraints to be marked critical. Under this profile
   this extension MAY be critical.
   Discussion: …

Yoav

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 10 Apr 2012 09:30:00 +0200

Interesting discussion.  Since it is mainly about deficiencies in a
few named vendors' PKI SW and nobody from that camp is responding,
this is essentially an SDO market adaptation issue.

IMO security is a "journey" were all bits and pieces are moving
in an uncoordinated fashion.  Therefore it seems that offering
software vendors an upgrade path would be the pragmatic solution.

That "non-critical" extensions like OCSP URLs in reality must
be regarded as critical also makes it [sort of] logical allowing
non-critical name constraints.

Anders

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Apr 2012 10:53:49 +0300

> this is essentially an SDO market adaptation issue.

The named vendor is known for its secrecy.

> non-critical name constraints.

The thing is, "critical" at best means "mandatory to implement", but vendors can also implement it as "recognize and ignore".

We shouldn't try to prevent CAs from reflecting their name constraints to supporting RPs, which we will if we require them to exclude non-supporting RPs.

The name constraints have been in the standards for over 15 years. Some browsers didn't implement their enforcement, because they weren't "in the field". CAs didn't put them "in the field" because some browsers would barf on a non-supported critical extension (and rightly so). It's great that Firefox did implement this, but without 99% success rate, the CAs won't deploy, but I guess we need non-criticality to get adoption going.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Tue, 10 Apr 2012 10:08:58 +0100

>    RFC 5280, with the exceptions listed in the following sections.

Hi Yoav.  Such a document already exists, so I don't think we need 
another new doc.

http://www.cabforum.org/Baseline_Requirements_V1.pdf

See Appendix B.

The Name Constraints extension is not mentioned, which means that "All 
other fields and extensions MUST be set in accordance to RFC 5280" applies.

>     this extension MAY be critical.

I intend to propose (on the CABForum list) updating the Baseline 
Requirements to allow NC to be non-critical.

---

From: Tom Gindin <[email-masked]>
Date: Tue, 10 Apr 2012 08:26:31 -0400

AFAIK, no large organization uses unicorns.  The good news arising 
from this part of the thread is that it's been clarified that it 
constitutes 5280-compliant RP processing to implement X.400 Name 
Constraints, like those for Registered ID or EDIPartyName, by rejecting 
any EE certificate with a SubjectAltName member of that form coming from a 
chain with a subtree of that form.  As a practical matter, I expect most 
such RP's to do exactly that.  That should remove one minor deterrent to 
the adoption of Name Constraints by RP's.

Tom Gindin

From:   Peter Gutmann <[email-masked]>
To:     [email-masked], Tom Gindin/Watson/IBM@IBMUS, 
Cc:     [email-masked]
Date:   04/09/2012 06:07 AM
Subject:        Re: [pkix] Proposal: Change the Criticality Requirement of 
Name

Tom Gindin <[email-masked]> writes:

>The actual processing of X.400 name constraints is almost unspecified in 
both
>RFC 5280 and X.509-2008.  This is far more of a weakness for X.509 than 
for
>RFC 5280, which at least makes it clear that it doesn't advocate such 
name
>constraints.  The issue I'm bringing up is that an RP may recognize an 
X.400
>name form while not knowing how to fully implement name constraints for 
it.

How many implementations properly handle X.400 names.  Not even name
constraints, but just basic X.400 names [0]?

Worrying about X.400 name constraints being underspecified is a bit like
worrying about unicorn constraints being underspecified.

Peter.

[0] Yes, I know, the USG still uses X.400.  I'm looking for stuff in our
    reality, not the USG's parallel universe.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Apr 2012 08:39:51 -0400

It's a question of how to do Engineering.

Approach 1: write a spec that describes what you want to achieve,
implement the spec as closely as possible given the current operating
environment and constraints, note AND EXPECT deviations from the spec,
and update implementations as the environment changes.

Approach 2: write a spec that achieves what is possible given current
operating environment and constraints.  As the environment changes,
update the spec to add back in capabilities that were previously desired
but omitted.

I'm not an HTML expert, but does not HTML 4 specify a complete feature
set that at one time was not implemented by all browsers?  And
individual HTML documents can be checked for "strict" or "transitional"
compliance?  As browser implementations improve, is it not possible to
write more and more HTML documents that pass "strict" compliance
checking WITHOUT updating the HTML 4 spec itself?

My engineering toolbox includes tools like "lint".  C compilers may be
written to accept non-standard code, but the specification of the C
language itself does not continue to evolve based on the current
capabilities of compilers and coders.

Should the PKIX spec be written like the HTML and C specs (one version
that may not be completely adhered to in practice), or should today's
version of PKIX be limited to the current state of applications and
updated as the application environment changes?

My vote is for Approach 1.

Dave

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

> CAs have good 
> justification for weighting "operate without inconveniencing casual 
> users" more highly than "secure" in that situation.  But it does not 
> change the specification of the correct way to achieve both 
> interoperability and security.

I disagree. The E in IETF in engineering. A spec that considers only the
"secure" and not the "operate without inconveniencing casual users" is
bad engineering. Engineering has to consider the operating environment
and constraints of those who need to follow the spec.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Apr 2012 14:52:31 +0200

Yoav,

On 12-04-10 6:38 AM, "Yoav Nir" <[email-masked]> wrote:

>   Discussion: Š

It would have to be another profile of X.509.
It can't be a profile of RFC 5280 as it isn't compliant with RFC 5280.

Since web browsers are an Internet application, I would much rather have a
web profile being a profile of RFC 5280.
Such a profile AFAIK has already been defined by the cab-forum.

/Stefan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 09:10:59 -0400

For someone who was accusing me earlier of not understanding PKI, this
is quite a statement.

It is not even gramatical, I can't parse it. What you seem to be
saying is that having this debate is a good thing because all those
troublesome implementers and users will go somewhere else to solve
their problems in future.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 09:13:29 -0400

Fixing Apple's code is one thing, getting them to distribute is
another, getting users to upgrade yet another.

Apple is not even patching their known virus vulnerability in Snow
Leopard, there are still Power PC users who have no support at all.

We can't wait ten years before using this technology. I have seen no
good argument for continuing to attempt PKIX compliance here.

On Mon, Apr 9, 2012 at 5:45 PM, Sean Leonard <[email-masked]> wrote:
> As Ryan Sleevi pointed out, Apple's tpPolicy code is open source, governed
> by the Apple Public Source License 2.0. Would we really be having this
> argument over a standards body mailing list (which now stretches to 138
> messages), if someone just fixed Apple's code? Any one of a number of
> commenters could use their Prodigious Corporate Resources(tm) to fix the
> problem, and post a fix to Apple. It seriously would not take more than 2
> weeks of a senior engineer's time. That will accomplish your long-range
> business and security objectives much better than fiddling with the
> criticality bit.
>
> As to any installed base argument that might crop up, Apple users are pretty
> good about getting updates in a timely fashion. See

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 09:26:49 -0400

But what is the basis for making the decisions in the furst place?

If the decisions are based on a bunch of consultants working out how
to fleece DoD out of the maximum amount of moolah, then the industry
that has real customers is going to go elsewhere. That is the downside
of the COTS strategy, it creates economic incentives for folk to muck
up the standards process.

There is already a consensus to make this change on the Mozilla list.
I would be astonished if anyone opposed making the change in CABForum.
So even under the present situation where those are two separate
communities, the de facto standard is going to change.

At this point this group has already backed the industry into a
position where it has lost de facto standards making capability. The
question now is whether it also loses control of the de jure
specification.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 Apr 2012 09:34:07 -0400

James,

It is hard to determine what would motivate a given vendor.  You may very well be right.  But, the way to achieve this is for the CAs to determine how to bring the "certificate consuming" software vendors in compliance.  The standard should preserve security.

CA vendors can give grace period or browser vendors can use existing or new UI to let the human use decide if they want to override the browser decision until browsers have the capability to process the extension.

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Monday, April 09, 2012 7:56 PM
To: Santosh Chokhani; IETF PKIX
Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

> If the standard said this extension can be NC (non-critical), folks 
> would be happy to produce certificates with NC and some browsers will 
> not implement name constraints processing.
>
> constraints and making security critical extensions NC in a security 
> standard is not the way to get their attention.

--
James Manger

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 10 Apr 2012 15:43:26 +0200

I think you are absolutely right Phil.  Breaking a gazillion clients
out there is not how you gain momentum.

Best
Anders
PS It is nice [for once] not being the only "bad guy" in PKIX :-) DS

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 09:44:44 -0400

What incentive is there for the CAs to act as you suggest?

The only way that such a threat can be made is through joint action by
the CAs which is impossible to agree in this forum as there isn't even
a membership. In fact the only place that there could be such an
agreement is in CABForum.

Since Apple is a very large vendor, I can't see how we can credibly
threaten them with a big stick. What you are suggesting essentially
amounts to 'brick every iPhone'.

Instead I think that the new security forum should have a brand like
the WiFi brand that is awarded on completion of compliance tests for
'good security' and make the criteria reasonable so that Apple wants
to achieve that brand just like they did with WiFi and so on.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 Apr 2012 09:56:03 -0400

PHB,

All I am saying that 5280 is as much a security standard and it should not equivocate about the need to enforce name constraints, especially in light of 2010-11 happenings.

CABF may be the right place to sort out how to get to the secure, end state that 5280 represents.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 9:45 AM
To: Santosh Chokhani
Cc: Manger, James H; IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

The only way that such a threat can be made is through joint action by the CAs which is impossible to agree in this forum as there isn't even a membership. In fact the only place that there could be such an agreement is in CABForum.

Since Apple is a very large vendor, I can't see how we can credibly threaten them with a big stick. What you are suggesting essentially amounts to 'brick every iPhone'.

Instead I think that the new security forum should have a brand like the WiFi brand that is awarded on completion of compliance tests for 'good security' and make the criteria reasonable so that Apple wants to achieve that brand just like they did with WiFi and so on.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 10:06:03 -0400

Seems to me like you want to make a decision on grounds that we find
to be arbitrary and capricious and then hold a gun that is liable to
backfire on us to Apple's head in order to force their compliance.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 Apr 2012 10:11:33 -0400

PHB,

No.  I am saying that the decision made for 2459 and that has stood to date is a sound one and should remain so.

If implementations need to catch up, appropriate producers and consumers can negotiate the transition plan.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 10:06 AM
To: Santosh Chokhani
Cc: Manger, James H; IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Seems to me like you want to make a decision on grounds that we find to be arbitrary and capricious and then hold a gun that is liable to backfire on us to Apple's head in order to force their compliance.

On Tue, Apr 10, 2012 at 9:56 AM, Santosh Chokhani <[email-masked]> wrote:
>>> would be happy to produce certificates with NC and some browsers 
>>> will not implement name constraints processing.
>>>

---

From: Tom Gindin <[email-masked]>
Date: Tue, 10 Apr 2012 10:22:30 -0400

Santosh:

        Under the defined syntax, CA's have three choices for intermediate 
certificates in this area.  In ascending order of security, they are "no 
constraints", "non-critical constraints", "critical constraints".  It 
appears to me that the effect of banning the middle option has been, at 
least in the commercial world, to drive most CA's to the less secure 
option rather than to the more secure one.
        Do you have evidence that many commercial CA's are using critical 
name constraints except under government influence?  I don't, but others 
may have had better experiences.

Tom Gindin

From:   Santosh Chokhani <[email-masked]>
To:     "Manger, James H" <[email-masked]>, IETF PKIX 
<[email-masked]>, 
Date:   04/10/2012 09:36 AM
Subject:        Re: [pkix] Proposal: Change the Criticality Requirement of 
Name
Sent by:        [email-masked]

James,

It is hard to determine what would motivate a given vendor.  You may very 
well be right.  But, the way to achieve this is for the CAs to determine 
how to bring the "certificate consuming" software vendors in compliance. 
The standard should preserve security.

CA vendors can give grace period or browser vendors can use existing or 
new UI to let the human use decide if they want to override the browser 
decision until browsers have the capability to process the extension.

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Monday, April 09, 2012 7:56 PM
To: Santosh Chokhani; IETF PKIX
Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

> It is a way to tell folks that this is not important for security.

At the moment, there is little incentive for an implementation (such as 
Safari) to implement name constraints as there are almost no certificates 
using them. A browser is equally secure with or without support.

If name constraints can be non-critical, certificates using them can 
appear far more easily and there will be an explicit security difference 
between browsers that do or do not implement those constraints. That will 
provide a tangible incentive for software (such as Safari) to implement 
name constraints. Otherwise it doesn't protect its users from a threat 
that other browsers do, which will look very bad if (or when) the threat 
becomes an attack.

I am in favour of removing the PKIX requirement that name constraints be 
marked critical.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Apr 2012 16:30:31 +0200

Protocol security is not about denying implementers the option to run in
insecure modes.
One typical example is the TLS ciphesuite TLS_NULL_WITH_NULL_NULL

A secure protocol is a protocol that gives the level of security one is
entitled to expect, given a selected policy and configuration.
Denying CAs to set NC non critical is equal to denying CAs to set their
own policy.

/Stefan

On 12-04-10 4:11 PM, "Santosh Chokhani" <[email-masked]> wrote:

>PHB,
>
>No.  I am saying that the decision made for 2459 and that has stood to
>date is a sound one and should remain so.
>
>Seems to me like you want to make a decision on grounds that we find to
>be arbitrary and capricious and then hold a gun that is liable to
>> All I am saying that 5280 is as much a security standard and it should
>>not equivocate about the need to enforce name constraints, especially in
>>light of 2010-11 happenings.
>>
>>the CAs which is impossible to agree in this forum as there isn't even a
>>membership. In fact the only place that there could be such an agreement
>>is in CABForum.
>>
>>'good security' and make the criteria reasonable so that Apple wants to
>>achieve that brand just like they did with WiFi and so on.
>>
>>
>>> It is hard to determine what would motivate a given vendor.  You may
>>>very well be right.  But, the way to achieve this is for the CAs to
>>>determine how to bring the "certificate consuming" software vendors in
>>>compliance.  The standard should preserve security.
>>>
>>> CA vendors can give grace period or browser vendors can use existing
>>>or new UI to let the human use decide if they want to override the
>>>browser decision until browsers have the capability to process the
>>>extension.
>>>
>>> At the moment, there is little incentive for an implementation (such
>>>as Safari) to implement name constraints as there are almost no
>>>certificates using them. A browser is equally secure with or without
>>>support.
>>>
>>>appear far more easily and there will be an explicit security
>>>difference between browsers that do or do not implement those
>>>constraints. That will provide a tangible incentive for software (such
>>>as Safari) to implement name constraints. Otherwise it doesn't protect
>>>its users from a threat that other browsers do, which will look very
>>>bad if (or when) the threat becomes an attack.
>>>

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 Apr 2012 10:31:56 -0400

Tom,

I know commercial Bridge CAs that issue certificates with and get certificate with name constraints being critical.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 10:23 AM
To: Santosh Chokhani
Cc: Manger, James H; IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

        Santosh:

        Under the defined syntax, CA's have three choices for intermediate certificates in this area.  In ascending order of security, they are "no constraints", "non-critical constraints", "critical constraints".  It appears to me that the effect of banning the middle option has been, at least in the commercial world, to drive most CA's to the less secure option rather than to the more secure one.
        Do you have evidence that many commercial CA's are using critical name constraints except under government influence?  I don't, but others may have had better experiences.

Tom Gindin

James,

It is hard to determine what would motivate a given vendor.  You may very well be right.  But, the way to achieve this is for the CAs to determine how to bring the "certificate consuming" software vendors in compliance. 
The standard should preserve security.

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Monday, April 09, 2012 7:56 PM
To: Santosh Chokhani; IETF PKIX
Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name

Santosh,

At the moment, there is little incentive for an implementation (such as
Safari) to implement name constraints as there are almost no certificates using them. A browser is equally secure with or without support.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 07:35:37 -0700

On Apr 10, 2012, at 2:08 AM, Rob Stradling wrote:

> Hi Yoav.  Such a document already exists, so I don't think we need another new doc.
> 
> The Name Constraints extension is not mentioned, which means that "All other fields and extensions MUST be set in accordance to RFC 5280" applies.
> 
>> 2. Name Constraints
> I intend to propose (on the CABForum list) updating the Baseline Requirements to allow NC to be non-critical.

Great! Can we stop this thread then? If the people who need this change already have a way to get it, there is no need to have the discussion here.

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Tue, 10 Apr 2012 15:41:29 +0100

Hi Paul.  I'm guessing you meant to "To:" the list rather than me.  I 
tried to stop this thread 6 days ago!  ;-)

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Apr 2012 16:48:36 +0200

Why should we stop the thread?

1) Because all has been said?
2) Because since CABFORUM decides to deviate from PKIX, there are no
reasons for PKIX to relax the requirement?

/Stefan

On 12-04-10 4:35 PM, "Paul Hoffman" <[email-masked]> wrote:

>Great! Can we stop this thread then? If the people who need this change
>already have a way to get it, there is no need to have the discussion
>here.
>
>--Paul Hoffman
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 07:53:15 -0700

On Apr 10, 2012, at 7:41 AM, Rob Stradling wrote:

> Hi Paul.  I'm guessing you meant to "To:" the list rather than me.  I tried to stop this thread 6 days ago!  ;-)

Someone else from your company seems pretty intent on keeping the thread going; maybe you two could talk. :-)

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 07:53:47 -0700

> reasons for PKIX to relax the requirement?

Yes and yes.

--Paul Hoffman

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Apr 2012 10:55:16 -0400

CAB Forum deciding to recommend what works best in today's application environment is a GOOD thing.

PKIX recommending what works best in a fully-capable application environment is also a good thing.  There is no conflict, and no "loss of control" (whatever that means) in having two specs that differ in specifics because they differ in target environments.

As for the basis for making a decision in the first place, I haven't heard any assertion that marking the extension critical isn't appropriate when the majority of Internet applications (and all "significant" applications) support the extension.  The only argument for marking it non-critical is based on a lack of application support, which can be expected to change over time.

If you regard PKIX as analogous to the HTML 4.01 strict DTD, and a CABForum profile as analogous to the HTML 4.01 Transitional DTD, why would you view differences in the two profiles as a conflict?

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 9:27 AM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

If the decisions are based on a bunch of consultants working out how to fleece DoD out of the maximum amount of moolah, then the industry that has real customers is going to go elsewhere. That is the downside of the COTS strategy, it creates economic incentives for folk to muck up the standards process.

There is already a consensus to make this change on the Mozilla list.
I would be astonished if anyone opposed making the change in CABForum.
So even under the present situation where those are two separate communities, the de facto standard is going to change.

At this point this group has already backed the industry into a position where it has lost de facto standards making capability. The question now is whether it also loses control of the de jure specification.

On Tue, Apr 10, 2012 at 8:39 AM, Kemp, David P. <[email-masked]> wrote:
> update the spec to add back in capabilities that were previously 
> desired but omitted.
>
> I disagree. The E in IETF in engineering. A spec that considers only 
> the "secure" and not the "operate without inconveniencing casual 
> users" is bad engineering. Engineering has to consider the operating 
> environment and constraints of those who need to follow the spec.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 11:12:32 -0400

The reason that I re-raised the issue was that I saw that a schism was
about to open in the PKI world and thought that we should either have
a clean break or none at all.

I don't think it is a good idea for the WG to walk blindly into a
divorce. What Paul proposes is essentially a trial separation. There
are marriages that have been saved by a trial separation. But you
should not go into one unless you are at least considering the option
of a divorce.

Keeping quiet is clearly the best way to protect the institution. But
that has never been a priority of mine. I am only interested in what I
believe will make the Internet safer. And note that I said 'safer' not
more secure.

I know that I have a history of doing this. I worked with Tim to turn
W3C into a standards organization after the arrangement with IETF
became untenable then I was involved in the OASIS work and APWG and
CABForum. I don't worry about protecting institutions because they are
rather easier to establish than you might imagine.

If you are prepared to risk a divorce over a MUST vs a SHOULD on a
single bit then its probably best for all concerned if we admit that
the marriage is probably over anyway.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 10 Apr 2012 16:16:32 +0100

> Someone else from your company seems pretty intent on keeping the thread going; maybe you two could talk. :-)

Let me rephrase: I tried to stop the original thread 6 days ago, after 
my question had been answered and the consensus against my proposal was 
clear.

But since then, it has morphed into umpteen sub-threads all sharing the 
same Subject line.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 11:18:34 -0400

I disagree for the following reasons:

1) If every client processes NCs then the critical flag is irrelevant

2) If 'most' clients process NCs and some do not then it is still for
the CA to decide whether safety of Internet users is best achieved by
marking it critical or not.

Once CABForum is forced into a position where it is overriding one
part of the spec, a precedent has been set and it will override
others. The result will be two specifications of which the PKIX
profile is the less recognized.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Apr 2012 17:26:44 +0200

Paul,

Please enlighten me more on your reasoning.
Why is it better to have the world's largest implementation of public
internet PKI non-conformant to the PKIX profile?

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 08:28:10 -0700

> a clean break or none at all.

It is not "about to open": CABForum opened it long ago.

> divorce. What Paul proposes is essentially a trial separation.

Once again: please don't put words (in this case, analogies) into my mouth. CABForum has already proposed a profile, and the market can decide whether or not it is a good one. Rob says that the CABForum will consider a change to its profile, which seems good too. Lots of other groups have also proposed profiles, and their markets decide as well.

> There

I do not consider the PKI-using world as a polyamory relationship.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Apr 2012 18:40:44 +0300

Interesting analogy. Or should I say metaphor.  http://xkcd.com/762/

The current profile suggested by CABForum is a sub-profile of 5280. Every requirement there is allowed by 5280. What is being proposed here is a deviation from 5280, so essentially it's another profile. The CABForum has so far not done this, and I would not like there to be such an overlap in what the two organizations do. Doing that leads to turf wars on the one hand, and the "is this ours or theirs" question (such as is raised whenever somebody brings anything new to websec)

I would much rather that a new profile (if needed) be done in the IETF in cooperation with CABForum, rather than in competition.

Yoav

On Apr 10, 2012, at 6:12 PM, Phillip Hallam-Baker wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Apr 2012 18:42:19 +0300

I agree. It would be another profile. We can make the document short, and exclude all the explanations of X509 that 5280 includes by saying that this profile is the same as 5280 except for these few differences.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 08:58:56 -0700

> internet PKI non-conformant to the PKIX profile?

Because they believe that it works for their business model. Their business model evolves over time, sometimes in ways that add to the PKIX spec, other times in ways that subtract from it. They should be free to move with the needs of their users.

Different implementations need different things from PKIX at different times. If they want to diverge, there are no Internet Police to stop them: that's a good thing.

--Paul Hoffman

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Apr 2012 18:13:55 +0200

Thank you Paul,

Then at least I know that we fundamentally disagree.

To me RFC 5280 (being the only Internet X.509 profile) should be usable
for all legitimate business models for internet PKI.
If there is a legitimate business model that does not fit within the base
technical profile of RFC 5280, our profile is to narrow.

If the business model fails to fit within RFC 5280, because it's security
model is broken, then it is not a legitimate business model.

I believe CABForum has a legitimate business model, and it appears that
you agree.
I simply can't understand why you want to ban it from RFC 5280.

/Stefan

On 12-04-10 5:58 PM, "Paul Hoffman" <[email-masked]> wrote:

>Because they believe that it works for their business model. Their
>business model evolves over time, sometimes in ways that add to the PKIX
>spec, other times in ways that subtract from it. They should be free to
>move with the needs of their users.
>
>Different implementations need different things from PKIX at different
>times. If they want to diverge, there are no Internet Police to stop
>them: that's a good thing.
>
>--Paul Hoffman
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Apr 2012 17:23:37 +0100

Stefan,

> I simply can't understand why you want to ban it from RFC 5280.

I didn't hear anyone try "ban" anything.

There is a trade off here. If the one implementation for
which we're told this is a problem gets fixed then do we tweak
RFCs again? That'd seem like an odd way to do stuff.

OTOH, starting to use NC would be a good thing.

There are arguments for the change to be made and there are
arguments for the status quo.

Speaking as a co-author of 5280, so far, I'm not convinced
by the argument to change the 5280 rule.

S.

>
> /Stefan
>
>
> On 12-04-10 5:58 PM, "Paul Hoffman"<[email-masked]>  wrote:
>

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Apr 2012 12:31:12 -0400

For the same reason that in 1999, the world's largest collection of
browsers was non-conformant to the HTML 4.01 strict profile.

>From W3C:

     * The HTML 4.01 Strict DTD includes all elements and attributes
       that have not been deprecated or do not appear in frameset
documents.

     * The HTML 4.01 Transitional DTD includes everything in the strict
       DTD plus deprecated elements and attributes.

This approach seems like a perfect analogy (or metaphor: +1 for xkcd
references :-).  There is no divorce or trial separation between the two
HTML DTDs; they are partners that were designed together to address
legacy applications and modern applications.  My question is "if the
purpose of PKIX is to define the transitional profile, then who is
responsible for defining the strict profile?"

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, April 10, 2012 11:27 AM
To: Paul Hoffman
Cc: IETF PKIX
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name

Paul,

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 09:39:41 -0700

> I simply can't understand why you want to ban it from RFC 5280.

The trust model for the CAs in the CABForum is quite different than the security assumptions made by other CAs who use PKIX. The CABForum trust model ("you will trust every CA in your root pile to issue certs for any domain name") works pretty well for the typical web browser model, but does not work well for other models that have historically been supported by PKIX.

CAs, and CA groups like the CABForum, should be encouraged to make profiles to PKIX as they see fit. Publicly-facing CAs should be encouraged to make their profiles public, as the CABForum did.

--Paul Hoffman

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Apr 2012 18:47:13 +0200

>I didn't hear anyone try "ban" anything.

Wrong word, I'm sorry.

I meant to say, I can't see any reason why this legitimate business need
would not be allowed under 5280.

>RFCs again? That'd seem like an odd way to do stuff.

Actually yes, I would hope this group would have the courage to change
things when it is the right thing to do.
In particular when the spec turns out to be to narrow to meet legitimate
needs.

I do not advocate changing things that would break the security model,
introducing vulnerabilities or breaking backwards compatibility.

Agreed.

Agreed.

>by the argument to change the 5280 rule.

I am. However I like to view it as "allowing more" because we found
legitimate scenarios where it is reasonable to do so.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Apr 2012 21:44:09 +0200 (MEST)

Piyush Jain wrote:
> Believe it or not, there are implementations out there which check
> if a certificate complies with the profile or not, and reject
> them upfront in case of failure.

But you should realize that such behaviour is significantly less
compliant to rfc5280 that not implementing name constraints for
anything besided directory names.

Checking whether a name constraints is marked critical is something that
rfc5280 explicitly recommends _against_.  Since following rfc5280 means
less code then performing such a check, adding such a check requires
a really good rationale.

The logic to check name constraints of the various name forms,
on the other hand, requires huge amounts of non-trivial extra code.
Therefore every implementation option that requires >10 lines of code
is considered a true implementor option in PKIX, something that the
"minimum requirements RP" must be expected to not support.

By defining the concept of a "minimum requirements RP",
PKIX has effectively watered down all non-trivial-to-implement
SHOULDs to MAYs.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 10 Apr 2012 19:45:03 +0000

So what NC would a commercial CA vendor assert, given that most public CAs
do not use namespace-specific Issuers?  (IOW, Verisign issues to any DNS
name.  Is Verisign champing at the bit to create a *.edu Issuer?  What
prevents them from doing so now?)

-- T

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Apr 2012 22:56:37 +0300

> prevents them from doing so now?)

They're not chomping at the bit to create a *.edu issuer, but they may want to sell my company a *.checkpoint.com CA certificate (for more than the wildcard cost), so that we can issue certificates for supportcenter.checkpoint.com, wiki.checkpoint.com, sslvpn.checkpoint.com and opengrok.source.checkpoint.com, while still not allowing us to sell you a gateway with a certificate for cpgateway.mitre.org, and have that certificate chain all the way to Verisign.

They would also not like us to take that certificate and use it in our TLS proxy to sign on-the-fly certificates for gmail, facebook, Amazon and others.

What prevents them from doing it now, is that not having a NC extension will allow us to do both of these things, while adding a critical one will cause iOS clients to fail.

Yoav

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Apr 2012 02:19:11 +0200 (MEST)

Santosh Chokhani wrote:
> 
> Your logic can be applied to any of the certificate extensions identified
> as critical in 5280.

Correct!  See the discussion of what *additional* impact the criticality
flag has on an extension, and why there might be reasons (for the entity
deciding about the trade-off) not to flag an extension as critical.

That document (rfc3647) lists _you_ as one of the authors, so I'm
kind of confused (to put it mildly) to see you argue 100% the opposite
today.

> 
> In my opinion PKIX standards are for secure interoperability.
> What you say exposes some of the clients.

You got it all backwards.  Because of the current requirement,
the situation that we're faced it that _everyone_ is exposed,
and it is not possible to allow mitigation for the subset of clients
that implements that optional protocol feature.

Not protecting anyone at all is definitely worse than not protecting only
those that do not fully implement this feature.

> 
> The harm it does is CAs will point to the RFC and mark the extension
> non critical and the RP software (browser) vendors will not have any
> reason or incentive to implement name constraints.
> This will expose the consumers and businesses.
> 
> We should not dilute the security of a security standard just because
> the largest market capitalization company in the history of human race
> has not implemented a long standing standard correctly.

While I personally try to avoid stuff from Apple as much as I possibly can,
criticising them for rejecting certs signed by CAs with certs containing
a name constraints extensions is a terribly BAD idea.

They're actually *MORE* compliant than many other implementations that
simply ignore name constraints extensions, independent of their criticality.

I don't know whether OpenSSL 0.9.8x will reject name constraints that
are marked critical, but comparing crypto/x509v3/v4_ncons.c from
0.9.8r and 1.0.0d, it don't see the matching of name constraints
in 0.9.8r.  Pretty much 100% of all our *NEW* Linux systems that I run
(and those in use in our company) use OpenSSL 0.9.8x,
and a signficant number of SLES-9 system still use OpenSSL 0.9.7x.

> nameConstraints extension.

The majority of Linux installations is on 0.9.8x or earlier, and
the original discussion was about name constraints primarily for
servers(!) (e.g. DNSName) rather than client certs.   Is the
mod_ssl check really about the **own** server cert (where such a check
would be silly and only hurting the consumer), or about the peer
certificate (where that check is just marginally interesting
for the current discussion).  What wget/curl do when doing server
endpoint identification would be more relevant to the discussion.

And I repeat my complaint that only looking at 5 top-most vendors
is missing the point, because it will miss several hundred million
TLS usage scenarios.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 11 Apr 2012 12:42:19 +0000

On 4/10/12 2:56 PM, "Yoav Nir" <[email-masked]> wrote:

>What prevents them from doing it now, is that not having a NC extension
>will allow us to do both of these things, while adding a critical one
>will cause iOS clients to fail.

We keep coming back to "Beat up on <vendor> via your support agreements."

-- T

---

From: Tom Gindin <[email-masked]>
Date: Wed, 11 Apr 2012 09:49:15 -0400

I don't expect root certificates, or the sort of intermediates 
that Entrust or Verisign create for brands, to contain any 
PermittedSubtree name constraints with the possible exception of Country. 
I would like to see commercial CA's issue intermediates to other 
organizations with name constraints for that organization.

Tom Gindin

From:   "Miller, Timothy J." <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, Santosh Chokhani 
<[email-masked]>, 
Cc:     IETF PKIX <[email-masked]>
Date:   04/10/2012 03:46 PM
Subject:        Re: [pkix] Proposal: Change the Criticality Requirement of 
Name

-- T

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 11 Apr 2012 20:10:31 +0200

Erwann Abalea a écrit :
> For example the deltaCRLIndicator extension, which also MUST be set
> critical. You probably know why it is dangerous for a RP to receive a
> CRL with such an extension non critical. Following your logic, the CA
> defines what is secure and what isn't, so this extension could be set
> non critical. Is that right?
> [...]

The basis of his argumentation is indeed that all extensions aren't 
created equal, and "name constraint" and "deltaCRLIndicator" are a 
perfect example of that.

With deltaCRLIndicator, a proper deltaCRL issued by the CA *can* be used 
to abuse a client that doesn't properly handle it.
Because the deltaCRL won't contain all revoked certificate so any client 
that accept it must absolutely take under account the fact it's a delta 
CRL to handle it properly.

With name constraints, a certificate properly issued by the CA *can't* 
be used to abuse a client that doesn't properly handle it.
An uncompromised CA will only issue certificates that respect the 
applicable name constraints, so the name constraint is there only as a 
double-check, and is not a basic requirement without which the 
certificate simply couldn't be properly used.
Still, a rogue CA that issues a cert with a bad name will have to handle 
the fact most client will properly reject that certificate, which will 
certainly very fast rise an alert against that CA.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 11 Apr 2012 20:33:48 +0200

Martin Rex a écrit :
>   A subCA cert with name constraints that is

My understanding is that this ought more be "MUST be accepted" and not 
SHOULD :

4.2.  Certificate Extensions
    [...] A non-critical
    extension MAY be ignored if it is not recognized, but MUST be
    processed if it is recognized. [...]

I understand some people may defend this does not explicitly say what 
you MUST/SHOULD do with a non-critical extension that you expect to be 
critical but isn't, and that whilst the Certification Path Validation in 
6 ignores the critically of extension, you are allowed to complement it 
with further verification.

By the way, there is an incorrect text in 4.2.1.10 :
    [...] If a name constraints extension that is marked as critical
    imposes constraints on a particular name form, and an instance of
    that name form appears in the subject field or subjectAltName
    extension of a subsequent certificate, then the application MUST
    either process the constraint or reject the certificate.
    [...] if an application encounters a critical name
    constraints extension that specifies other values for minimum or
    maximum for a name form that appears in a subsequent certificate, the
    application MUST either process these fields or reject the
    certificate.

This, twice, can be interpreted as meaning the extension could be 
ignored if not marked critical. This of course directly contradicts 4.2.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 11 Apr 2012 16:52:36 -0400

> certificate simply couldn't be properly used.

As I noted previously 
(http://www.ietf.org/mail-archive/web/pkix/current/msg30778.html) this 
is not true.  Not all PKIs are hierarchies.  In some cases a 
nameConstraints extension is simply intended to restrict the set of 
certificates accepted by the issuer's relying parties, and it is does 
not represent a restriction on the set of certificates that the subject 
CA may legitimately issue.

> ignored if not marked critical. This of course directly contradicts 4.2.

This text is not incorrect.  It is merely silent on how to process a 
nameConstraints extension is not marked as critical.  This was 
intentional, since (for some reason) we were unable to come to consensus 
on the proper behavior of a client encountering a non-critical 
nameConstraints extension where the client was capable of processing 
some of the name forms in the extension, but not all of them.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2012 23:47:08 +0100

So I like Paul's idea but think David is right that its not quite
right as stated. I've no problem with 2119 purity either, so how
about taking Paul's approach but naming names (sort of) and saying
that NC MUST be critical except in the current public CA/web
browser model, where NC SHOULD be critical on the basis that
some implementations still need to catch up (with RFC 2459;-) and
explain that that's ok because it does improve matters for some
and is no worse than the status-quo for those RP's not supporting
NC.

With a wordsmithed version of the above I'd find that ok.

Personally, I think that might be better as a separate document
updating 5280 and not necessarily from the PKIX WG, so's we can
obsolete that without side-effect once NC is supported widely
enough, but I won't quibble about where it gets documented.

The point that 5280's assertion that NC MUST be critical is a
harm-reduction measure and not for interop was well-made too
btw.

S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Apr 2012 07:40:58 +0300

> and is no worse than the status-quo for those RP's not supporting

As Martin said, implementations don't have to catch up. They can remain without support for name constraints forever. Besides, if all implementations do catch up, then criticality ceases to be an issue at all. Any implementation that recognizes the extension MUST process it regardless of criticality.

Yoav

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 12 Apr 2012 09:08:05 +0200

> constraint was marked non critical.

However it's quite ambiguous about it, which is a bad idea.

If you consider it properly, they are some case where it would actually 
help to reject any certificate with the non-critical extension, because 
it would guarantee security problems can immediately be seen.

For example, it would be best to reject crl with a non critical "Delta 
CRL Indicator" because that means one produced by error would be 
directly identified as invalid, instead of being perfectly usable until 
it falls into the hand of someone who doesn't implement the extension 
and where it's a security failure.

OTOH treating a certificate containing a non-critical "Name Constraints" 
as invalid would impair compatibility with no real gain.

At the end, the conclusion is :
- The difference between the two actually is that "Delta CRL Indicator" 
has a good reason to be critical and "Name Constraints" doesn't

So in a ideal world :
- Extension that don't have a really good reason to be critical should 
be changed to non critical, including "Name Constraints"
- Software should reject as invalid certificates containing extension 
required to be critical that aren't, because there's a real security 
risk in having issued one and that risk ought to be identified as soon 
as possible

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 12 Apr 2012 08:52:39 -0400

That depends on who decides whether a reason is good.  PKI does not
exist for the benefit of CA operators or subscribers (in this case,
server operators), it exists for the benefit of relying parties.  When I
go to my bank web site, it is in my interest (not the bank's directly,
much less the CA's) to ensure that the site is what it claims to be.

If security was a priority for me, I would do my banking on a device
that warned me if something was fishy over a device that provided no
such warning.  Name constraints provides the warning if the device
supports it, but not if the device doesn't support the extension and the
extension is non-critical.

Delta CRLs can be misused to trick RPs without any mistakes by a CA.
Forged names require a CA to 1) make a mistake, 2) deliberately issue a
forged name, or 3) be induced to do so by an attacker.  But that
difference isn't sufficient to claim that one extension has a "good"
reason to be critical and the other does not.  In both cases the RP is
fooled and can suffer harm if the extension is non-critical, and the
harm could be prevented by making the extension critical.

This discussion is whether interoperability is more important than
security, which in many cases it is.  But that doesn't mean that
avoiding security failures that could harm the RP is not a "good"
reason.

I like Stephen Farrell's suggestion to be explicit about the reason for
making NC NC - it is an exception made for applications with significant
market share that do not yet support it, and the security of the
Internet would be improved when those applications are fixed and the
exception is no longer needed for interoperability.

Dave

-----Original Message-----
From: Jean-Marc Desperrier

---

From: Piyush Jain <[email-masked]>
Date: Thu, 12 Apr 2012 07:00:04 -0700

> From: [email-masked]
> To: [email-masked]
> Date: Thu, 12 Apr 2012 07:40:58 +0300
> CC: [email-masked]
> As Martin said, implementations don't have to catch up. They can remain without support for name constraints forever. 
To be compliant implementations must process Name Constraints. Off course they don't have to catch up if compliance is not important to them.>Besides, if all implementations do catch up, then criticality ceases to be an issue at all. Until then, they are vulnerable if the understand criticality and don't recognize name constraints, which is true of most non compliant implementations.
>Any implementation that recognizes the extension MUST process it regardless of criticality.
and compliant implementations MUST recognize (and process) name constraint.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Apr 2012 11:19:34 -0400

I agree that users are best served by having secure devices.

But in this particular case the rate of mis-issue incidents does not
come anywhere close to justifying bricking the vast majority of mobile
devices made thus far.

I really can't see the justification for forcing the issue to a split
between the commercial PKI world and the IETF. The CABForum BR
guidelines are currently a profile of PKIX. If you continue to force
the issue here they will end up as a profile of X.509v3.

It is possible that there will be a re-combination at a later date,
but do not count on that being inevitable. The critical mass of the
cryptography industry has been in the commercial sector for 15 years
now. This particular forum has given the younger engineers no real
stake in or ability to influence a process that consists of them
watching their ideas being trampled by folk making bogus appeals to
their own authority.

I can build a more secure Internet without you, Kent and Santosh but I
really do need their help.

On Thu, Apr 12, 2012 at 8:52 AM, Kemp, David P. <[email-masked]> wrote:
> server operators), it exists for the benefit of relying parties.  When II

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 15 Apr 2012 16:09:34 +0200

It seems like a moderately good idea sending out yet another bunch of messages to
convince "the other camp" that they are wrong because *nobody is actually wrong*;
it is (as often) rather a matter of principles and priorities.

Since "Rough Consensus" obviously isn't achievable, a formal voting procedure could
be used instead for settling this somewhat heated issue.

The proposal is here:

http://www.ietf.org/mail-archive/web/pkix/current/msg30734.html

If the proposal is taken it means that this would eventually become a PKIX standard,
otherwise the CAB forum's specifications would be the (non-PKIX-endorsed) alternative.

FWIW, I cast my vote here: I'm for the proposal.

Regards,
Anders Rundgren

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Apr 2012 17:16:54 +0300

> FWIW, I cast my vote here: I'm for the proposal.

"We reject ... and voting, we believe in rough consensus and ..."

Having said that, +1

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 15 Apr 2012 07:31:00 -0700

The proposal is poorly worded. Changing the word "MUST" to "SHOULD" without saying what the exception to the "SHOULD" are causes worse security and insufficient guidance to those who would benefit from changing their CA software.

Anders: instead of you taking on the role of WG Chair, maybe you could do a wee bit of work, like writing a clearer proposal. Given that clarity is not your strong point, it still would help get what you and others want here.

If there is a solid proposal for "SHOULD be marked critical except Xyz", the WG chairs should consider a consensus call.

None of this affects CABForum's ability to do whatever they want on the topic.

--Paul Hoffman

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 15 Apr 2012 17:56:05 +0200

On 2012-04-15 16:31, Paul Hoffman wrote:
> The proposal is poorly worded. Changing the word "MUST" to "SHOULD" without saying
> what the exception to the "SHOULD" are causes worse security and insufficient guidance
> to those who would benefit from changing their CA software.
> 
> Anders: instead of you taking on the role of WG Chair, maybe you could do a wee 
> bit of work, like writing a clearer proposal.

> Given that clarity is not your strong point,

Thanx :-)

> it still would help get what you and others want here.

As Rob wrote, he proposed a compromise. When I make specifications
they just have to be implementable.  Here is a condensed version of
what I would put in an RFC.

If the NC criticality bit is set, and the application doesn't support
NC extensions, a confirming application MUST reject the certificate.

If an application implements support for NC extensions a confirming application
MUST process NCs as described.  If the application implements support for NC
extensions but doesn't recognize one or more NC objects under processing,
a confirming application MUST reject the certificate.

If the NC criticality bit is not set and the application doesn't support NC
extensions, a confirming application MAY silently ignore NC processing altogether.

Trying to squeeze in more stuff in the non-critical case would IMHO only lead to
"slimy" code and specifications.  This part more or less remains in "vendor land".

Anders

---

From: "Erik Andersen" <[email-masked]>
Date: Sun, 15 Apr 2012 18:02:10 +0200

Sounds like an echo of X.509

Eri

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Anders
Rundgren
Sendt: 15. april 2012 17:56
Til: Paul Hoffman
Cc: IETF PKIX
Emne: Re: [pkix] Voting on the Proposal: Change the Criticality Requirement
of Name Constraints

On 2012-04-15 16:31, Paul Hoffman wrote:
> The proposal is poorly worded. Changing the word "MUST" to "SHOULD" 
> without saying what the exception to the "SHOULD" are causes worse 
> security and insufficient guidance to those who would benefit from
changing their CA software.
> 
> Anders: instead of you taking on the role of WG Chair, maybe you could 
> do a wee bit of work, like writing a clearer proposal.

Thanx :-)

> it still would help get what you and others want here.

As Rob wrote, he proposed a compromise. When I make specifications they just
have to be implementable.  Here is a condensed version of what I would put
in an RFC.

If the NC criticality bit is set, and the application doesn't support NC
extensions, a confirming application MUST reject the certificate.

If an application implements support for NC extensions a confirming
application MUST process NCs as described.  If the application implements
support for NC extensions but doesn't recognize one or more NC objects under
processing, a confirming application MUST reject the certificate.

If the NC criticality bit is not set and the application doesn't support NC
extensions, a confirming application MAY silently ignore NC processing
altogether.

Trying to squeeze in more stuff in the non-critical case would IMHO only
lead to "slimy" code and specifications.  This part more or less remains in
"vendor land".

Anders

> 
> If there is a solid proposal for "SHOULD be marked critical except Xyz",
the WG chairs should consider a consensus call.