Brad,
I would agree that a mapping from Jueneman(_at_)gte(_dot_)com to
organisation=Internet, domainNameComponent=com,
domainNameComponent=gte, commonName=Jueneman would
solve the problem of how to transform a basically X.400 DN name
construct into an Internet address.
What I am arguing is that that is NOT the problem we are trying
to solve, or at least not the only problem. As I said in my 5 Oct.
message (repeated below for your convenience), we are trying
to solve at least two, and maybe three, separate problems
with one Distinguished Name construct, and that won't work.
One of the problems can certainly be solved, but not two,
much less three.
The issue is not simply how to use an X.509 certificate and
the DN contained therein as a convenient substitute for an
X.500 directory and to provide a means of looking up someone's
e-mail address, although that would certainly be nice.
The real problem is that we have burdened the DN with additional
semantic baggage, such as the affiliation between the user and
his employer when it comes to responsibility for a digitally signed
message. Even if we were only to discuss authentication of an
individual for the purposes of sending an encrypted message,
I submit that it may very well matter whether an individual
is still employed by a given company, especially if I am sending
him proprietary data.
I understand that there are many applications and users for which
these concerns are not terribly relevant. For them, your form of
DN to Internet address mapping would be fine. But if I want to
understand the various implications (social, organizational, legal,
etc.) associated with a digital signature, I need to know more
information, and I believe that the X.509 certificate was and is
intended to provide that information. If not, then we have a
very major disconnect as to the very purpose of PEM.
Remember, even though PEM is strongly oriented towards electronic
mail, one of its considerable strengths is that it was intended to be
independent of the media or virtual network used to carry the
message. The user is not even required to HAVE an e-mail
address -- PEM works just fine over sneaker net.
Bob
------------------------------
Date: Tue, 05 Oct 93 12:43:33 EDT
From: jueneman%wotan(_at_)gte(_dot_)com
Subject: X.509 DN semantics
To: hoyt_kesterson(_at_)ppd-smtp(_dot_)az05(_dot_)bull(_dot_)com
Cc: pem-dev(_at_)tis(_dot_)com, Stephen D Crocker <crocker(_at_)tis(_dot_)com>
Reply-To: Jueneman(_at_)gte(_dot_)com
Priority:
Security:
Hoyt,
I think that the DN problem within X.509 is even worse than
Steve Crocker's comments imply. He has pointed out some
syntactic anomalies that are irritating, but fixable, I presume.
But there are some much deeper semantic problems that are
inherent in the use of the Distinguished Name construct, at
least is so far as it is used within PEM.
Admittedly, X.509 was intended to authenticate users to
a Directory, and PEM and others have appropriated the
certificate for its purposes. In so doing, I believe that we
have "stood on the shoulders of giants..." and perhaps
crushed them into the ground thereby.
I perceive the problem to be the lack of a clear definition of
the semantic content of a DN. Maybe it was clear in
the X.500 (and X.400) context, but I claim that it is no
longer clear when we graft on the PEM/signature implications.
Consider which (if any) of these statements is true:
1. The Distinguished Name of a user has NO semantic
content, but is only intended to ensure that a globally
unique reference is provided to that user. All of the
other attributes associated with that user should be
looked up in the Directory (if and when we had one).
Presumably this would include primary residence,
vacation addresses, organizational affiliations, various
roles, e-mail addresses, etc. In this context, the
Certification Authority may be acting as a surrogate for
the eventual X.500 directory service provider, and
may either assign or help the user "discover" his
globally unique name. Hopefully, that name would be a
lifelong constant, so that correspondence could be
forwarded to that user regardless of changes of residence,
employment, marriage, etc. Under this scenario the USER
would be responsible for the accuracy of the information.
The user's directory entry would stay relatively constant,
but such fields as Organization might change as the user
changes jobs or at least roles. How global uniqueness
would guaranteed without violating everyone's right to
privacy (e.g., by recording the user's name, date and place
of birth, mother's name, etc.) is left as an exercise for the
reader. If it weren't for the difficulty in searching for that
user, a 128-bit hash of the information on user's birth
certificate would be an ideal DN - presumably it would
be globally unique forever, and the user could easily
"discover" it for himself.
2. The user's DN DOES contain valid semantic information,
such as his organizational affiliation, residential address,
and perhaps various roles. These various roles are
necessary to appropriately qualify attributes which are
related to those particular roles, notably including which
certificate/public key/algorithm is to be used for a
particular purpose. Particularly in the case of an
"affiliated" user, i.e., someone whose DN includes an
organization, the affiliation is presumed to be vouched for by
the CA, who can reasonably be assumed to exercise some
degree authority over that user, such as acting as his
employer, and therefore shares at least some degree of
responsibility and/or liability for that user's actions.
(This begins to get a little sticky in the case of "OU=guest"
or "OU=customer", especially since the degree to which
the affiliation exists or is enforced is not defined within the
DN, nor in the X.509 certificate, but only in the contract or
agreement between the PCA and the CA, and in the PCA's
policy!
3. The user's DN does contain valid semantic information
but it is the user's MAILING address, and not necessarily
either his corporate affiliation or his place of residence.
In particular, if you want to send the sheriff to that location
in order to enforce a digitally signed document, this
information may not be sufficient. Under this interpretation,
a DN could reasonably be mapped to an Internet email
address, including one or more email accounts at the user's
previous places of employment, schools, and/or various
utilities such as CompuServe or Prodigy. In the case of
a residential address, a PO box number would be
considered legitimate, even one at Mailboxes, Inc.
The user's common name may or may not be the name
that is registered with the various civil authorities, as
in the case of a Persona certificate.
Although it has taken several megabytes of wrangling over a
number of these issues, I finally understand that the difficulty
has been due to the fact that we were using one construct to
mean at least three different things. Not only does this lead to a lot of
emotional arguments when the two discussants have two
different points of reference in mind, but it is clearly terrible
from an architectural standpoint. (Maybe others saw this problem
earlier, and I apologize for arguing so vociferously with those
who may have held an equally valid but different viewpoint
from my own in the past.)
I started thinking about this problem when I was trying to
find a simple way to get back to the user's CA in order to
obtain either the latest CRL or a confirmation of the validity
of the user's signature on a document. It suddenly occurred to
me that although I knew the certificate issuer's DN, I did not
necessarily know how to find that CA -- either his email address
or his real address -- except by asking the PCA.
As usual, I started to think about a hack. "Maybe we should put
the CA's CRL responder email address in the commonName
field of the CA's (issuerName) DN?"
C=US,O="GTE", OU="GTE Labs",
CN="CRL Responder <CRL_RESPONDER(_at_)GTE(_dot_)COM>"
Then I thought, well, why not put the user's DN in the
certificate also, to avoid having to guess what the PEM user's
email address might be:
C=US,O="GTE", OU="GTE Labs",
CN="Robert R. Jueneman <Jueneman(_at_)GTE(_dot_)COM>"
or C=US,O="GTE", OU="GTE Labs",
CN="Robert R. Jueneman <rrj0(_at_)bunny(_dot_)gte(_dot_)com>"
or C=US,O="GTE", OU="GTE Labs",
CN="Robert R. Jueneman <jueneman(_at_)wotan(_dot_)gte(_dot_)com>"
or even C=US, O="GTE", OU=GTE Labs",
CN="Robert R. Jueneman <xxxxxx(_at_)CompuServe(_dot_)COM>"
Although all of those are valid, they may have entirely different
implications with regard to routing and distribution, and which
certificate to use for what purpose.
Maybe, I thought to myself, in order to be more politically
correct and avoid such an ugly hack, we should use
the appropriate telecommunications atttibute set. But
what to my wondering eyes should appear but the fact
that an Internet address is not one of the defined attributes
in that class, at least according to X.520 (1993)!
Undaunted, we'll make one up, and we'll use a multivalued
RDN in order to encode it, viz:
C=US,O="GTE", OU="GTE Labs",
{CN="Robert R. Jueneman" +
title="Mgr., Secure Systems" +
certificatePurpose="Encryption only" +
internetAddress="<Jueneman(_at_)gte(_dot_)com>" +
description="My generic Internet mail address and general
purpose encryption certificate, for mail which is subject to
being forwarded to and read by my secretary and/or others
on my staff at my sole discretion."
But all this is getting worse and worse from the standpoint
of eventually searching an X.500 directory, and loading the
DN with all this information it still doesn't solve the basic
architectural problem of using one field for two or three
different and potentially incompatible purposes.
Therefore, at the risk of making a radical suggestion, maybe
we should think about making one of three relatively
unpalatable choices:
1. Have PEM depart from X.509 by allowing the addition of
optional fields such as certificatePurpose, internetAddress,
organizational affiliation, organizational street or mailing
address, telephone number, FAX number, roleName,
description, etc., as might be found on a business card.
This would explicitly recognize the fact that PEM is
intended to be independent of but (eventually) compatible
with X.500, and that it should work in the absense of an
X.500 directory. The version 0 PEM certificates would be
compatible with version 0 (1988) of X.509, but forthcoming
versions of the PEM certificates would not necessarily
remain in lockstep. with X.509.
2. Enhance X.509 (1993) by explicitly adding these fields
as optional entities outside of the DN, in order to address
the fact that a number of non-Directory functions now
plan to use this overall certificate structure, and in order
to encourage the eventual migration to a common
directory infrastructure. The current PEM would presumably
ignore any fields that it didn't understand, but all of these
fields would be signed by the CA. (??)
3. Do nothing that might impact anyone's code now that we
have several hundred users, but muddle along until we have
hundreds of thousands of users, hoping for a miracle
solution that will make these problems go away.
Frankly, I suspect that these problems are not unique to PEM,
or even digital signatures in general. I would be willing to bet
that when the NADF starts looking at the issues involved
in authenticating a user's access to individual fields within
a directory, they will begin to see the need for all of the
different roles, email addresses, postal addresses, etc., that
we are beginning to see.
My inclination at this time would be to vote for option 2.
Comments?
Bob