Subject: Re: Standard for Name Constraints for X500Names

From: Steve Hanna <[email-masked]>
Date: Wed, 04 Sep 2002 17:28:59 -0400

Anne Anderson wrote:
> In RFC3280, I do not find an algorithm or reference for how
> X500Name NameConstraints are compared.  I know that the empty
> string is the root of the X500 name space, but..
> 
> If A is constrained by B,
> - must A include all RDNs in B as its most general RDNs?
> - is there any sub-matching within a given RDN?  e.g.
>    CN="* Anderson" matching "CN="Anne Anderson", or some other
>    syntax for such partial matches?
> 
> Is there a standard for such comparisons?  An X500 ordering-rule
> or something?

X.509 (2000) says in section 8.4.2.2:

   If present, the permittedSubtrees and excludedSubtrees
   components each specify one or more naming subtrees, each
   defined by the name of the root of the subtree and, optionally,
   within that subtree, an area that is bounded by upper and/or
   lower levels. If permittedSubtrees is present, of all the
   certificates issued by the subject CA and subsequent CAs in the
   certification path, only those certificates with subject names
   within these subtrees are acceptable. 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.

So, as you say, "A include all RDNs in B as its most general RDNs".

How are RDNs matched? X.520 has lots of information about that,
but RFC 3280 says you can do something much simpler:

   At a minimum, implementations MUST perform the DN comparison
   rules specified in Section 4.1.2.4.  CAs issuing certificates
   with a restriction of the form directoryName SHOULD NOT rely
   on implementation of the full ISO DN name comparison algorithm.

Neither X.520 nor section 4.1.2.4 of RFC 3280 provide for
wild-card matching within an attribute value, at least not
for any of the attributes normally included in a DN in a
certificate (those mentioned in section 4.1.2.4).

The name matching algorithm defined in section 4.1.2.4 of
RFC 3280 doesn't require any intelligent handling of Unicode
characters. X.520 doesn't do much better. There is an effort
underway to define better handling for such characters. But
at this point, section 4.1.2.4 is the rule for RFC 3280.

I hope that helps!

Steve Hanna