Re: [IETF-PKIX] Question about SubjectAltNames

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Andreas,

I think your proposal of guidelines and best practices is a good one and
probably about as far as we could go in this area. There are 2 different
sets of requirements, both of which need to be accommodated. In one case
we want the names to be simple and easily retreivable and in the other
case we need to address both PKI-specific repositories and repositories
that are shared directories with other applications.

There are some guidelines that clearly fit into both environments, such
as recommending that only "standard" attribute types be used in names
and possibly recommending which ones (increasing the likelihood that
they can be retrieved), use of numeric values to disambiguate (although
3-4 years ago people would have thrown up their arms in opposition to
that I think that has changed along with the realization that these
don't normally get displayed to end-users anyway) ... just a few early
thoughts.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:boeyen@entrust.com       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security


>----------
>From:  Andreas Berger[SMTP:aberger@DARMSTADT.GMD.DE]
>Sent:  December 3, 1997 6:24 AM
>To:    IETF-PKIX@LISTS.TANDEM.COM
>Subject:       Re: [IETF-PKIX] Question about SubjectAltNames
>
>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
>--
> Andreas Berger, GMD - German National         eMail:
>Andreas.Berger@gmd.de
> Research Center for Information Technology,
> Institute for Telecooperation Technology      Tel:   +49-6151-869-715
> Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   +49-6151-869-704
>