Re: PKIX Cert and CRL profile bugs and queries

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

>>> Dean Povey <povey@dstc.qut.edu.au> 10/01/97 10:41PM >>>

>With regard to DN's, PKIX simply states that you should use X.501 standard 
>attributes.  However, I'd like to see some recommendations/constraints in
here 
>ala Peter Gutmann's X.509 style guide, namely:
>
>Implementations conforming to this profile should not generate Certificates

>and CRLs including DNs which use multivalued SETs of AVAs.  SETs are yucky
to 
>DER encode (you have to sort on tag value from memory), and I would expect 
>that this would make life easier for developers.  Implementations may still

>accept other Certs and CRLs which do have multivalue AVA sets (DER decoding
of 
>SETs is much easier than encoding).

Dean, I would have to respectfully disagree with you on this one.

The overarching principle is with respect to DNs is that they be
_distinguished_, i.e., that they be globally unambiguous.

Unfortunately, it is too late to get all of the mothers and fathers of the
world to agree to name their offspring in such a way as to include the exact
date/time/location of their birth, a message digest of the mother's maiden
name, and a birth certificate number to be used as a tie-breaker within
their given name. And despite Carl Ellison's desire to use public keys as
identifiers rather than names, we aren't yet to the point where we will
implant a microchip in the baby's butt for ease of identification.

That being the case, common names will undoubtedly continue to be all too
common to be unique, and so we have to face the fact that within an
organization, or within some geopolitical locality, there will be
duplicates.  It will therefore be necessary to used some kind of additional
qualifier, such as an employee serial number, or an arbitrary qualifier
assigned by a CA, to prevent ambiguity.

Unlike e-mail addresses, which are assigned by the whim of some
administrator, we cannot reasonably expect people to change their names to
minimize the "yuckiness" faced by a developer, and a multivalued AVA for the
final leaf of the naming tree is the least objectionable way of solving this
problem that we have discovered to date.

Bob



Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com