Subject: 3280bis: name constraints

From: Stephen Henson <[email-masked]>
Date: Mon, 15 Nov 2004 21:33:51 +0000

IMHO some clarification of the nameConstraints extension should be 
included in RFC3280bis.

I can recall there being a number of threads discussing the meaning of 
name constraints for various types including the interpretation of the 
rfc822Name and dNSName fields. At the time various people had come to 
different conclusions based on the existing text.

I've not seen a description of how directoryName types are handled or a 
discussion on this.

IIRC X509 includes a note that if an unhandled constraint type is 
encountered the certificate should be rejected: should RFC3280bis 
include this too?

What about the minimum and maximum fields: should an implementation 
reject a certificate where these are present?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 15 Nov 2004 17:08:06 -0500

Steve,

I already have a note that the processing of dNSName in name constraints 
needs to be clarified.  In particular, it needs to be made clear that 
"f.example.com" falls within the subtree "example.com", but 
"fexample.com" does not.

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.  The same applies if the minimum or maximum field is 
included and the relying party can not process those fields.  I can add 
text in 3280bis that states this.

I was not aware of any confusion over the meaning of name constraints 
imposed on rfc822Name or directoryName.  Could you provide more 
information about what needs to be clarified?

Dave

Stephen Henson wrote:

> I've not seen a description of how directoryName types are handled or 
> a discussion on this.
>

---

From: Stephen Henson <[email-masked]>
Date: Mon, 15 Nov 2004 23:33:42 +0000

> text in 3280bis that states this.

OK.

> information about what needs to be clarified?

With rfc822Name it was mentioned that the comparision should be to 
compare the RHS against the constraint. The discussion was whether a 
constraint of, for example, [email-masked] would *only* match 
[email-masked] or whether [email-masked] was allowed as well. I 
can't recall if any consensus was reached over this: I'll see if I can 
find the reference.

As far as directoryName is concerned I've not seen a description or a 
reference to the algorithm used for this type of constraint. Some 
private communications with some vendors suggested that this wasn't 
obvious and also produced the worrying comment that "everyone does this 
differently".

Steve.

---

From: "Terry Hayes" <[email-masked]>
Date: Mon, 15 Nov 2004 15:45:25 -0800

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:
> must be rejected.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 10:19:18 -0500

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:

Terry Hayes

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 09:51:07 -0500

Stephen Henson wrote:

David A. Cooper
wrote:

I was not aware of any confusion over the
meaning of name constraints imposed on rfc822Name or directoryName.
Could you provide more information about what needs to be clarified?

Here is the current text for name constraints on rfc822Name:

A name constraint for Internet mail addresses MAY specify a
particular mailbox, all addresses at a particular host, or all
mailboxes in a domain.  To indicate a particular mailbox, the
constraint is the complete mail address.  For example, "[email-masked]"
indicates the root mailbox on the host "xyz.com".  To indicate all
Internet mail addresses on a particular host, the constraint is
specified as the host name.  For example, the constraint "xyz.com" is
satisfied by any mail address at the host "xyz.com".  To specify any
address within a domain, the constraint is specified with a leading
period (as with URIs).  For example, ".xyz.com" indicates all the
Internet mail addresses in the domain "xyz.com", but not Internet mail
addresses on the host "xyz.com".

As I read this, one can specify three types of constraints:

a specific email address

all email addresses on a particular host

all email address on all hosts whose DNS names are hierarchically
subordinate to the specified name

There is no option to specify a set of email addresses on a particular
host that fit a certain pattern.  So, "[email-masked]" would not
match "[email-masked]" since RFC 3280 states that
"[email-masked]" is specifying a particular mailbox, not a set of
mailboxes.  In my opinion this is the correct behavior.  Name
constraints are designed to specify constraints in terms of subtrees.
Logically, "[email-masked]" is not hierarchically subordinate to
"[email-masked]", the two are siblings.

As far as
directoryName is concerned I've not seen a description or a reference
to the algorithm used for this type of constraint. Some private
communications with some vendors suggested that this wasn't obvious and
also produced the worrying comment that "everyone does this
differently".

I have never heard this.  It seems to me that the rules are fairly
simple.  A DN consists of a SEQUENCE of RDN.  A subtree specification
for name constraints on DNs consists of a SEQUENCE of RDN.  If the
subtree specification is a sequence of n RDNs, then a DN
matches if and only if the DN consists of a sequence of at least n
RDNs and the first n RDNs in the DN match the the RDNs in the
subtree specification in order.  The rules for comparing RDNs are the
same as are used to compare issuer and subject names when verifying
name chaining.

So, are these vendors who are unclear on how to process name
constraints on directoryNames also unclear on how to compare issuer and
subject names, or is the confusion limited to name constraints?

Dave

---

From: Stephen Henson <[email-masked]>
Date: Tue, 16 Nov 2004 17:20:54 +0000

David A. Cooper wrote:

