Subject: Name Constraints Processing

From: [email-masked] (Terry Hayes)
Date: Thu, 22 May 2003 10:02:23 -0700

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.

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).

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?

It's possible for a value in a name constraint
to be invalid for that type of name. For example, an RFC822
name might have two '@' characters (such as
"terry@[email-masked]").
Also, the matching rule for the IP
address type cannot be applied if the value has an incorrect length.

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.

Thanks in advance for any comments or clarification you can provide.

Terry Hayes

[email-masked]