John Gillmore, Don Eastlake, Phil Hallem, and others have expressed some
dissatisfaction with the X.509 certificate, centered primarily on the
conventional wisdom regarding the format of the distinguished name. These are
old arguments in the case of X.509 v1, and have been hashed and rehashed in the
PEM discussions over the last five years, and ever more vigorously during the
MOSS discussions.
I am sympathetic tosome of those concerns, but want to point out why most of
these issues can and do go away with the adoption of X.509 v3. Then maybe we
can get on with something more useful.
Dear all,
I think that X.500 addresses have their use but thats mainly
to interact with X.500 addresses. The binding is unsatisfactory for the
following reasons :
1) An X.509 certificate is informaly described as a declaration by
the issuer that the subject posseses a public key
This is actually imprecise, the strongest statement to be made is
that there is an authenticated assertion from the issuer that any
entity which can provide information authenticated by the key
information is the subject.
Well, actually this is a legal/semantic issue, not a technical one. A better
way to say it would be that there is an authenticated assertion from the issuer
that any entity which can provide information authenticated by the public key
in the certificate must be in the possession or of have effective control over
the corresponding private key, whether this was acquired by valid or invalid
means. Fraud, covert or overt compromise, and deliberate sharing by the subject
are all issues that have to be considered. However, this has very little to do
with the name or identity of the subject.
2) There is no mechanism for providing qualifications on the assertion.
This is absolutely true, and one of the crucial failings of X.509 v1. (To be
fair to the "ISO crowd", X.509 was originally intended to be used for strong
authentication to control a user's access to _his_ entries in an X.500
directory, which is the only reason to have a DN in the certificate in the
first place. The PEM community (and others) preempted that usage with a broader
one, and as is often the case when a standard that was developed for one
purpose is used for another, it wasn't quite good enough to do the whole job.)
Both the issuer and subject may have a number of reasons to qualify the binding
between the key and the identity of the user, in particular if a digital
signature is to be used for important transactions that may be legally binding,
such as electronic commerce. In particular, the user knows best what his
comfort level is with respect to the security of this private key and/or the
operating system that may be protecting it. Since there is no affordable
computer security that could be considered even close to perfect, there is a
risk of a compromise that must always be considered. In order to balance the
risk against the cost of adequate protection, there must be some means of
bounding the risk, either by providing some kind of legal notice in the
certificate itself ("Not valid for more than $1000.", or "Not valid without
authorization from an online, real time validation process whose address is
foo."), or through legislative, consumer-protection initiatives. Finite
protection resources and an unbounded risk does not compute.
Other qualifications may include restricting the certificate to a particular
policy, insisting on name subordination or path constraints to limit the
possible scope, etc.
This is part of what X.509v3 is about. There should be provision to link to
the certificate revocation service.
Here, lets stop the thinking that goes "if we put the facility in to
allow online checking of certificates we have moved to an entirely online
scheme". I have an online system and want to take advantage of the
capaboilities that affords. Someone who does not have access to the
network will always be at a disadvantage. Tough!
Yes, agreed. An offline, CRL hot-list is perfectly adequate for most e-mail
usage, as well as for authenticating software and other purposes. But it
certainly isn't good enough to be used for buying and selling stock or other
high value goods, where an up to the second confirmation is required. Of
course, in electronic commerce you may want to know that the customer has money
in his account to cover the transaction, in addition to verifying that the
certificate is still valid, but that is a different issue.
3) The structure of the namespace reflects mailing addresses which are
geographical in nature.
Again this is problematic. People respond to logos rather than ascii
names. The X.509 specification is also centered on a latin alphabet
which is particularly bad. Or to be precise it tries to evade this
problem by leaving it open to implementations.
The principal difficulty with X.400 and X.500 addresses in general
is that they do not provide the strong cognitive associations to an
identity that is required. This is easily demonstrated using the
psychology principle of 7 items +- 2. The brain has limited short
term recall. Distinguished names exceed the buffer length.
A secondary difficulty is that our net persona is effectively our
email address attempts to duplicate that identity leads to dissonance,
the brain must remember two things and correlate them. This introduces
the possibility (probability) of error.
Well, this is based on the conventional thinking of what a DN "ought" to look
like, but in fact there is nothing in either X.509, X.500, PEM, or anywhere
else that compels the use of an X.400-like organizational name, or mailing
address style names, or anything else. We've just made assumptions based on
certain examples.
In particular, an Internet DNS name is a perfectly valid DN -- it satisfies all
of the criteria for a globally unambiguous identifier. Other valid DNs would
include an international telephone number, a DUNS number, etc. Of all of these,
the geopolitical mailing address DN is perhaps the least well suited, because
in most countries there is no formal registration or control over names and
mailing address. It may not be a smart idea, but if George Foreman wants to
name all of his kids "George", and they all live at the same address, then some
other means of qualification will be required to make these names unique, and
this generally won't be obvious.
I would claim that the ONLY reason to retain the use of the DN in X.509 v3 is
for backward compatibility, and more importantly, to provide a backward
reference pointer to a directory entry that _may_ contain other useful
information about the subject.
However, there are still no constraints placed on the format or structure of
the DN (unless you want to be able to interoperate with someone's X.500
directory and you don't control that directory's schema). More to the point, V3
provides an alt-name capability that specifically addresses the possibility of
e-mail address and other "names". These names may or may not be in the form of
a DN, but alternate DNs are also allowed (aliases, for example).
So in version 3, at least, the issue of having to choose between simple,
elegant DNS names like Jueneman(_at_)gte(_dot_)com (or less revealing ones like
gnu(_at_)toad(_dot_)com) vs. the long-winded, complicated X.400-style names
should finally
and permanently be put to bed. If you want to look up a certificate based on
someone's e-mail address, you can do so (assuming you have some kind of
directory). If the banking community wants to look up certificates based on a
bank name or number and an account number, they can do so as well. In fact,
with a little luck and some cooperation from both sides, it might even be
possible to use the same certificate for more than one purpose!
4) In PEM, the certificate is opaque.
Certificates carry vital information, the information which is most
needed to be read by the user. Why then use ASN.1 for this purpose?
While HTTP is headed for binary transport modes in general, certificates
are the IMHO one exception where the movement should be in the opposite
direction.
Unless there is a substantial readership who have both base64
and ASN.1 decoding abilities in the brain and can use both at once
then this is not "the right thing".
This is clearly a red herring.
Even if I had base64 and ASN.1 decoding abilities in my brain, I still can't do
1024 bit arithmetic. A certificate is totally useless, and worse yet,
potentially misleading, unless it has been validated by examining the entire
certificate chain. We are not sending these certificate to model 39 teletype
machines, they are being read and interpreted by a computer. I don't feel
strongly about the base 64 issue -- if they can't read binary let them eat cake
is my general feeling, but even though ASN.1 is hard to read and even harder to
write correctly, it does provide a significant advantage in being able to
migrate to new fields, options, and even character sets.
(There is a rumor that Visa and Microsoft would like to delete the ASN.1 and
DER encoding from their certificate format -- they may even want to
deliberately come up with an incompatible certificate format to preclude anyone
else from using them. To my way of thinking this is incredibly short-sighted,
and should be strenouusly resisted by the user community. It will be difficult
enough to set up one reasonably good CA infrastructure, but to require multiple
and incompatible infrastructures would be to repeat the format wars of 33 vs.
45, Beta vs. VHS. A tremendous waste of time and effort.)
None of the above does not mean that X.509v3 is critically important
to the internet community. The lawyers can discuss semantics. We should
reserve syntax for ourselves. Thus we might define a certificate :-
[snip]
It has taken a lot of thought and effort to evolve X.509 v3 to the point where
it is today. I would certainly NOT like to have to go through all of those
thought processes all over again. By providing the ability to have attribute
extensions in the certificate, and the ability to mark some of those attributes
as critical, X.509 v3 has provided all of the facilities that could reasonably
be required, and creating a new fomat would be a Bad Thing, IMHO.
Instead, we ought to focus on selecting some reasonable subset of the options
available, reality-check them against known or proposed applications, and move
on. I've argued with Warwick Ford regarding some of the attributes in the PDAM,
or more accurately some that are not in the PDAM that I believe should be, but
that is a separate discussion. The point is that v3 can accomodate every
requirement that has been seriously proposed to date, and abandoning it or
substantially revising it would probably be the death knell of a hoped-for
global public key infrastructure.
Comments???
Phill Hallam-Baker.
You're welcome.
Bob
--------------------------------
"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>
Staff Scientist, Wireless and Secure Systems Laboratory
GTE Laboratories, 40 Sylvan Road, Waltham, MA 02254
Waltham office: Voice: 1-617-466-2820, FAX: 1-617-466-2603
Telecommuting: Voice: 1-508-264-0485, FAX: 1-508-264-4165