>> constraint of, for example, [email-masked] 
>> <mailto:[email-masked]> would *only* match [email-masked] 
>> <mailto:[email-masked]> or whether [email-masked] 
>> <mailto:[email-masked]> was allowed as well. I can't recall if 
>> any consensus was reached over this: I'll see if I can find the 
>> reference. 
> 
>     constraint is the complete mail address.  For example,
>     "[email-masked]" <mailto:[email-masked]> indicates the root mailbox on
>     the host "xyz.com".  To indicate all Internet mail addresses on a
>     particular host, the constraint is specified as the host name.  For
>     example, the constraint "xyz.com" is satisfied by any mail address
>     at the host "xyz.com".  To specify any address within a domain, the
>     constraint is specified with a leading period (as with URIs).  For
>     example, ".xyz.com" indicates all the Internet mail addresses in the
>     domain "xyz.com", but not Internet mail addresses on the host "xyz.com".
> 
>    1. a specific email address
>    2. all email addresses on a particular host
>    3. all email address on all hosts whose DNS names are hierarchically
> host that fit a certain pattern.  So, "[email-masked]" 
> <mailto:[email-masked]> would not match "[email-masked]" 
> <mailto:[email-masked]> since RFC 3280 states that 
> "[email-masked]" <mailto:[email-masked]> is specifying a 
> particular mailbox, not a set of mailboxes.  In my opinion this is the 
> correct behavior.  Name constraints are designed to specify constraints 
> in terms of subtrees.  Logically, "[email-masked]" 
> <mailto:[email-masked]> is not hierarchically subordinate to 
> "[email-masked]" <mailto:[email-masked]>, the two are siblings.
> 

Yes that's how I'd interpreted it. In more explicit terms: perform a RHS
match unless the constraint is of the form user@hostname where only an
exact match will satisfy it.

There were suggestions that some had interpreted it in a different way.
At least one thread discussing this is at:

http://www.imc.org/ietf-pkix/old-archive-02/msg01718.html

>> obvious and also produced the worrying comment that "everyone does 
>> this differently".
> 
> subtree specification is a sequence of /n/ RDNs, then a DN matches if 
> and only if the DN consists of a sequence of at least /n/ RDNs and the 
> first /n/ RDNs in the DN match the the RDNs in the subtree specification 
> in order.  The rules for comparing RDNs are the same as are used to 
> compare issuer and subject names when verifying name chaining.
> 

If we could include a sentence or two explicitly stating that it would
avoid any possibly confusion.

> So, are these vendors who are unclear on how to process name constraints 
> on directoryNames also unclear on how to compare issuer and subject 
> names, or is the confusion limited to name constraints?
> 

It was only name constraints. One area was concerning an RDN consisting
of more than one AttributeTypeAndValue. If RDNs in name constraints
follow the issuer and subject name comparison rules then that resolves
that case.

Steve.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 13:28:49 -0500

See comments in-line

Dr Stephen Henson wrote:

> David A. Cooper wrote:
>
>>   Stephen Henson wrote:
>>
>>> David A. Cooper wrote:
>>>
>>>> I was not aware of any confusion over the meaning of name 
>>>> constraints imposed on rfc822Name or directoryName.  Could you 
>>>> provide more information about what needs to be clarified?
>>>
>>>
>>>
>>> [email-masked] or whether [email-masked] was allowed as 
>>> well. I can't recall if any consensus was reached over this: I'll 
>>> see if I can find the reference. 
>>
>>
>>     "[email-masked]" indicates the root mailbox on
>> There is no option to specify a set of email addresses on a 
>> particular host that fit a certain pattern.  So, 
>> "[email-masked]" would not match "[email-masked]" since RFC 
>> 3280 states that "[email-masked]" is specifying a particular 
>> mailbox, not a set of mailboxes.  In my opinion this is the correct 
>> behavior.  Name constraints are designed to specify constraints in 
>> terms of subtrees.  Logically, "[email-masked]" is not 
>> hierarchically subordinate to "[email-masked]", the two are siblings.
>>
>
> Yes that's how I'd interpreted it. In more explicit terms: perform a 
> RHS match unless the constraint is of the form user@hostname where 
> only an exact match will satisfy it. 

Actually, this is not the case.  RFC 3280 states that constraints of the 
form "xyz.com" are matched only by email addresses on the host xyz.com.  
So, if the constraint were "xyz.com", one would perform a RHS match on 
"@xyz.com".  One could perform a RHS match for constraints of the form 
".xyz.com".

> There were suggestions that some had interpreted it in a different 
> way. At least one thread discussing this is at:
>

I saw that there was at least one response that completely 
misinterpreted the meaning of various constraints on rfc822Names.  I get 
the feeling, though, that this wsa not a case of someone misinterpreting 
the text but rather someone who did not read the text.  There are no 
changes we can make in 3280bis to address that problem.

Dave

---

From: Stephen Henson <[email-masked]>
Date: Tue, 16 Nov 2004 18:51:03 +0000

