Subject: RE: 3280bis: name constraints

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 17 Nov 2004 00:25:23 -0000

First I would suggest that this whole discussion of criticality is invalid in the context of name constraints and rfc 3280

1. RFC 3280 requires that the name constraints extension MUST be critical (take a look at end of 3rd paragraph in section 4.2.1.11  Name Constraints)

2. RFC 3280 path validation requires the path validation software to understand and process name constraints.

So, any implementation that does not process name constraints is by definition NOT compliant with RFC 3280.

Further....

I totally agree with David that the current defined name comparison rules are not logical and do not follow the subtree principle (i.e. to allow all descendent entries but not parallel entries. This is also the case for the concept that xyz.com should be limited to the host (i.e. that [email-masked] is a violation of xyz.com. In my mind, [email-masked] is a perfectly valid subtree of xyz.com. The standard is thus not logical in this aspect.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: den 16 november 2004 16:19
To: Terry Hayes
Cc: [email-masked]
Subject: Re: 3280bis: name constraints

Terry,

Even if I agreed with you that name constraints should work as you describe, there would still be a couple of problems.  First, this would be a change from RFC 3280, which is probably outside the scope for changes that we are allowed to make in 3280bis.  Second, this would make 3280bis inconsistent with X.509, which is certainly not something we can do, since 3280bis is a profile of X.509.

X.509 states (among other things):
If excludedSubtrees is present, any certificate issued by the subject CA or subsequent CAs in the certification path that has a subject name within these subtrees is unacceptable.
If the [nameConstraints] extension is present and is flagged critical, a certificate-using implementation must recognize and process all name forms for which there is both a subtree specification (permitted or excluded) in the extension and a corresponding value in the subject field or subjectAltNames extension of any subsequent certificate in the certification path. If an unrecognized name form appears in both a subtree specification and a subsequent certificate, that certificate shall be handled as if an unrecognized critical extension was encountered. If any subject name in the certificate falls within an excluded subtree, the certificate is unacceptable.
X.509 is quite clear that if a certificate includes a name that falls within an excludedSubtree or does not fall within any permittedSubtree, then the certificate is unacceptable not just the name.  In order for a certificate to be acceptable, all names must satisfy name constraints, not just the name(s) that is of interest to the application.  If the nameConstraints extension is critical and the application can not process one or more of the constraints, then it must reject the certification path since it is unable to verify that the name constraints have been satisfied.

In my opinion, the answer to your concern is not to change the semantics of name constraints, but to be careful in your use of name constraints and alternative names.  At the moment, in the U.S. Federal PKI, we only impose name constraints on the directoryName form and I have not seen a compelling reason to impose constraints on other name forms.

If you do feel the need to impose name constraints on some name form for which many applications may not be able to process the constraint, then I would suggest issuing separate certificates for the application(s) that use that name form.  For example, if you have an application that uses X.400 names and you feel the need to impose name constraints on X.400 names, issue subscribers two certificates:  one certificate with an X.400 name for use with the application that uses the X.400 name (presumably this application can process the X.400 name constraints) and a second certificate without an X.400 name.  If a CA imposes a constraint on a particular name form, but no subsequent certificate includes a subject name or subjectAltName of that form, then there is no processing to be done so the application can accept the path despite not being able to process constraints for that name form.

There is another option:  the nameConstraints extension could be marked non-critical.  X.509 states:
If the [nameConstraints] extension is present and is flagged non-critical and a certificate-using implementation does not recognize a name form used in any base component, then that subtree specification may be ignored.
Granted, RFC 3280 states that the nameConstraints extension MUST be critical, but if there were sufficient interest in changing this in 3280bis to state that the extension can be set to either critical or non-critical, I would be willing to support that.

Dave

Terry Hayes wrote:

In my opinion, a requirement such as this is too restrictive, and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it should be free to ignore constraints that apply to that name form.  Notice that to do this, it must recognize and process the name constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with constraints for name forms that they do not recognize, they will be prevented from using certificates that have those name forms added to them for other applications.  This will impede the use of certificates for these new applications, since older clients will not be able to function.

Terry Hayes

David A. Cooper wrote on 11/15/2004, 2:08 PM:

X.509 does have a rule that one must reject a critical extension unless 
you can process all of the fields in the extension. So, for name 
constraints, if a critical nameConstraints extension includes a 
constraint on a name form and that name form appears in the subject 
field or subjectAltName extension of a subsequent certificate, then path 
must be rejected.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 18 Nov 2004 12:01:46 -0500

Stefan Santesson wrote:

While I agree that the rules for name constraints on rfc822Name is not
entirely proper, but I don't see a compelling reason to change them.

RFC 3280 provides three ways to specify name constraints for rfc822Name:

specify a particular mailbox: this one seems to be consistent
with the general rules for specifying name constraints.

A constraint of the form "xyz.com":  This is really indicating a
constraint of "xyz.com" with a minimum of 0 or 1 (it doesn't matter
since "xyz.com" is not itself a valid email address) and a maximum of 1.

A constraint of the form ".xyz.com":  This is really indicating
a constraint of "xyz.com" with a minimum of 2 (must add at least one
subdomain plus a local-part to the specified subtree) and no maximum.

In order to get the "normal" meaning of "xyz.com" one would need to
include two subtree specifications:  "xyz.com" and ".xyz.com".

This seems to have been a way to introduce some flexibility in the
specification of name constraints for rfc822Name without introducing
the added complexity of the minimum and maximum fields.

Since the rules for specifying constraints on rfc822Name have remain
unchanged since RFC 2459, I think it would be best not to change them.

Dave