Re: [IETF-PKIX] Question about SubjectAltNames

[Mike Smith <mfsmith@xxxxxxxxxxxxx>]

Maybe I'm missing something with the X.500 compatibility issue and X.509 certifcates.  I thought that, with version 3, X.500 is just one schema tht the X.509v3 certificate processing systems should be "backward compatible" with.

Michael

>>> Andreas Berger <aberger@DARMSTADT.GMD.DE> 12/03/97 04:24AM >>>
Bob Jueneman wrote:
>
> >Phil,
> >
> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> >require "Distinguished Names" to be "Directory Names"?

To my opinion, the X.509 certificates were intended to authenticate
users for access of the X.500 directory system. Certificates must
contain an acceptable name for the application in question. Therefore,
distinguished names for the X.500 are the appropriate namespace for this
application. For other applications there may well be other namespaces
acceptable.

> 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> two people with the same common name could possibly be confused?
>
> Answering that question "yes" will force name subordination to be applied
> everywhere, even in cases where the obvious ways of doing it (geopolitical
> name qualification, down to the street address level) are either
> unacceptable (e.g., due to privacy concerns), or not workable (because the
> state or locality entities have not bought into the system, or because the
> natural domain of a CA (e.g., an ISP) is not confined by regional
> boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> component, in order to avoid changing someone's common name while still
> maintaining global unambiguity.
>
> Answering the question "no" seems (at least on the surface) to significantly
> weaken the legal status of a digital signature for purposes of commerce,
> unless some other name mechanism (e.g., a unique account number) is included
> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> system was somewhat cavalier about the assignment of names -- in fact it
> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> mark, whether unique or not.  But more recently, the issue of who owns
> domain names has become increasingly contentious. Whereas at one time Apple
> the computer company and Apple the music company had little to do with each
> other, today the separation is much less clean cut.  Even today, if there
> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> legal confusion is likely to result. But who can say what will happen
> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> have an e-mail account with CompuServe. or some other domestic ISP).

We don't need a global unique name for users in a certificate in the way
you described it. We have to be very careful not to mix the attributes
of a person (Name, Address...) with the requirement of the technical
"name". That is a problem that X.500 created with typed RDNs.

For electronic commerce applications (or legally binding transactions)
we need a name that is acceptable to the other party. This acceptance
depends largely on the trustworthiness of the issuer of the certificate
and defined measures to get hold of the physical person in case a
dispute arises. Therefore, it should be enough to identify an end entity
relativly unique to the issuer. And this identification may well be made
by a number or some other means. People may have several identities in
this respect - and nobody will care unless the resolution of these
pseudonymity is required.

> 2. Does the use of X.509 envision at least the possibility of a globally
> interconnected directory to be used for certificate retrieval and perhaps
> CRL retrieval?  If so, doesn't require the assumption that the DN in the
> certificate is one to one with respect to the DIT?  If we don't start out
> deploying certificates with that assumption in mind, will it not prove to be
> impossible to migrate to such a scheme later on?

If an application accepts simple DNs (such as CN=High Speed Modem) it
has to have some knowledge on how to retrieve such names from a
directory (if a directory is employed at all). I would not want to make
very piece of equiment in a corporate network "worldwide unique". And
yes, this certificate would have no meaning outside the corporate
network, but is this really necessary?

For the (relativly simple) operations needed for retrieving security
attribute from directories (i.e. find a certificate for a person,
retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
FINGER or something similar). We do not need a very complex "directory
service" for these operations.

But I agree that we should develop some guidelines for creating DNs. Or
at least write down what is already there (see the NT4 LDAP server,
verisign certificates, X.400 mailaddresses an so on). Perhaps we can
converge on an accepted practice. We should stress the point that these
DNs are automatically resolvable to machine/service names (on the
internet or other) so that applications (e.g. eMail clients or payment
systems) can access a direcory service to retrieve additional
information desired.

> 3.  And speaking of schemes, what schema is to be assumed for acceptable
> components of a DN in a certificate, if we are to ever move toward a common
> directory?  At present, I am not aware of any definition of what constitutes
> allowable, deprecated, or not allowable attribute types within a PKIX DN,
> yet if we ever expect that the current islands of LDAP usage will ever merge
> into archipelagoes, and finally continents, some agreement on acceptable
> schemas will have to be enforced.  Should we just leave it up to the public
> CAs like VeriSign to say what kinds of DN attributes they will support, and
> let all of the directory providers eat dirt?  Or vice versa?
I doubt that we will get a common directory for each and every entity on
the planet. Companies will severly restrict access to corporate
directories and even I personally would not want to publish a massive
amount of information globally.

> I believe that the working consensus is still the same that it was in the
> PEM days -- that we should strive to be interoperable with X.500
> directories, but should not presume their existence to be either necessary
> or sufficient.
Agreed. But what I would like to see is the seperation of the DN as a
name for an entry from identity information needed in certificates. The
DN for an entry is just a name (like an URL or bettern URN) that - in my
opionion - may be changed as often. What matters is the content of the
entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
to the application, it should put these into the certificate as well -
but not as part of the DN.

Andreas