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:
Consider which (if any) of these statements is true:
False dilemma.
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.
Used to establish identity. (see the period ?)
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!
Part of the identity may be an organizational afilitiation. Still just an
identity.
If I get an ID of C=US;SP=Massachusetts;L=Cambridge;SA=Mass Ave.;CN=Mack the
Knife
Does that mean I "represent" US ? How about Massachusetts ? Does it depend on
the issuer ? What if the issuer has a Disclaimer for my actions as part of
their policy ?
These questions have been answered before. What part don't you understand ?
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.
This is obviously not true and never has been. Note that DN is an X.500
construct
borrowed by X.400 (88) (you do have these, yes ?) and is incorporated as a
component into
an X.400 ORName. Note that an ORName consists of an ORAddress and a DN.
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.)
Only a few have been so insistent that PEM DNs are overloaded. The DN in
a PEM Certificate (any Certificate for that matter) is used only to uniquely
identify
an entity within a name space. (another period back there ...)
So ... you have an addressing problem, well lets look for some other way of
solving it, shall we ?
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.
Ah ha, a specific problem. You do have a possible solution there ...
Is it possible that CAs might be "well known entities" ? Not good enough ?
Ok, what about proposing a new header field ? Say something like
"X-Senders-CA-RFC-822-Mail-Address" ?
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?"
You are right, this is a hack.
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.
A good reason not to do this ...
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)!
A refinement on a bad idea... Give up the bad idea and start over.
Trying to sugar coat it doesn't help.
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."
Even you found this one too obnoxious...
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.
In other words, lets break the Key Management System component of PEM
to solve a rather trivial addressing problem ....
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. (??)
In other words, lets break X..500 for PEMs sake ?
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.
These are all false dilemmas. Lets state the problem and take innovative
approaches which do not harm the current set of functional units within PEM.
Lets see if I can state one of the problems for you:
Recipient receives a message from originator for the first time ever.
Recipient would like to validate originator's certificate.
Recipient needs CRL from originator's CA.
Recipient doesn't know how to contact originator's CA. (doesn't have quipu ...)
Originator's CA or CA CRL "server" is reachable via email.
Recipient could ask for CRL via email.
(consider case there CRL is available via anonymous FTP instead ...,
using your suggestion, we should have things like CN="FTP to foo.com
as anonymous, login as guest, cd to wherever and get CRL.out" ...
yuch.)
Therefore it would be nice if email address necessary to get CRL were
present in originator's message.
Does any of this suggest that the ONLY way to achieve a solution is to
muck about with DNs, Certificates, and break X.500, PEM Key Management, etc ?
I think not.
Consider one reason why X.400 included DNs as part of ORNames. In an
environment
where the recipients ORAddress changed frequently (perhaps weekly) the DN is
the more
reliable way to send mail. The MTA resolves the address, the originator
specified the
recipients using only the DN. Note that there is no addressing in the DN or the
recipient's certificate ...
Comments?
You asked for them :-)
Bob
John