Jim, you confused me by addressing your message to spock (Steve Dusse) while
putting Jeff (Thompson?) in your salutation. In any case, I'd like to make
sure that I understand what everyone is proposing, because it impacts some
things I am trying to do in X.500.
Based on community feedback we proposed
to augment the PEM specifications to allow 3 additional identifiers:
distinguished name/selector
email address/selector
arbitrary string selector
I'm not quite sure that I understand the intent, perhaps because we may have a
different concept of what is (or can be) in a distinguished name.
At the risk of flogging a dead horse, there has been a considerable amount of
confusion as to what constitutes a "decent" distinguished name, both in an
X.500 directory proper, and in the DN field of an X.509 certificate.
To review the bidding, there is nothing in X.509 or in the entire X.500 series
of documents that requires that the DN in an X.509 certificate be in any
particular form, e.g., the geopolitical name form that is often assumed in this
context. In fact, there is no requirement that the DN in the X.509 certificate
even exist, or that it bear any particular resemblence to a DN that might be
found elsewhere in the directory. Nothing in X.500 requires that the X.509 DN
even be checked.
In essence, therefore, the DN field in the original X.509 is a bit of a
misnomer. What it really is is simply a collection of strongly typed ASN.1
attributes that contain a variety of values. It is PRESUMED that the collection
of those attributes is globally unique, but this is not enforced by X.500
although it is certainly a good idea.
The DN is not restricted to being made up of the so-called "useful attributes"
(which really aren't terribly useful, as it turns out) that are suggested in
X.521. The Internet society or any other organization that has a unique
organization ID can create and publish attributes of any type whatsoever.
At one point the IETF was going to decide upon a recommended set of attributes
to be supported, but this never happened.
Of course if the pessimists are right and X.500 never becomes viable as a way
of looking up e-mail addresses, cryptographic certificates, etc., then none of
this matters very much, but even in that event we could (and should, I believe)
use the X.509 format in order to maximize the possibility of interoperating
with other standards. Depending on your taste for strongly typed objects, you
could create an X.509 DN that consists of one or more arbitrary strings, such
as Description, and simply enter the information any way that you wish -- by
postal address, e-mail address, global telephone number, etc. Because I would
like to avoid having to parse such a melange of untyped ASCII, I would prefer
to use ASN.1 encoded attributes, and if necessary would suggest inventing new
attributes that will do whatever is needed without reusing other attributes and
introducing semantic ambiguity, but this is a matter of architectural taste and
style -- essentially a religious issue.
In any case, and I want to stress this, a DN of
rfc822Address=Jueneman(_at_)gte(_dot_)com
is a perfectly valid and potentially even useful X.509 DN. It isn't necessary
to specify the country or anything thing else, because of the way that Internet
mailboxes are assigned. It may not satisfy some of my own application criteria
as a DN that is suitable for electronic commerce, but then again no one said it
had to, so long as other more comprehensive DN as still allowed.
Even within an X.500 directory context, an rfc822 name is a perfectly valid DN,
or perhaps an alias of another DN. Given the user's e-mail address, you could
look up his postal address, telephone number, crypto certificates, etc. Vice
versa, given the user's name and at least a portion of his postal address, you
could look up his e-mail address, etc.
In all these cases we are using one form or another of a DN as a "handle" to
look up a much longer attribute, the user's certificate. But what if the user
doesn't want to publish his certificate in the directory? He could still
exchange his certificate privately, perhaps encrypted within a message sent to
his correspondent if the correspondent's public key is known, or even
hand-carried between co-conspirators. This would avoid some of the potentially
sensitive information in the certificate, including the user's name and or
e-mail address.
In that case we still need a convenient way of uniquely identifying the user's
certificate, just so we know we got the right one. PEM uniquely identified a
certificate by referring to the certificate issuer and a unique serial number,
but even this amount of information might violate someone's privacy.
CA=Anarchists, Inc., serial=001 might be too revealing, as might CA=Central
Intelligence Agency, serial=007. Your correspondent needs to know who your CA
is so he can decide whether or not to trust you, but third parties do not need
to know.
Some have suggested that we use the public key itself, or at least a digest of
it as a emans of identifying and/or retrieving a certificate. Unfortunately,
there may be a number of cases where the same public key may be used in
different certificates, for example to provide different levels of
authorization, or simply to change hats or roles without having to manage
multiple keys.
My suggestion, therefore, is that we identify the certificate by taking a
message digest of the entire certificate itself. Although uniqueness cannot be
absolutely guaranteed, the probability of a duplicate is negligibly small. If a
user sends you his certificate, you can file it locally and retrieve it by
means of the digest alone.
(This doesn't mean that there isn't a place for the certificate issuer plus
serial number, e.g, for CRL purposes, where looking up the certificate by means
of its message digest might be awkward. But if you don't have the certificate
you don't have any need for the CRL either, so this information can be included
within the certificate without any further compromise.)
I would claim that this mechanism would effectively address the requirements
that you enumerated:
From an implementation point of view, it is possible to view these
identifiers as "handles" that indicate the required public key, i.e., as
an implementor you need not parse the individual values but rather you
can use the pair as single unit. Thus, conceptually, you need only
support two identifiers: the key itself and a "handle" for it.
There are several reasons why identifiers are useful.
o Public key's are large. Some folks will not want to distribute them.
Let me observe that the PGP community is in touch with this issue
since they typically only distribute key footprints.
o There is community of users who would prefer not to publish their
public keys. Rather, they will prefer to use psuedonyms that are only
useful to the recipients.
o If you remove textual information from the identifiers, users will not
be able to get any useful information out of message. In particular,
if a message fails to verify there will be no help for the user.
(Well, perhaps that's a bit strongly stated. One could argue that the
message content itself may be helpful as well as the envelope of the
message.)
Jim
--------------------------------
Robert R. Jueneman
Mgr., Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820 (rolls over to cellular and/or my house
if no answer -- have patience