Re: PKIX Part I - Name Constraints

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

> From: Warwick Ford <wford@verisign.com>
> 
> I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX
> Part I.  
> 
> Regarding RFC822Name, the most common way to convey an e-mail address today
> is as a PKCS#9 e-mail attribute in the subject DN.  Migration to
> subjectAltNames will undoubtedly occcur in time, and the profile correctly
> covers that future.  However, to ensure that the intent of Name Constraints
> is met given current styles of naming, I propose that we additionally state
> that "Restrictions for the rfc822 name form shall also apply to any
> instance of the PKCS#9 E-mail Name attribute type present in a subject DN."

I agree with the proposal.


But that brings up the question of which name representations are "better"
from a design perspective.

My uninformed intuition suggests that name forms like email addresses,
locally-defined (SDSI-type) names, the "persistent IDs" discussed here
a few months back, as well as other AltName forms such as IP
addresses/DNS names/URIs, would be most cleanly represented as
Distinguished Names, with AttributeType OIDs (such as the PKCS#9 email
attribute) defined for each type.  This would:

 1) put all name forms in a common data structure, reducing the need to
    parse separate data structures depending on the name type,

 2) eliminate the "null-DN" problem,

 3) allow directory operations (search & retrieval) based on alternative
    name forms to make use of the existing DN search machinery,

 4) eliminate the need for the above suggestion on consistent email
    name form restrictions, since there would be only one place an
    email name could occur (a DN attribute), and

 5) eliminate the need for changing the GeneralName structure to add
    additional name types (such as SDSI names) to the existing 9 types.
    Alternatively, if all future naming requirements are to be satisfied
    by lumping them into "otherName" and registering OIDs for new
    otherName types, then I don't see why the same effect cannot be
    better achieved by registering the new OIDs as DN attributes instead.


Can someone explain the rationale for preferring the GeneralName
extension over DN attributes, and in particular why new applications
should migrate away from including email addresses in DNs?

For the case where multiple different names are needed for a single
entity, a structure like:

  Names ::= SEQUENCE OF Name

could replace the need for GeneralNames.

In fact, if the "subjectAltName" and "issuerAltName" extensions were
replaced by new versions that used  "SYNTAX Names" instead of
"SYNTAX GeneralNames", then the extension would be needed ONLY in the
case where a subject had 2 or more name forms.  Entities such as
PGP subjects who have only an RFC822 name would not be relegated to
second-class status, using a null DN and the subjectAltName
extension.