Subject: Processing rules for non-critical extensions (Re: Rationales for CA clearance constraints)

From: "David A. Cooper" <[email-masked]>
Date: Mon, 03 Nov 2008 15:04:02 -0500

Kemp, David P. wrote:
> Dave C,
>
> I start with the assumption that an extension marked critical must be
> processed identically to an extension marked non-critical if it is
> processed at all, and that processing requirements that refer to
> criticality are therefore incorrect.  Name constraints has two such
> statements (here is one) ...
>   
David,

You may choose to start with this assumption, but as I noted in my 
previous email, this is contrary to X.509, which specifically allows 
(requires) clients to ignore some unknown elements in a non-critical 
extension but not in a critical extension:

  If unknown elements appear within the extension, and the extension
  is not marked critical, those unknown elements shall be ignored
  according to the rules of extensibility documented in 12.2.2 in
  ITU-T Rec. X.519 | ISO/IEC 9594-5.

I do not understand your logic below with respect to the nameConstraints 
extension.  You proposed the following text:
  
   A certificate-using system MUST reject the certificate if it
   encounters a critical extension that it cannot process.  If a
   certificate-using system encounters a non-critical extension,
   it MUST either process the extension as if it were marked
   critical or ignore the extension entirely.

As I interpret this, a client that encounters a non-critical 
nameConstraints extension that includes a name form that it cannot 
process MUST ignore the extension entirely since it cannot process the 
extension as if it were marked critical.   Below you seem to be 
proposing, for the nameConstraints extension, that clients should be 
required to process a non-critical nameConstraints extension as if it 
were critical.  This would mean that a client that can process name 
constraints for some name forms would be required to reject a 
certificate if it encountered a non-critical nameConstraints extension 
that included a name form that it could not process even though a client 
that did not recognize the OID for the nameConstraints extension at all 
would be permitted to accept the certificate.  Not only does this seem 
to be contrary to the idea behind allowing an extension to be marked 
non-critical, it directly contradicts X.509.  Unlike RFC 5280, X.509 
specifically allows for the nameConstraints extension to be marked 
non-critical and it includes the following text:

   Conformant implementations are not required to recognize
   all possible name forms. If the extension is flagged critical
   and a certificate-using implementation does not recognize
   a name form used in any base component, the certificate
   shall be handled as if an unrecognized critical extension
   had been encountered. If the extension is flagged
   non-critical and a certificate-using implementation does
   not recognize a name form used in any base component,
   then that subtree may be ignored.

>    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.
>
> ... and conforming CAs MUST mark name constraints as critical.  If an
> application finds a non-critical name constraints and a path contains
> SANs using dNSname form and the application cannot process that form,
> then it is better to reject the certificate than to constrain subject DN
> while allowing dNSname to pass unconstrained.  Under what circumstances
> would it ever be a good thing to process some name constraints while
> silently ignoring others?

Under what circumstances would it be a good thing to ignore all name 
constraints simply because some cannot be processed?  Remember that we 
are only considering the case in which the CA has chosen to mark the 
extension non-critical.  The fact that RFC 5280 states that conforming 
CAs must always mark the extension as critical is irrelevant as is any 
discussion of whether it ever makes sense for a CA to mark the extension 
non-critical.  If the CA has chosen to mark the extension non-critical, 
then it is indicating that it does not wish to require clients to reject 
the certificate simply because they that cannot process the extension.  
Thus a client that can process nameConstraints on some name forms but 
that encounters a non-critical nameConstraints extension with a name 
form that it cannot process must do one of the following: (1) reject the 
certificate since it cannot process every element of the extension; (2) 
ignore the extension entirely; or (3) process the extension to the 
degree possible and ignore the presence of the name forms that it cannot 
process.  Option (3) is the one specified by X.509.  Isn't it also the 
option that most closely aligns with the CA's intention in marking the 
extension non-critical?

> To answer your last question below, "no".  But the same behavior
> (processing what it can and ignoring the rest) should be required where
> appropriate (as with AIA and EKU) if the extension is marked critical.
> Name constraints should be fixed so that the appropriate behavior
> (constrain all present subject names or reject) is required even if the
> constraint is non-critical.
>   

Isn't this essentially saying that the profile should override the 
express wishes of the issuing CA since you believe the CA must have been 
mistaken in choosing the mark the extension non-critical?

Dave

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 3 Nov 2008 17:03:09 -0500

CAs and application developers look to X.509 to understand the meaning
of an extension.  If a hypothetical discussion resulted in consensus to
change X.509's treatment of name constraints to not depend on
criticality, then a [non-PKIX] CA's decision to mark name constraints
non-critical would be based on the behavior described in the new X.509.

My "assumption" is of course contrary to X.509, otherwise there would be
no basis for a proposed change.  From 5280:

This does not say that *any* unsupported constraint would reject the
certificate, only an unsupported constraint on any subject name form
used in the path.  An application that *uses* a name form (for example,
dNSName) must be able to understand that name form, and arguably should
be required to also support constraints on that name form (where
constraints can be defined).  For name forms that appear in the cert
path but are ignored by the application, constraints are trivially
"processed" and satisfied without any explicit action.

So the argument to the X.500 WG would be that for a critical or
non-critical nameConstraints, the "best" course of action would be
similar to (1) below: reject the certificate since it cannot process
every element of the extension that (a) applies to any subject of a
subsequent certificate that (b) is used by the application.
Why would any CA believe it worthwhile to specify constraints that
applications are permitted to selectively enforce?

Am I planning to propose such a change?  No.  But if a discussion of
criticality happened to occur, I would advocate the position of equal
treatment.

Dave