Subject: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Apr 2012 10:28:16 -0700

This proposal is an alternative to the people who want the "MUST mark as critical" to be a "SHOULD". So far, those proposals have not given CAs enough guidance about when the "SHOULD" is and is not important. Instead, we can look at this as clarification of what the current "MUST" means.

===========================

In describing the Name Constraints and Policy Contraints extensions, RFC 5280 says:
   Conforming CAs MUST mark this extension as
   critical
In these cases, the "MUST" language from RFC 2119 is based on a potential for causing harm, not the need for interoperability. This interpretation can be seen by looking in Section 6.1 of RFC 5280, which says:
   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.

The Name Constraints and Policy Contraints extensions do not need to be marked critical if a relying party has no restrictions on the names or policies of end entity certificates issued under a particular trust anchor. For example, if such a trust anchor issues a CA certificate with the Name Constraints extension that limits that CA's ability to issue certificates, and if the Name Constraints extension in that CA's certificate is not marked critical, and if the CA issues an end entity certificate whose name is outside the set of ones it is allowed to issue for, and if the relying party does not understand the Name Constraints extension, the relying party is no worse off because it would have accepted that end entity certificate issued directly by the trust anchor.

Given this rationale, the statement "Conforming CAs MUST mark this extension as critical" is interpreted as "Conforming CAs MUST mark this extension as critical when there is a potential for harm in relying parties that do not understand the extension", not universally.

===========================

Thoughts?

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Apr 2012 22:25:02 +0300

I think MUST means MUST. The thing that means "MUST unless it's safe not to do it" is called SHOULD. At least that is my understanding of RFC 2119.

A CA that issues a sub-CA certificate with non-critical name constraints does not conform to RFC 5280. That may not be a bad thing, but I don't think we can clarify that fact away.

On Apr 11, 2012, at 8:28 PM, Paul Hoffman wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Apr 2012 14:25:55 -0700

> I think MUST means MUST. The thing that means "MUST unless it's safe not to do it" is called SHOULD. At least that is my understanding of RFC 2119.

Direct quote from RFC 2119:

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.

> A CA that issues a sub-CA certificate with non-critical name constraints does not conform to RFC 5280.

One purpose of draft-ietf-pkix-rfc5280-clarifications it to clarify RFC 5280; my proposal is for such a clarification, given the confusion.

--Paul Hoffman

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 12 Apr 2012 01:09:53 +0200

Interesting idea Paul,

I think this text might be a bit confusing though.

Isn't what you intend to say the following:

In cases where the CA need to enforce that relying parties rejects
certificates issued outside of a set NC, the CA MUST mark this extension
as critical.

In cases where the CA need to declare a limited name space without
enforcing any particular behavior on non-conformant relaying parties that
do not implement the NC extension, the CA MAY mark this extension as
non-critical.

/Stefan

On 12-04-11 7:28 PM, "Paul Hoffman" <[email-masked]> wrote:

>This proposal is an alternative to the people who want the "MUST mark as
>critical" to be a "SHOULD". So far, those proposals have not given CAs
>enough guidance about when the "SHOULD" is and is not important. Instead,
>we can look at this as clarification of what the current "MUST" means.
>
>In these cases, the "MUST" language from RFC 2119 is based on a potential
>for causing harm, not the need for interoperability. This interpretation
>can be seen by looking in Section 6.1 of RFC 5280, which says:
>The Name Constraints and Policy Contraints extensions do not need to be
>marked critical if a relying party has no restrictions on the names or
>policies of end entity certificates issued under a particular trust
>anchor. For example, if such a trust anchor issues a CA certificate with
>the Name Constraints extension that limits that CA's ability to issue
>certificates, and if the Name Constraints extension in that CA's
>certificate is not marked critical, and if the CA issues an end entity
>certificate whose name is outside the set of ones it is allowed to issue
>for, and if the relying party does not understand the Name Constraints
>extension, the relying party is no worse off because it would have
>accepted that end entity certificate issued directly by the trust anchor.
>
>Given this rationale, the statement "Conforming CAs MUST mark this
>extension as critical" is interpreted as "Conforming CAs MUST mark this
>extension as critical when there is a potential for harm in relying
>parties that do not understand the extension", not universally.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Apr 2012 16:34:01 -0700

> I think this text might be a bit confusing though.

Could be; RFC 2119 "MUST" can mean one of three things, and we are using the least common one here.

> certificates issued outside of a set NC, the CA MUST mark this extension

No, not at all. A CA never needs to enforce anything on an RP. A CA might want to reduce its liability by constraining CAs under it, and if that CA believes that some RPs only trust the CA for some names or policies, the CA needs to alert the RP that sub-CAs have more constraints.

That's probably not less confusing. :-)

> do not implement the NC extension, the CA MAY mark this extension as

The CA MAY do whatever it wants for marking anyway, given that we say that RPs SHOULD NOT check conformance. So I don't think we need to change the rule, only clarify it.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Apr 2012 01:36:59 +0200 (MEST)

> do not implement the NC extension, the CA MAY mark this extension as

As I previously said, not implementing NC for SubjectAltNames
is 100% rfc5280 conformant.  It is called "minimal requirements RP".

Most Non-conforming RPs will simply ignore critical NC constraints.

The "MAY mark this extension as non-critical" is only to take
care of rfc5280-conforming "minimal requirements RPs", which do not
implement the optional NC processing of SubjectAltNames,
and reject the cert due to NC being marked critical,
in full conformance with rfc5280

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Apr 2012 07:36:49 +0300

>   on implementors where the method is not required for

