Re: X.509 certificate and its subject name field

["Anil R. Gangolli" <gangolli@xxxxxxxxxxxxxxxxxx>]

I can no longer resist adding my own comments:

(A) Peter says that it is common practice in https servers to use
a hash of the (entire) certificate as a key for mapping to a user,
but I'm not sure which ones he's referring to.  The ones I know about
(Netscape's) do not do this.

In Netscape servers for example:
2.x servers use the combination of the DER-encoded issuer name + subject
name.

3.x servers allow a per-issuer mapping to an LDAP entry to be
site-supplied but the default implementation is based on the subject
name.
They tend to use the LDAP attribute UID for disambiguation (which
represents a user id not a universally unique id). 

A hash of the cert was avoided specifically because it is not stable
across renewals.

Anyway, that's not my main point.  The main points are in the
next item.


(B) There seem to be a few separate requirements that have been
voiced in this discussion.  It might help to consider them
separately; I've attached my own comments to each one I've
identified.

Distinctiveness (the need for a component that can disambiguate subjects
whose names otherwise would be the same).  In distinguished names this
is
generally addressed by adding an additional AVA to the terminal RDN.  It
is
unfortunate that some implementations of LDAP and a lot of cert
software doesn't support this properly.  I would hope that this
requirement eventually will get addressed in popular implementations.

Persistence (stability over time).  Many organizations do want
persistent
identifiers for their ACLs.  They wish to be able to separate the
decision about when to change a name (which may or may not
reflect some organizational structure) from when they change
memberships in authorization groups. This can be addressed
by using a component of the name, that is specifically for this use.
This portion may be the same as is used for Distinctiveness.

Global scope (stability across namers/naming contexts).  There is a
problem currently faced by sites that wish to accept certificates from
multiple CAs that serve the Internet public at large.  Namely to
actually be sure of the scope in which the same subject name is
guaranteed to
represent the same entity, one needs to consider the entire path of
names up to the root or trusted CA along the certificate chain.  Under
the reasonable assumption that no trustworthy root CA will allow two
distinct end-entities (even under subordinate CAs) to share the same
subject name, only the root and end entity names are needed to
identify namespace and name, respectively.  Still, because many things
aren't geared to deal with this kind of contextual baggage, it tends
to be ignored in many implementations, and using it in conjunction with
say LDAP or X.500 is not easy.  I believe some people voiced the desire
to have a component that would be the same for a subject regardless of
CA.
Here the problem is what to use as such an identifier, and any ensuing
privacy implications, but not necessarily where to put it in the
cert.  Any CA-specific name will not satisfy this requirement
and using the subjectUniqueID field doesn't help.

Presentability (to a human user).  The representation of a name in a
certificate is already in a form that needs to be decoded and
presented to users, and choices on the presentation (or exclusion from
the presentation) already can and must be made in doing so.  I don't
see this requirement as necessitating the use of the subjectUniqueID
field
to hold any identifier that is meant to satisfy the previous
requirements.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
gangolli@StructuredArts.com
http://www.StructuredArts.com