Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)

From: "Tom Gindin" <[email-masked]>
Date: Mon, 27 Aug 2001 15:16:03 -0400

While your point that case sensitivity is a cause of name constraint
mismatches is valid, why is this not an issue for RFC822 addresses as well?
Suppose an attacker lists your domain as "Sun.COM"?  In section 11.3.2 of
the latest X.509 draft, the subject is finessed by having certificates
match if the subjectAltName contains a component of the same name type as
the one being checked.

          Tom Gindin

Steve Hanna <[email-masked]> on 08/27/2001 09:57:30 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)

Tom Gindin wrote:
> As far as I can tell, the only excludedSubtree with DirectoryName
> which is widely usable and doesn't run into the character code
> problems discussed earlier is one which contains a countryName and
> no other attributes. Thus I would not change the last sentence of
> the paragraph (it's good advice anyway)

I'm glad we agree on that.

> but would add a new sentence to it after the first sentence as
> follows: "This is particularly hard to guarantee when one or more
> of the attributes in the DN specification is encoded as a CHOICE,
> such as DirectoryString." and change the beginning of the next
> sentence to "If the encodings differ" from "If not".

For those following along at home, that would change the text to:

   In addition, name constraints for distinguished names MUST be
   stated identically to the encoding used in the subject field or
   subjectAltName extension. This is particularly hard to guarantee
   when one or more of the attributes in the DN specification is
   encoded as a CHOICE, such as DirectoryString. If the encodings
   differ, then name constraints stated as excludedSubTrees will not
   match and invalid paths will be accepted and name constraints
   expressed as permittedSubtrees will not match and valid paths will
   be rejected.  To avoid acceptance of invalid paths, CAs SHOULD
   state name constraints for distinguished names as
   permittedSubtrees wherever possible.

Why do you want to make this change? It seems to narrow the focus of
this paragraph to only cases of differing encodings. But different
encodings aren't the only cause of name constraint mismatches. Two
UTF8Strings with values "Tom" and "TOM" won't match using the minimum
son-of-2459 rules, which use binary comparison for UTF8String values.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Mon, 27 Aug 2001 15:53:53 -0400

Tom Gindin wrote:
> While your point that case sensitivity is a cause of name
> constraint mismatches is valid, why is this not an issue for RFC822
> addresses as well? Suppose an attacker lists your domain as
> "Sun.COM"?  In section 11.3.2 of the latest X.509 draft, the
> subject is finessed by having certificates match if the
> subjectAltName contains a component of the same name type as
> the one being checked.

RFC 2459 and son-of-2459 both say that rfc822 names are
case-insensitive. So if I issue a CA certificate containing an
excludedSubtree of type rfc822Name and value "sun.com" and the
subject of that certificate issues a certificate with a subject
alternative name of type rfc822Name and value "Sun.COM", a path
consisting of those two certificates is not valid.

Section 11.3.2 of X.509 (4th edition, draft 8) refers to the
certificate match rule, which is used to fetch certificates
from a directory. You can include an AltNameType to say "only
return certificates that contain a subject alternative name of
this type."

When retrieving certificates from a directory, that's probably fine.
You wouldn't want to make the directory server implement support for
matching all sorts of alternative name forms. But a validation
library that encounters an excludedSubtree of type rfc822Name
had better understand how to match names of that type and not allow
a subsequent certificate in the path to contain a name that
matches the excludedSubtree.

The paragraph that you're proposing to change (in the Security
Considerations section of son-of-2459) is concerned solely with
risks caused by inconsistent application of name comparison rules
for distinguished names. son-of-2459 doesn't allow any
inconsistencies in name comparison rules for rfc822Names, so
there's no risk there (except for buggy implementations that don't
meet the spec, which is an entirely different problem).

In my commentary on your proposed change, I was just pointing out
that it's possible to run into inconsistencies in name comparison
rules for distinguished names even if both names use the same
encoding. Two UTF8Strings with values "Tom" and "TOM" will be
considered equivalent by an implementation that supports case-
insensitive comparison of UTF8Strings and not equivalent by an
implementation that just does a binary comparison for attributes
that are not encoded with PrintableString. So changing that
paragraph to focus solely on inconsistencies caused by different
encodings is probably not a good idea.

Am I missing something here?

-Steve