Steve,
Many of us would like to use an infrastructure based on DNS names.
This would solve several problems, e.g. availability of a name server
(the DNS exists and is deployed) or linkage between names and mail address
(the mail address being part of the certified name). However it is often
maintain that we really need X.500 names "for security reasons".
Suppose that for an evolution of PEM we would use RFC-822 like
names:
"Free from name" < code-name @ domain-name >
for users or maybe simply:
"Free from name" < domain-name >
for entities which are not directly users.
Could we maintain the same level of security as provided by RFC
1424? Classically, two objections are made: that one needs to
provide a "rooted certification hierarchy", and that the DNS names
are not sufficiently descriptive.
Implementing a "rooted hierarchy" is often deemed a necessity for
scaling the system to millions of users. The alternative is to use a
meshed topology, with many "point to point" relations: it can
certainly work in limited environment, but one could argue that it
would become too complex on a very large Internet. I will note debate this
point here, but will merely examine the feasibility of performing
RFC-1424 like certificate validations with a DNS based infrastructure.
The PEM rooted hierarchy requires three different objects, TLCAs, PCAs
and "organizational" CAs. TLCAs are supposedly trusted by everybody
because their key is "well known"; they are allowed to sign the
certificates of PCAs. PCAs are recognized as such because their
names - or more precisely the least significant component of their
names - contains the assertion that they are a PCA, and because a
trusted TLCA agreed to sign a certificate bearing this name. PCAs
can sign the certificates of "organizational" CAs. Organizational CA
can only sign the certificates of "hierarchically inferior" entities:
the INRIA CA, can only certify INRIA users or INRIA units' CAs.
This is easy to check because the X.500 "distinguished names" of
the inferiors is built by appending "name parts" at the end of the
superior's name.
Implementing a similar hierarchy and similar checks with a DNS
based infrastructure would be trivial. There is obviously no
problem for the TLCA or the PCA, as there is no particular
constraint on their names. On could imagine that the PCA would
have a name of the form:
"Very high security PCA" <pca.security.org>
The hierarchical relations between organizational CAs and users or
lower level CAs is also easy to check. The dependancy between
<impcomp.com> and <unit.impcomp.com> or <u227(_at_)impcomp(_dot_)com>
is different in syntax from the X.500 dependancy between
<O=Important Company, L=City, C=XX> and <CN=Joe User,
O=Important Company, L=City, C=XX> or <OU=Minor Unit,
O=Important Company, L=City, C=XX>. The same validation
algorithms can easily be applied. If the same model of trust is
used, there is no reason to consider that using one type of
hierarchy (DNS) is in any way less secure than using the other one
(X.500).
The other classic objection is that a name like
<u227(_at_)unit(_dot_)impcomp(_dot_)com>, even completed by a free form name
like "Joe User" is way less "descriptive" than the X.500 equivalent
of <CN=Joe User, OU=Minor Unit, O=Important Company, L=City,
C=XX>. This may be a serious problem when receiving mail from a
third party for the first time: wrongly assuming the qualifications
of a partner may have dangerous implications. On the other hand,
we may have a very different picture if instead of looking only at
the name, we look at the whole certification chain:
Originator: "Joe User" <u227(_at_)unit(_dot_)impcomp(_dot_)com>
Certified by: "Minor Unit" <unit.impcomp.com>
Certified by: "Important Company, City, XX" <impcomp.com>
Certified by: "Very high security PCA" <pca.security.org>
In this chain, every certification authority certified both the
domain name and the free form name. The PCA for example
certified both that <impcomp.com> possessed the public key
indicated in the certificate and that it was entitled to use the
name "Important Company, City, XX". Careful evaluation of the
"free form names" at the time of certification would thus lead to
the same level of expressiveness as usage of X.500 distinguished
names, while certifying the mail address at the same time!
If we accept these arguments, we may want to change the syntax
of PEM certificates accordingly. In fact, there are two options, i.e.
"hacking the X.509 syntax" and "removing all traces of ASN.1". The
first option has been explored by Rhys. It would lead to using a
mix of "DNS" and "Standard" attributes in the distinguished names;
it has the advantage of reusing the existing code and the
inconvenient of not making that code any simpler. Having a
competely textual certificate is certainly possible. Using the simplistic
PGP syntax may not be sufficient. To provide RFC-1424 like features,
including support for revocation lists, the certificates should
contain:
name: free form name + dns name.
key: method + information.
validity: date notation.
issuer: free form name + dns name.
number: unique id
and indeed a signature with the issuer's key. Points of debate are
whether one should allow various alphabets in the "free form
name", which is extremely natural and whether one should also
transcribe the issuer's free form name, which is only useful if the
DNS name is not a sufficient identifier. Going to far in this debate is not
the purpose of this message..
Christian Huitema