Subject: [pkix] Criticality of Name Constraints in 5280

From: Rob Stradling <[email-masked]>
Date: Thu, 29 Mar 2012 21:05:11 +0100

RFC5280 says:
"4.2.1.10.  Name Constraints
...Conforming CAs MUST mark this extension as critical"

Can anyone explain the reason for this requirement?

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: Santosh Chokhani <[email-masked]>
Date: Thu, 29 Mar 2012 16:09:35 -0400

It is critical so that relying parties that do not understand this extension do not unwittingly accept a certificate that has been issued for a name space the CA is specifically prohibited from.

If the extension was made NC, relying party will accept a certificate for which the CA has violated the constraint.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Thursday, March 29, 2012 4:05 PM
To: [email-masked]
Cc: Kathleen Wilson
Subject: [pkix] Criticality of Name Constraints in 5280

RFC5280 says:

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
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Adam Langley <[email-masked]>
Date: Thu, 29 Mar 2012 16:14:26 -0400

> Should RFC5280 be updated to specify that Name Constraints need not be

If the certificate would otherwise have been an unrestricted
intermediate CA then obviously non-critical Name Constraints are
beneficial.

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.

Cheers

AGL

---

From: Carl Wallace <[email-masked]>
Date: Thu, 29 Mar 2012 16:34:06 -0400

>intermediate CA then obviously non-critical Name Constraints are

What do you mean by otherwise unrestricted?  That sounds like the question
is whether to include name constraints at all.

>that the MUST in RFC 5280 is unhelpful and support the idea that it

Do you mean you are not aware of any path validation software that
enforces name constraints, any path validation software that requires name
constraints to be critical or any CA software that requires name
constraints to be critical when generating certificates?

---

From: Adam Langley <[email-masked]>
Date: Thu, 29 Mar 2012 16:46:15 -0400

> is whether to include name constraints at all.

Yes. The reality is that CAs do issue intermediate CA certificates to
organisations for that are intended to be used with a small number of
domains (i.e. internally).