That's guidance. I think the authors of RFC 5280 and its predecessors did not follow that guidance, but that's because I don't think a non-critical name constraints (NCNC?) causes harm. Once it's there, MUST still means MUST.

> One purpose of draft-ietf-pkix-rfc5280-clarifications it to clarify RFC 5280; my proposal is for such a clarification, given the confusion.

The confusion is about what RFC 5280 should say, not about what it does say.

Yoav

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Apr 2012 13:55:52 -0400

> This proposal is an alternative to the people who want the "MUST mark as critical" to be a "SHOULD". So far, those proposals have not given CAs enough guidance about when the "SHOULD" is and is not…

I am still unconvinced that this is desirable.

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 12 Apr 2012 14:50:42 -0400

Paul,

As I noted in my previous messages, it is a mistake to only think about 
public roots, hierarchical PKIs, and sub-CAs.  The example that I used 
was the DoD Root CA.  DoD has a policy of only accepting (as a relying 
party) certificates issued at the Medium Hardware and High assurance 
levels.  It reflects this policy in its cross-certificate to the Federal 
Bridge CA by including a critical policyConstraints extension.  The 
Federal Bridge CA is not a sub-CA of the DoD Root and the inclusion of 
the constraints extension by DoD is not to notify DoD relying parties 
that the Federal PKI is not supposed to be issuing certificates at lower 
assurance levels.  The constraints extension is enforcing on DoD relying 
parties that they may only accept the subset of Federal PKI-issued 
certificates that have been issued at an assurance level acceptable to DoD.

This is very different from a hierarchical PKI, in which a CA may 
procedurally limit what certificates a sub-CA may issue.  In this case 
it would likely be a sign of an error if a sub-CA issued a certificate 
that did not satisfy a constraint (policyConstraints or nameConstraints) 
specified in a cross-certificate issued to the sub-CA.

In the non-hierarchical case, failure to process a constraints extension 
will lead to the relying party accepting certificates that it should not 
be accepting.  In the hierarchical case, failure to process a 
constraints extension will only lead to the relying party accepting 
certificates that it should not be accepting if a sub-CA issued a 
certificate that it shouldn't have issued (and the bad certificate does 
not satisfy the constraint).

Dave

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Apr 2012 13:23:36 -0700

I'm not sure why this message was addressed to me, since I didn't say anything below that indicates limiting our view to public roots and hierarchical PKIs. Even in the US DoD CA case, the CA does not need to enforce anything on an RP. I agree strongly with your last paragraph, about what happens when those RP fail to process a constraints extension, but that doesn't mean that the CA needs to enforce anything: it is the systems that are RPs that need to enforce either understanding the constraints or stopping validation when they see the critical bit on something they don't understand.

--Paul Hoffman

On Apr 12, 2012, at 11:50 AM, David A. Cooper wrote:

> Paul,
> 
> As I noted in my previous messages, it is a mistake to only think about public roots, hierarchical PKIs, and sub-CAs.  The example that I used was the DoD Root CA.  DoD has a policy of only accepting (as a relying party) certificates issued at the Medium Hardware and High assurance levels.  It reflects this policy in its cross-certificate to the Federal Bridge CA by including a critical policyConstraints extension.  The Federal Bridge CA is not a sub-CA of the DoD Root and the inclusion of the constraints extension by DoD is not to notify DoD relying parties that the Federal PKI is not supposed to be issuing certificates at lower assurance levels.  The constraints extension is enforcing on DoD relying parties that they may only accept the subset of Federal PKI-issued certificates that have been issued at an assurance level acceptable to DoD.
> 
> This is very different from a hierarchical PKI, in which a CA may procedurally limit what certificates a sub-CA may issue.  In this case it would likely be a sign of an error if a sub-CA issued a certificate that did not satisfy a constraint (policyConstraints or nameConstraints) specified in a cross-certificate issued to the sub-CA.
> 
> In the non-hierarchical case, failure to process a constraints extension will lead to the relying party accepting certificates that it should not be accepting.  In the hierarchical case, failure to process a constraints extension will only lead to the relying party accepting certificates that it should not be accepting if a sub-CA issued a certificate that it shouldn't have issued (and the bad certificate does not satisfy the constraint).
> 
> Dave
>

---

From: Tom Gindin <[email-masked]>
Date: Tue, 17 Apr 2012 09:16:49 -0400

That is certainly a strong reason for such a cross-certificate to 
use a critical name constraint.  It doesn't mean that hierarchical 
certificates' name constraints need to be critical.
        Is there any generalizable advice which this case leads to?  The 
narrowest I can think of is roughly "When a CA specifies a name constraint 
in a cross-certificate that is intended to exclude many of the 
certificates legitimately issued by the subject of that cross-certificate, 
that name constraint SHOULD be marked critical".

Tom Gindin

From:   "David A. Cooper" <[email-masked]>
To:     Paul Hoffman <[email-masked]>, 
Cc:     IETF PKIX <[email-masked]>
Date:   04/12/2012 02:52 PM
Subject:        Re: [pkix] Proposed addition to 
draft-ietf-pkix-rfc5280-clarifications about criticality and As 
name/policy constraints
Sent by:        [email-masked]

Paul,

certificates that have been issued at an assurance level acceptable to 
DoD.

Dave

On 04/11/2012 07:34 PM, Paul Hoffman wrote:
> No, not at all. A CA never needs to enforce anything on an RP. A CA 
might want to reduce its liability by constraining CAs under it, and if 
that CA believes that some RPs only trust the CA for some names or 
policies, the CA needs to alert the RP that sub-CAs have more constraints.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix