Subject: Re: Name Constraints Processing

From: Steve Hanna <[email-masked]>
Date: Wed, 11 Jun 2003 11:43:01 -0400

I apologize for taking so long to respond to your questions.
I agree that there are a few potential ambiguities in the
discussion of name constraints in RFC 3280. Let me address
your comments directly.

Terry Hayes wrote:
> RFC 3280 seems to be unclear as to the handling of certain
> unusual cases that may be encountered while processing the
> Name Constraints extension.  While these cases are not likely
> to be seen in real deployments, the certificate processing
> code needs to respond to them correctly, both to avoid incorrect
> behavior of the application and to avoid introducing security
> holes.  I'll describe each situation below along with my best
> guess at the correct handling.  I'd appreciate comments.
> 
> 1. Name constraints containing an empty Directory Name sequence
> 
> What is the correct processing of a name constraint extension
> that contains an empty sequence in the directoryName choice?
> 
> The empty sequence value for a directory name is used in other
> places in this RFC to indicate that no name is present. However,
> here I think it means that the constraint matches all possible
> names. Therefore, in the permitted subtrees field, this allows
> certificates to be issued to any directory name (equivalent to
> no constraint), and in the excluded subtrees field, prevents
> certificates from being issued that contain any directory name.

You're right. The X.500 specs are pretty clear about this.
The name of the root of the DIT is a zero length sequence.
So if you include such an empty DN in permitted subtrees,
it allows and DN (subject of course to any other name constraints
defined in the excluded subtrees or in other certs in the chain).
And if you include such an empty DN in excluded subtrees,
it prohibits any subsequent certificates from containing any
distinguished name as a subject or subject alt name.

RFC 3280 should probably be more clear about this.

> 2.  Name constraints with other empty values
> 
> What is the meaning of an empty (zero length) value for the
> RFC822 name, DNS name, Uniform Resource Identifier and IP
> Address forms of a name constraint extension?
> 
> An empty value in these fields might be interpreted as matching
> all names of the corresponding type.  Again, this is not very
> useful in the permitted subtrees area, but might be use to
> disallow all names of that type by including the empty value
> in the excluded subtrees field.
>
> For RFC822, DNS and URI types, the empty value seems equivalent
> to "." (just the dot).  Do current implementations interpret
> that string as matching all names?  For IP addresses, there is
> already a mechanism to match all names (an all-zero "subnet"
> mask value) so I would be tempted to declare that an empty value
> is invalid (see the following question).

A strict reading of section 4.2.1.11 of RFC 3280 seems to
indicate that an empty value for rfc822Name indicates all
mailboxes on the root domain (since the root domain has
a null string for its name). A value of "." would indicate
all mailboxes in all domains except the root domain.

A strict reading with respect to an empty DNS name would
say that it indicates all DNS names. And a strict reading
with respect to an empty URI name would say that it indicates
only URIs whose host part is empty.

And RFC 3280 says clearly that a name constraint whose syntax
is iPAddress MUST have a length of 8 or 32 bytes (for IPv4
and IPv6 addresses). So a zero length IP address name constraint
is definitely invalid.

I agree with you that it would be useful to have an easy
way to indicate "all names" for each name type. This would
make it easier to exclude all rfc822Names in subsequent certs,
for instance. In the case of Distinguished Names and IP
addresses, this is already provided for in the current
spec (although it could be clearer for DNs). I don't think
it would be a problem if a subsequent draft of RFC 3280
changed (or clarified) the meaning of an empty name constraint
of type rfc822Name, dNSName, and uniformResourceIdentifier
to say that this value should match all names of that name
type. Why wouldn't this be a problem? Because I suspect that
no certs have been issued with such name constraints.

It would also be nice to have a way for a CA to say "no names
except in these explicitly listed types". I don't think there's
any way to do that with name constraints as currently defined.
If enough people think this is important, perhaps a new flag
for this could be added.

> 3. Name constraints with badly formed name values
> 
> What is the correct handling of a name constraint that contains
> invalid data?  Should the constraint value ever match?  What if
> the incorrect value is in the excluded subtrees field?

If any field in a certificate is badly formed or incorrectly
encoded and it's not possible to unambiguously determine
the intent of the certificate issuer, then I'd say the
relying party should discard the certificate.

> Since it is the CAs responsibility to put the correct values
> into the name constraints that are needed to enforce the
> issuance policy, I think it is reasonable for applications
> to ignore name constraints values that don't make sense.

Maybe. But maybe the CA is using a later version of the spec
that defines some new meaning for this previously malformed
value. Or maybe the CA has a private understanding with relying
parties within its domain about what this value means. And
the relying party that doesn't understand the value just
hasn't been upgraded yet.

I think it's pretty dangerous to ignore values in critical
extensions if you don't understand them.

Thanks,

Steve