Today, those intermediate CA certificates have no technical
constraints, save perhaps a path length constraint. Using a critical
name constraint would break many clients that can't process them.
Using a non-critical name constraint would technically constrain the
intermediate with no loss in functionality. (That's assuming that
there aren't clients that reject non-critical name constraints.) Since
the alternative is a non-constrained certificate, it would seem to be
a good thing to do where possible.

> constraints to be critical

I mean that I've not encountered any path validation software that
requires that a name constraint, when present, to be critical. If
anybody knows otherwise, I'm sure Rob would be interested to hear
about it.

Cheers

AGL

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Mar 2012 22:38:29 +0100

> If the extension was made NC, relying party will accept a certificate for which the CA has violated the constraint.

+1 to Santosh's point. If RP s/w skips over it then it seems
pointless in terms of the function for which it was designed.
(All of 17 or so years ago!) If some other function is what's
wanted really then I don't see why this change is any easier
than another extension.

I could maybe see an argument to allow some equivalent to
non-critical NameConstraints as a way of helping to get
initial deployment but that doesn't seem to be the argument
being offered here.

But starting to (finally) use this extension would be a good
thing, so maybe it's worth thinking about.

S

> Senior Research&  Development Scientist

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 29 Mar 2012 16:42:39 -0700

Is it meaningful/useful to do TAMP without supporting this extension as critical?

> Should RFC5280 be updated to specify that Name Constraints need not be critical?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Tom Gindin <[email-masked]>
Date: Thu, 29 Mar 2012 21:02:00 -0400

It may not be meaningful to implement TAMP without supporting this 
extension, but relying parties which recognize an extension don't usually 
need to care if the extension is critical or not.  Is it truly more secure 
to have a lightly deployed critical constraint extension, such that most 
single-organization intermediates have no name constraint for RP's to 
enforce, than a widely deployed non-critical one which is enforced by the 
majority of RP's but ignored by a quarter of them?
        I think that requiring constraint extensions to be critical can 
sometimes be a case of making the best the enemy of the good.

Tom Gindin

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

From:   "Henry B. Hotz" <[email-masked]>
To:     Santosh Chokhani <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>, Kathleen Wilson 
<[email-masked]>
Date:   03/29/2012 07:43 PM
Subject:        Re: [pkix] Criticality of Name Constraints in 5280
Sent by:        [email-masked]

Is it meaningful/useful to do TAMP without supporting this extension as 
critical?

On Mar 29, 2012, at 1:09 PM, Santosh Chokhani wrote:

> It is critical so that relying parties that do not understand this 
extension do not unwittingly accept a certificate that has been issued for 
a name space the CA is specifically prohibited from.
> 
> If the extension was made NC, relying party will accept a certificate 
for which the CA has violated the constraint.
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.
critical?

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 29 Mar 2012 21:22:31 -0400

Tom,

If you go back to the archives, we have asked for and 5280 bis clarifies that the relying parties need not and should not examine criticality of any extension.  This came up 5-6 years back in the context of Sun Java and inhibit any policy.  So, any RP that enforces constraints on the producers that are NOT stipulated in Section 6 of 5280, are over-reaching.

In terms of making extension non-critical, folks can do so if they want to.  But, 5280 should not recommend that.

The fact that Apple and Mozilla have not gotten the semantics of an extension right after over 10 years is a problem that Mozilla and Apple need to address and not a security standard.

I would not want an upstream offline, secure CA to constrain an online CA and due to compromise of the online CA or RA or rogue RA to create certificates for Google or other major companies and 25% (your number) of browsers to be snookered into using them.

This stuff is not hard to understand or implement.  Why do not Browsers implement the 10-15 old X.509 standard properly before adding band aids that do not scale.  There are plenty of toolkits out there that do this right and some of them are available with source code on open source for variety of platforms.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, March 29, 2012 9:02 PM
To: Henry B. Hotz
Cc: Kathleen Wilson; [email-masked]; Santosh Chokhani
Subject: Re: [pkix] Criticality of Name Constraints in 5280

        It may not be meaningful to implement TAMP without supporting this extension, but relying parties which recognize an extension don't usually need to care if the extension is critical or not.  Is it truly more secure to have a lightly deployed critical constraint extension, such that most single-organization intermediates have no name constraint for RP's to enforce, than a widely deployed non-critical one which is enforced by the majority of RP's but ignored by a quarter of them?
        I think that requiring constraint extensions to be critical can sometimes be a case of making the best the enemy of the good.

Tom Gindin

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

critical?

---

From: Sean Leonard <[email-masked]>
Date: Thu, 29 Mar 2012 20:54:11 -0700

I agree with Santosh's assessment. [Except the Mozilla part: the new 
PKIX API is supposed to implement name constraints.]

Name constraints are very useful to constrain the (otherwise unbounded) 
authority of intermediate CAs, when intermediate CAs are issued to 
specific parties for specific communities.

Every customer that relies upon certificates, and that has procurement 
standards in place (e.g., government agencies), ought to require RFC 
5280 compliance--including processing name constraints--as a condition 
of purchase.

Reality is very different. iOS/OSX devices don't implement every 
standard properly (and also aren't bought en masse by government 
agencies), yet are shiny and manage to capture 50% of the mobile 
smartphone industry's profits. iOS/OSX will probably implement name 
constraints when it hits them in the pocketbook, or becomes a PR fiasco. 
On the other hand, if they do not feel the need to "conform to RFC 
5280", and don't hold themselves out to do so, it's a moot point.

Yet the standard ought to toe the line; otherwise, you have a standard 
that doesn't offer any guarantees of standard behavior. If the CA 
conforms to RFC 5280, the CA expects applications to honor what it 
technically imposes. While 5280 requires applications to process name 
constraints, it doesn't require applications to check the criticality 
flag of the name constraints extension. 5280 only imposes the 
criticality flag on CAs, not applications. So the fact that AGL has not 
encountered path validation software that requires the criticality flag 
to be set, is expected. Perhaps Mozilla should take the opportunity to 
needle Apple about its lack of support.

Sean

On 3/29/2012 6:22 PM, Santosh Chokhani wrote:
> From:   "Henry B. Hotz"<[email-masked]>
> To:     Santosh Chokhani<[email-masked]>,
> Cc:     "[email-masked]"<[email-masked]>, Kathleen Wilson
> <[email-masked]>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Mar 2012 08:19:36 -0400

