John, I was away for a week, and I am trying to catch up on my mail.
You responded to a note of mine in a manner that was occasionally
rather cryptic, and I am not sure that I understood all of your points.
Since some time has gone by I'll repeat the original exchange.
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 ?)
I don't understand. I believe that this statement is pretty close to the
original
intent of X.500. If the DN is used to establish identity, then presumably
an individual would only need one DN throughout his lifetime. Maybe that
would work in a full X.500 environment, but it won't work in the context of
the current X.509 certificates unless there are multiple certificates per
DN. And then we don't have sufficient information in the certificate to
discover which one to use.
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 ?
I believe that I do understand. But once we begin to incorporate various roles,
affiliation, etc., then the DNs become much more complex. I'm not sure what the
tradeoff is between the search process in X.500, given a particular DN, vs.
the need to be as specific as possible in the X.509 certificate, especially if
it is used for PEM without a X.500 service being available.
I would make another point as well -- one that I mentioned to Hoyt Kesterson.
The X.509 certificate is the only thing that is signed by the CA, and the CA
is the only organization that I (have to) trust. In particular, I tend to reject
the notion put forward by many of the PTTs that "of course you can trust the
directory -- it is operated by the Government, and we are here to help you!"
To the extent that the CA needs to be able to say something about a user,
and to sign that, then it has to go into the DN, and I think that leads to
overspecifying the DN with what such just be informational attributes.
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.
On the contrary, there has been a considerable amount of discussion as to
how to derive the mailbox name from the DN, and/or vice versa. And that
only applies to the electronic mail address. Surely if I want to know whether
I can trust someone, I might like to know how I can get in touch with him
in person, if necessary to compell performance or seek redress. Even
in the X.400 case, there is no binding between the user's ORName and
his certificate or "identity", since it is not vouched for by the CA (not
contained in the 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.)
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 ...)
John, you've said that severel times, but maybe I'm not catching the nuances.
What, exactly, do you consider an "entity" to be? In particular, do you
consider it valid to distinguish between "entities" based on the role that
entity may be playing at the moment? Or are you trying to equate an entity
to one physical person, cradle to grave?
So ... you have an addressing problem, well lets look for some other way of
solving it, shall we ?
That's one way of looking at it, but by "address" I would include at least all
of
the information I would normally find on a business card, including his
telephone
number, physical location, etc. -- not just his X.400 or SMTP address.
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" ?
In general, I want the information to go into the certificate so the CA can
sign it.
In the case of the CA, the PCA should sign it. A header field woldn't be
cryptographically authenticated.
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 ...
But I may very well have different certificates and different e-mail addresses
that I would want to use for different purposes, e.g., to solve the
secretary/manager problem.
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...
The information is not at all obnoxious, and I would assume that these
attributes
would normally be available in an X.500 directory. Presumably these attributes
would be used to help the searcher decide which certificate he should use,
assuming that he did a browse, rather than a read. The issue is not whether
the information is useful, but whther it should go in the DN or somewhere
else, preferably in an signed-attribute section of the X.509 certificate.
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 ....
A, I don't agree that it would "break" the Key Management System of PEM
to extend the format of X.509 to include some optional fields. And B, I don't
think that the issue is trivial.
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 ?
Again, I would prefer the term "enhance", rather than "break", but it is not
just
for PEM but for virtually all digital signature systems. My hope is that we can
arrive at a common infrastructure that can not only support PEM, but EDI, and
X.400, and even access control to the X.500 directory system itself.
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.
This problem was what got me to think about this issue, but it is not the only
problem that needs to be solved.
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.
Why do you keep saying "break", when I am talking about compatible, long-term
enhancements? Are you afraid you might have to write another line of code or
two? The X.509 (93) standards haven't even been approved yet. Is PEM going
insist on staying with the '88 version for all eternity?
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 ...
I'm not hung up on trying to solve the name to e-mail address look up problem
in the certificate, although it might be a convenient place to put it until a
more
powerful directory service becomes generally available and integrated with
whatever
mail system (SMTP, X.400, etc.) eventually becomes ubiquitous.
I'm just trying to point out that there are many attributes that might normally
be
contained in the directory that would be nice to have available in a PEM-only
context, and that regardless of the context it would be nice to allow the CA to
sign
those attributes (such as employer's name and postal address) without requiring
everything to go into the DN.
Since the X.509 certificate is up for review and the opportunity has been
presented to
"fix" it, I was recommending that it be extended to include additional,
optional attributes
that would not be required to be part of the DN itself. My believe is that
would make the
directory search process easier, since the DN would not be cluttered with
information that
is not essential to unambiguously identifying an "entity"
Comments?
You asked for them :-)
Bob
John
Sorry for the length of this, but without responding point by point I couldn't
address
your comments properly.
Bob