Subject: Re: excluding all names of given type

From: [email-masked]
Date: Mon, 21 Aug 2000 10:02:32 -0400

Tim Polk <[email-masked]> wrote:

>On the other hand, you could consider NULL the implicit root of all
subtrees,
>the correct answer is excludedSubtrees is NULL with a minimum value of 1.
>(We would need to set the minimum to 1 so that NULL itself was not
excluded.)

I don't think that's right.  An empty subject DN in a certificate doesn't
mean that the certificate applies to a principal whose DN is the root of
the DIT, rather that the principal in question has no DN.  This is a
special case, called out explicitly in the PKIX profile.  A certificate
with an empty DN should be permitted regardless of any DN name constraints.
So I don't think this requires that you set the minimum value to 1 - 0
should do just fine.

>CASE: NameConstraints *includedSubtrees* contains a directoryName
>where the RDNSequence is NULL
>
>has the
>
>SEMANTICS:  The Subject field and the directoryName field of the
>SubjectAlternativeName (if it appears at all) may only contain names
>in the subtree NULL for all successive certificates in the path.
>
>The only name in the subtree NULL would be the exact match - the
>NULL value.  That would work, since we require a NULL RDNSequence
>if the Subject is omitted.  As Steve has pointed out, this should only
>occur in an end entity certificate.
>
>This is not particularly straightforward, I know.  We are using the
include
>feature to exclude names!  However, it works *if* you consider the only
>name in the subtree NULL is NULL itself.

Normally when a name is given as the root of a subtree, it means that
members of that subtree are formed by appending RDNs to the root name
(subject to any minimum and maximum path lengths in the subtree constraint,
which don't apply to the PKIX profile).  Thus the subtree rooted at the
empty DN includes all names in the DIT.  So by putting this name in the
permittedSubtrees field you are saying all names are permitted, which
doesn't say anything useful, as it's the default state.

To use either of these mechanisms, some special-casing has to be done by
relying parties, so we need to decide which mechanism we should recommend
and put language into the profile to explicitly support it.  I definitely
favor the use of excludedSubtrees to exclude the entire X.500 DIT, both
because it just seems illogical to use a permitted Subtrees extension to
exclude things, but also because the reason that special-casing is
necessary at all is that we have decided that an empty DN in the subject
field of a certificate has special semantics, so we should strive to
restrict any special casing necesssary to our interpretation of that field,
rather than having to change the semantics of other fields to suit.

John