Thanks, Jim. That helps to clarify your position a lot.
If I can boil it down to a few words (in order to test my understanding), you
seem to be saying the following:
1. The deployment of a ubiquitous public key infrastructure cum certification
authorities has been found to be fraught with a number of problems, ranging
from right-to-use issues and questions of legal liability to simply the inertia
fo setting up a complex system and the absence of an effective national or
international X.500 directory to date. In the meantime, the direct trust model
is needed at the top, in order to select whose PCA policy you accept, and may
also be of benefit in jump-starting the use of encryption and digital
signatures while we are sorting out the process problems. In this sense you
seem to be picking the best features of both PEM and PGP (CA-issued
certificates and/or recipient-issued name/key binding.)
So far I agree with you.
2. You differentiate between the use of a distinguished name "as specified by
X.500", vs. the use of "e-mail addresses and/or arbitrary strings to identify
the owners of public keys". In particular, you say that "Hence, there is a need
to support name forms which do not conform to the expected usage of
distinguished names."
Although I understand how we got to this point, and I have probably contributed
more than my share towards the confusion on this issue by trying to support
electronic commerce applications with robust signature tools, the simple fact
of the matter is that X.500 DOES NOT make any substantitive recommendations as
to what form a distinguished name can or should take. In particular, the DN in
the certificate does not have to map directly, or even indirectly, to any
particular DN in an actual X.500 directory, even if the X.509 certificate
itself is carried as part of the payload of an directory entry. Although there
may be pros and cons with respect to its suitability to a particular
application, an RFC822 e-mail name is a perfectly good distinguished name to
put in a certificate, and it may very well be a useful DN to use within the
directory itself, at least as an alias. Other constructs are also perfectly
feasible for use as a DN, including an individual's worldwide DDD telephone
number, his DUNS number, his name and social security number, etc. -- so long
as there is some kind of a explicit or implicit naming authority that is
operating in such a manner as to ensure the global uniqueness of the resulting
name. It is truly unfortunate that we got hung up on this issue of "expected
usage," without asking more directly who was doing the expecting. It turns out
that no one was -- we have met the enemy and he is us.
3. You do support the use of X.509 certificates for forward/backward
compatibility (depending on your point of view, I suppose.) However, because
you rejected the use of strongly typed names (which is all that a DN is), you
have created several other forms of identifiers that can be used to identify a
user's public key and bind his identity to that key. This seems to be Jeff's
primary concern -- not necessarily that the existing certificates won't work,
but that there will be a proliferation of additional forms that existing
implementations will have to support, thereby slowing down the whole deployment
process.
I guess I have to agree with Jeff (and Steve Dusse). Wouldn't it have been much
simpler, and much less divisive, to have merely allowed any user to be his own
CA, and therefore issue his own certificates to any user he trusts? He can
certainly do that within his own domain of trust -- in fact it would be an
excellent way to anchor the root of even the classical PEM/IPRA tree. An
argument might be raised -- well, what would happen if that user certifies
other users? Could such a presumably low-integrity certificate lead to
confusion? Yes, it could, but only if a user's cache of trusted certificates
was seriously mismanaged. Otherwise, someone else's certificate would not be in
the chain of CAs signed by the PCA, and would be rejected, if that's what the
user wants to have happen. However, if the user who signed another user's
certificate happened to be the boss of both of us, or the director of security
form my company, maybe I should honor that certificate even if it isn't a part
of the global CA hierarchy. (For a nunber of reasons, we have considered
setting up a CA for experimental purposes that would be deliberately
disconnected from any PCA and/or the IPRA hierarchy, so that we can play with
these concepts without exposing us to quite as much potential liability if a
certificate is misused.)
4. Because a user may have more than one key pair, some means of uniquely
identifying which key pair to use is required. But if you hadn't effectively
thrown out the use of conventional X.509 certificates, you could have used the
same common mechanism for each case, i.e, the issuer and serial numnber, even
when the user is his own issuer. Even without the version 3 format, you could
have chosen to create a certificate with an e-mail address in the DN, and/or
any other private form that you wished to use. (Once you start exporting those
private forms you may have a problem, but I am assuming that you are using
these for our own local address book, and not exporting them. You are not
precluding from making up your own unique X.500 attributes and naming them
anything you wish, but other users and their agents may have trouble in
understanding those attributes/private names.)
Then I would suggest that we all look at the v3 version of the
X.509 certificate and see whether it solves the problem that Jim
was trying to address. I suspect and hope that it will.
If this is the case, I would hope that we could begin a healing
process that would eventually result in a harmonization of PEM
without MIME, PEM with MIME, AOCE, andsome of the various other
encryption/signature implementations (maybe even PGP?) that are
currently on the table, each with their various strengths and
faults.
While the new X.509 certificate may in fact solve the same problem, I
would be very much against delaying these documents or the technology
since both are forward compatible with this work when it is generally
accepted and available.
Keep in mind, the PEM/MIME proposal includes complete support for
certificates (as does the available implementation). A user can begin
now with email addresses (a concept understood and appreciated much more
readily by many more people than certificates) and easily migrate to
certificates when the need arise. Note, the available implementation
already includes the ability for a user to assign themselves a
public/private key pair and then to "insert" the public key in a
certificate later. Or, of course, a user could choose to start with a
certificate and migrate "back" to a public/private key pair.
Looking at the same set of facts, I come to a different conclusion. I have no
problem with your going ahead with the distribution and use of the current TIS
implementation of PEM/MIME. Perhaps the marketplace will endorse it by
acclamation, and then almost anyone would be able to predict it's swift
standardization. Being able to experiment with these various mechanisms may
also be helpful in trying to uderstand problems of scalability.
But I have a lot of difficultly with your inventing new mechanisms to solve
problems that the old mechanisms were perfectly capable of solving, if it means
that many groups will have to modify or abondon the infrastructure support
tools that are having to be created.
In summary, I am not opposed to going forward with the integration of PEM and
MIME per se on the standards track. I'm not an expert in MIME, and I am quite
willing to follow your lead in this area (although I am somewhat concerned
about the wisdom of trying to too doo much all at one time). However, I am
opposed to the introduction of new key identifiers within the standards track,
and frankly with the rejection of the certificate approach that your approach
tends to imply. I think that it will end up setting back the whole effort
significantly if that view is adopted.
I would therefore prefer that we begin the process of updating both the
existing PEM spec and the PEM/MIME spec to take advantgae of the v3 certificate
format, which would make what you are trying to do even easier and add a lot of
other capabilities as well. But what you are trying to do can also be done with
the version 1 format, so I would vote NO on any effort to standardize on the
key selector approach as it presently exists.
I haven't intended to put words in your mouth, so if I have misunderstood or
misrepresented what you are saying, please correct me.
Regards,
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
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