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

From: "Tom Gindin" <[email-masked]>
Date: Fri, 24 Aug 2001 20:32:23 -0400

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

          Tom Gindin

Steve Hanna <[email-masked]> on 08/23/2001 10:20:04 AM

To:   Tom Gindin <[email-masked]>
cc:   Peter Sylvester <[email-masked]>, [email-masked]
Subject:  Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)

Tom Gindin wrote:
> On a more constructive note, however, any attribute which can only
> be encoded in PrintableString or NumericString (or Object ID) can
> safely be used in excludedSubtrees.  The most useful of these is
> probably Country.

Right. So I can safely use excludedSubtrees with directoryNames as long
as the only attributes in the excluded DN are countryName, dnQualifier,
and serialNumber. But I suspect that most DNs that people would want to
exclude would contain organizationName and the like.

So I still think that using excludedSubtrees with directoryNames is
generally a bad idea. The Security Considerations section of
new-part1-08 basically says this, so I don't think any changes to the
draft are required.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Mon, 27 Aug 2001 09:57:30 -0400

Tom Gindin wrote:
> 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