> "@xyz.com".  One could perform a RHS match for constraints of the form 

Yes, now I've re-read it I'd agree with that.

Steve.

---

From: "Terry Hayes" <[email-masked]>
Date: Mon, 15 Nov 2004 15:45:25 -0800

Terry Hayes

---

From: Stephen Henson <[email-masked]>
Date: Mon, 15 Nov 2004 23:33:42 +0000

OK.

Steve.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 13:28:49 -0500

See comments in-line

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 15 Nov 2004 17:08:06 -0500

Steve,

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 09:51:07 -0500

Stephen Henson wrote:

David A. Cooper
wrote:

a specific email address

As far as

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 16 Nov 2004 10:19:18 -0500

Terry,

Dave

Terry Hayes wrote:

Terry Hayes

---

From: Tom Gindin <[email-masked]>
Date: Wed, 17 Nov 2004 23:36:49 -0500

David:

      X.509 doesn't give any support to handling the comparison for
excluded subtrees differently than the one for permitted, even though the
natural intent of excluded subtrees for DN's is probably closer to "if all
the attribute/value pairs in the constraint exactly match ones in the
subject, exclude it" - somebody who puts in an excluded subtree for "C=US,
O=Enron" doesn't really want "C=US, ST=TX, O=Enron" to pass.
      On Terry's point from Monday, we might be best off declaring that any
name constraints extension containing a constraint for otherName,
ediPartyName, x400Address (where we give no guidance) or registeredID
SHOULD or at least MAY be non-critical.  Although Permanent Identifier name
constraints do make sense (it makes perfectly good sense to use the
assigner field as a constraint), to declare that an unrecognized name
constraint should make a non-critical SubjectAltName form unacceptable is
likely to deter the use of such forms.  The same applies to registeredID,
even though many implementors know the OID leading substring match.

            Tom Gindin

                      "David A. Cooper"                                                    
                      <david.cooper@nis        To:       Stephen Henson                    
                      t.gov>                    <[email-masked]>        
                      Sent by:                 cc:       [email-masked]                 
                      owner-ietf-pkix@m        Subject:  Re: 3280bis: name constraints     
                      ail.imc.org                                                          

                      11/16/2004 09:51                                                     
                      AM                                                                   

Stephen Henson wrote:
      David A. Cooper wrote:

      With rfc822Name it was mentioned that the comparision should be to
      compare the RHS against the constraint. The discussion was whether a
      constraint of, for example, [email-masked] would *only* match
      [email-masked] or whether [email-masked] was allowed as well.
      I can't recall if any consensus was reached over this: I'll see if I
      can find the reference.
Here is the current text for name constraints on rfc822Name:
      A name constraint for Internet mail addresses MAY specify a
      particular mailbox, all addresses at a particular host, or all
      mailboxes in a domain.  To indicate a particular mailbox, the
      constraint is the complete mail address.  For example, "[email-masked]"
      indicates the root mailbox on the host "xyz.com".  To indicate all
      Internet mail addresses on a particular host, the constraint is
      specified as the host name.  For example, the constraint "xyz.com" is
      satisfied by any mail address at the host "xyz.com".  To specify any
      address within a domain, the constraint is specified with a leading
      period (as with URIs).  For example, ".xyz.com" indicates all the
      Internet mail addresses in the domain "xyz.com", but not Internet
      mail addresses on the host "xyz.com".
As I read this, one can specify three types of constraints:
   1. a specific email address
   2. all email addresses on a particular host
   3. all email address on all hosts whose DNS names are hierarchically
      subordinate to the specified name
There is no option to specify a set of email addresses on a particular host
that fit a certain pattern.  So, "[email-masked]" would not match
"[email-masked]" since RFC 3280 states that "[email-masked]" is
specifying a particular mailbox, not a set of mailboxes.  In my opinion
this is the correct behavior.  Name constraints are designed to specify
constraints in terms of subtrees.  Logically, "[email-masked]" is not
hierarchically subordinate to "[email-masked]", the two are siblings.

      As far as directoryName is concerned I've not seen a description or a
      reference to the algorithm used for this type of constraint. Some
      private communications with some vendors suggested that this wasn't
      obvious and also produced the worrying comment that "everyone does
      this differently".
I have never heard this.  It seems to me that the rules are fairly simple.
A DN consists of a SEQUENCE of RDN.  A subtree specification for name
constraints on DNs consists of a SEQUENCE of RDN.  If the subtree
specification is a sequence of n RDNs, then a DN matches if and only if the
DN consists of a sequence of at least n RDNs and the first n RDNs in the DN
match the the RDNs in the subtree specification in order.  The rules for
comparing RDNs are the same as are used to compare issuer and subject names
when verifying name chaining.

So, are these vendors who are unclear on how to process name constraints on
directoryNames also unclear on how to compare issuer and subject names, or
is the confusion limited to name constraints?

Dave