At 4:46 PM -0400 3/29/12, Adam Langley wrote:
>...

Adam, I applaud your interest in using NameConstraints to improve secruity
relative to the browser public TA trust model.

BBN has developed and used (and sometimes sold) CA SW that enforces 
the critical marking requirement, probably since the late 1990's. 
It's been part of the PKIX standards since the beginning, RFC 2459 in 
1999. However, as Santosh noted, an RP need not enforce the marking, 
just pay attention to it when present. I don't recall if our RP (vs. 
CA) software tried to enforce the marking, or if there was a local 
option to do so, or not.

Santosh also noted the reason this is extension MUST be critical. The 
problem we face here is that you want to make use of this extension, 
yet not require strict adherence by RPs, to enable an incremental 
rollout of the feature. The concern is that RPs might not follow 5280 
(and its 2 predecessor cert & CRL profile RFCs) re support of this 
extension.

I'd like to see a survey of which RPs in the context of interest do 
not follow a part of the standard that has been around for >10 years, 
and encourage them to fix this problem.

Again, I am encouraged by efforts to improve secruity in the browser 
PKI context, but changes to 5280 need to be very well justified, and, 
based on the discussion so far, I don't think that criterion has been 
met. CAs should follow the RFC, and mark the extension as critical. 
RPs have been required to support this extension for a very long time.

Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 30 Mar 2012 09:48:59 -0400

+1.

This is not a case of better being the enemy of good - RP applications
can do anything they want, including using a manufacturer-default trust
anchor list, ignoring or incorrectly processing any certificate field or
extension, and barfing on any standards-compliant input.  But the
critical flag signals intent of the public key infrastructure -
non-critical can be safely ignored while ignoring critical extensions
results in security-relevant violations of the PKI's intent.  A PKI that
includes name constraints but signals that ignoring them is not
security-relevant is lying.   It would be great if all applications
understood the signal, but some percentage not understanding it is a
lesser evil than making the signal itself incorrect.

Dave

-----Original Message-----
From: Sean Leonard

criticality flag on CAs, not applications.

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Mar 2012 20:51:28 +0200 (MEST)

> relative to the browser public TA trust model.

I'm a little confused.  The endpoint identification performed with the
"browser public TA trust model" is based on DNS names rather than on
distinguished directory names.

> 
> The concern is that RPs might not follow 5280 (and its 2 predecessor
> cert & CRL profile RFCs) re support of this extension.

rfc5280 and its predecessors "require" support for name constraints
*ONLY* on the directory name.  Support for name constraints on
subjectAltNames (those that are typically used for server endpoint
identification performed with the "browser public TA trust model"
is _not_ required, only recommended.  So rfc5280 compliance
seem not to help here at all, see last paragraph here:

  http://tools.ietf.org/html/rfc5280#page-40

Looking at *real* existing certs, like the one presented by
"https://www.google.pl" when connecting with *NO* TLS extension SNI,
contains 436 subject alt names of type DNSName, all different.

If that cert would have to be equipped with subject alt name constraints
for each and every of those names, it would probably grow much larger
than 16 KByte and cause a number of TLS clients to abort the handshake
due to the size of the server certificate...

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 30 Mar 2012 15:09:58 -0400

The certificate you cite is intended for the following purposes:
"Ensures the identity of a remote computer",

i.e. it is an end entity cert.  Why would an EE cert be affected when
5280 prohibits it?:
   "The name constraints extension, which MUST be used only in a CA
   certificate, ..."

And by extension, what would be the purpose of putting name constraints
in the certificate of the terminal CA in a path (the one that issued the
EE certs)?  Hammers can be used on thumbs as well as nails; a
cross-certification environment must be designed intelligently for name
constraints to be of any use.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Rex
Sent: Friday, March 30, 2012 2:51 PM
To: Stephen Kent
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Criticality of Name Constraints in 5280

Stephen Kent wrote:
> Adam, I applaud your interest in using NameConstraints to improve 
> secruity relative to the browser public TA trust model.

rfc5280 and its predecessors "require" support for name constraints
*ONLY* on the directory name.  Support for name constraints on
subjectAltNames (those that are typically used for server endpoint
identification performed with the "browser public TA trust model"
is _not_ required, only recommended.  So rfc5280 compliance seem not to
help here at all, see last paragraph here:

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Mar 2012 21:23:26 +0200 (MEST)

> constraints to be of any use.

Admittedly, I had confused the certificate that would have to carry
the name constraints extensions.  But the problem is actually the same.

The discussion is about constraining a subCA / intermediateCA, and per
TLS spec, the server MUST send his entire cert chain in the Certificate
handshake message (and may omit only the self-signed rootCA cert
at the end of the path).  Since the limitation in some TLS clients in
the installed base is about the size of a handshake message (or more
precisely about the lack of support for fragmented handshake messages)
combined with a TLS record size limit of 16 KByte.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 30 Mar 2012 14:12:18 -0700

I agree with the standard that an extension which could cause a security issue if ignored should be marked critical.  Also that RP software should hard-fail if it doesn't understand such an extension.  Anything else would seem to significantly reduce the clarity and value of the standard.

That said, it would seem that the real-world situation conspires against such functionality.  Could the people working on 5280bis please include some practical guidance for how to deal with an environment which does not fully support that behavior?  Surely there are people on this list who have actually implemented or used name constraints (e.g. at BBN, hint, hint ;-) and can provide experience with how to deal with the compatibility issues.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 30 Mar 2012 18:31:37 -0400

Martin:

        The name constraint needed would probably just be a list of 
permitted subtrees of type DNSName.  In some intermediate certificates, 
each subtree would contain the name of a TLD, while in others each subtree 
would contain a DNS domain belonging to the organization for whom the 
intermediate issued certs.  It seems unlikely that there would be more 
than ten or twelve of them in a particular intermediate, and thus they'd 
take up much less than 1 KB.  That size is normally increased by only two 
bytes by making the extension critical.

Tom Gindin

From:   Martin Rex <[email-masked]>
To:     [email-masked] (Kemp David P.), 
Cc:     [email-masked]
Date:   03/30/2012 03:28 PM
Subject:        Re: [pkix] Criticality of Name Constraints in 5280
Sent by:        [email-masked]

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 31 Mar 2012 20:14:43 -0400

Dave,

I agree with you for the most part.

There may be scenarios when name constraints in terminal CA certificate make sense.

One example is when a public trust "trust anchor" or intermediate CA may issue certificated to online terminal CA may provide them their name space or inhibit them from issuing some high value site certificates.

Another example is for security reasons an Enterprise may have separate terminal CA for human and device certificates and auto issuance of devices being less secure, may want to constrain the name spaces for both CAs.

There may be other example.  Thus, we should not say that terminal CAs never need name constraints in their certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Friday, March 30, 2012 3:10 PM
To: [email-masked]
Subject: Re: [pkix] Criticality of Name Constraints in 5280

And by extension, what would be the purpose of putting name constraints in the certificate of the terminal CA in a path (the one that issued the EE certs)?  Hammers can be used on thumbs as well as nails; a cross-certification environment must be designed intelligently for name constraints to be of any use.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, March 30, 2012 2:51 PM
To: Stephen Kent
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Criticality of Name Constraints in 5280

> secruity relative to the browser public TA trust model.

I'm a little confused.  The endpoint identification performed with the "browser public TA trust model" is based on DNS names rather than on distinguished directory names.

rfc5280 and its predecessors "require" support for name constraints
*ONLY* on the directory name.  Support for name constraints on subjectAltNames (those that are typically used for server endpoint identification performed with the "browser public TA trust model"
is _not_ required, only recommended.  So rfc5280 compliance seem not to help here at all, see last paragraph here:

Looking at *real* existing certs, like the one presented by "https://www.google.pl" when connecting with *NO* TLS extension SNI, contains 436 subject alt names of type DNSName, all different.

If that cert would have to be equipped with subject alt name constraints for each and every of those names, it would probably grow much larger than 16 KByte and cause a number of TLS clients to abort the handshake due to the size of the server certificate...

-Martin