Folks,
I've finally gotten around to reading a very long trail of PEM
messages on several threads streatching back over 6-7 weeks. This
message presents some observations on these general topics, rather
than issuing separate responses directed to indiviaul authors of the
messages which prompt thse observations. At the end of this message is
a topic list for the PEM WG meeting on Monday in Seattle.
1. Redefining the CA name subordination rule
This thread addressed the concern that, in an X.500
environment, it may not always be feasible to have the CA occupy the
directory entry which is superior to the CA or user names for which
certificates are being issued. The suggestions initially propopsed,
based on a new distingusihed attribute, and a slight mofdification of
the name subordination rule, were criticized because of conflicts with
existing DSAs. In order to avoid this problem (not a concern to those
who have no use of X.500 DSAs), we need a scheme that still allows us
to mark a certificate as being associated with a PCA or CA, and
prevents unauthorized creation of certificates that ought not have
these marks. Some suggestions for how to achieve this, using either
the subject public key info field, or the issuer and subject unique ID
fields, have been mentioned and need further work. In particular, the
ongoing work of Francisco Jordan strikes me as havin several good
ideas that may help in this regard, thought it also incorporates
other suggestions that I do not endorse.
2. Retrieving certificates when only a DNS name is known
Although DNS names often are not very descriptive, they are
the names used in addressing email throughout most of the Internet.
In the absence of any form of white pages that both holds certificates
and is widely available, we need some other means of being able to
retrieve certificates based on whatever collateral information we have
to identify a user. One suggestion is to use responders at the hosts
where users have mailboxes, calling for use of DNS names as serach
indices. This certainly seems feasible and was something I propsed to
the folks at TIS about 4 years ago, but which did not make it into the
RFCs. It fails to provide a real white pages sort of service,
suggesting that other means, e.g., adding certificates to whois++,
might make sense too. The bottom line is that we really could use a
white pages service where certificates are stored, but that service
does not HAVE to be X.500 in order to store certificates with X.500
DNs.
3. Putting DNS names in certificates
This thread takes on two forms, i.e., using DNS names in lieu
of more structured DN , or adding a DNS mailbox name to a "real" DN.
The arguments for the former approach often are based on the premise
that DNS mailbox names are perfectly adequate as DNs, since we use
them every day for email addressing and that's how we "know" people in
the Internet today. Counterarguments have been provided by folks who
observe that DNS names are, in the vast majority of instances, not a
preferred form of naming but rather an artifact of our means of naming
computers and accounts on those computers. These folks argue that
while DNS names may be the easiest ones to employ in a certificate,
because they are well known and an infrastructure exists for assigning
these names, they leave much to be desired as a long term basis for
descriptive naming. While it it certainly true that we employ email
names for IDs today, we have many examples where this leads to
confusion, delivery of message to other than the "intended"
recipients, etc. Do we want tomperpetuate this "feature" of current,
unsecure emai, systems in secure email systems?
One line or argument that I encountered stated that there
needs to be a means of securely binding email addresses to DNs for use
with PEM, if the email addresses are what the user employs in
addressing mail. There is some truth to this, but the argument
continued to suggest that this binding must involve signatures,
third-parties, etc. This is simply wrong. A DN is intended to
be suitably descriptive so that a user can identify the human being by
that name. The mailbox address is something we use for routing and,
due to relatievly poor email software, for identifying the user
associated with the mailbox. However, if presented with a well-formed
DN, I can decide if this is the recipient to whom I swish to send
email and I don't really care about the mailbox address. So, yes, I
need a locally secure binding between an email address and a
certificate if I use email addresses to select the certificates for
outbound mail, but I don't need anyone to vouch for that binding
because it is the DN that really identifies the party in question.
When I have addressed a message with email addresses and it is
being encrypted with PEM, a display of the DNs of the recipients would
be a feature (not a bug) that would allow a user to check the
recipient IDs using names that are more descriptive than the email
addresses. The argument that both names must be in a certificate or
security flaws can result seems mostly to be a function of a
particular implementation model, not a fundamental requirement.
Alternatively, if the user is comfortable with a locally-secure
DN-email address binding provided on his workstation, there is no need
to display the DNs and ask for user confirmation. 1422 makes it clear
that either approach is acceptable.
Attendent with this argument has been the claim that use of
DNs requires establishing a vast new infrastructure. Well, the answer
here is yes and no. It is erronsous to state that, in order to use
DNs in certificates, we must have a global X.500 directory system in
place. 1422 describes the requirements for management of the
certificate name space, for CA, PCAs, and the IPRA. The greatest
burden accrues to the IPRA to maintain a residential user database to
detect DN conflicts. For organizational DNs, the infrastructre
maintained by the IPRA is much more manageable, even if it were not to
be an interim measure. The burden that must be addressed by the CA at
an organizational site is a purely local one, with regard to name
management, and is not a substantial incremental burden relative to
the certificate issuaing process.
One proposal called for MANDATING inclusion of an email name
in the common name element of a DN. The context in which this
suggestion was offered strongly suggest that the implementor is
concernd about maintaining a mapping between DNS and emai, addresses
and wants to require inclusion of the email address as a convenient
means of solving this problem. The suggestion that the certificate
naking scheme be modified to allow one particular implementation
approach to easily provide for this mapping seems out of place in a
standards discussion. There are lots of ways to locally bind email
addresses and DNs, in a secure fashion, without imposing this
restriction on those who expressly do not wish such a binding.
Fortunately, the offeror of this proposal later softened the proposal
to make inclusion of the email name optional. I worry that an
implementor seeing the "optional" DNS address feature will produce
code that, if no email name is present in the DN, will fail to provide
a locally secure mapping between the two?
A common confusion appears in several arguments, namely why
use DNs at all. Someone suggested that the use of DNs is motivated
primarily by a desire/requirement for leaglly binding names. While it
is true that some applications have such a requirement , that is not
a universal requirement nor is it the fundamental rationale behind the
use of DNs. The fundamental motivation here is that DNs are, in most
cases, much more descriptive than DNS names. The use of DNs is an
attempt to provide, even for "less-than-legally-binding" email
exchanges, a better quality name. Non-repudiation can be provided with
any form of name in a certificate, but names that are not very
descriptive will tend to have less global utility both for
identification as well as for non-repudiation.
There is a cliam that the use of DNS address is a complete
success. Viewed solely from the standpoint of Internet growth, that
is hard to argue with. However, I encounter all sorts of DNS
addresses in mail messages and a large number of then carry an
embedded comment which purports to be the real name of the sender. If
people were happy with the quality of ID provided by their mailbox
addresses, why do they put in these other names? The answer, I think,
is that most people recognize that a terse DNS address is NOT very
descriptive and they want to be identified by a larger, more
descriptive name. The "signature" files appended to many messages
carry full organizational names and maybe titles, etc. Yet none of
this info is authenticated. Use of DNs is a means of allowing users
to express these more descriptive names, in a fashion that imbues them
with some assurance.
One proponent of DNS addresses in lieu of DNs suggests that an
user can select any additional information to be included along with
the DNS address, to provide descriptive functionality comparable to
that of a real DN. He also argues that examination of the names in
the certification path will make it clear who is vouching for what,
and thus this poses no real diminuation of the assurance offered by
the use of DNS addresses. This is not a bad argument, though in
detail it contains some errors, e.g., it states elsewhere that one can
tell when you encounter a PCA certificate because the termninal RDN
says it's a PCA (not really a requirement). If name subordination is
still applied, I agree that the addition of DNS addresses as "addenda"
could be relatively benign. However, it isn't clear just how easily
software can do the name subordination check with free form names (vs.
encoded DNs) and it is not reasonable to expect a user to pay close
attention to all of the certificates in chain. This suggestion
warrent further attention.
Another argument has been made that more decsriptive
information associated with a user can be obtained from a directory
service, e.g., FINGER. This misses the whole point of certificates.
The idea is to NOT have to trust a wide range of directories
maintained by lots of people, and with potentially (usually) unsecure
communication paths between the user and the directory. Those who
argue against adopting the naming infrastructure implied by X.500
should consider how they would secure global directories so that all
the info in every entry maintained by anyone can be trusted to
accurately identify the entity named in the entry, and so that the
retrieved entry info can be validated even when it is retrievd across
an unsecure path. Compared to this sort of problem, using DNs is
easy.
One argument stated that a certificate DN cannot be tied to a
DIT entry and a certificate cannot be issued until there is a
corresponding DIT entry. This is not true. The intent is that the
DNs in a certificate do correspond to DIT entries, whether those
entries existe YET or not. The goal of PEM was not to create a
certtificate with a DN which would conflcit with a valid DIT entry
that might already exist, or to create a certificate with DNs that
would not be capable of being registered in the DIT later. There is a
subtle, but real, difference between this intent and the suggestion
that a certificate cannot be issued until a DIT entry exists.
There have been questions about whether anyone has a DUA that
really uses certificates and strong authentication, a DSA that works
with such a DUA, and how about integration into an application. The
answer is that yes, I have seen two such examples demonstrated. One
was done for the government as a prototype for the Defense Message
System and was integrated with MSP, the secure email protocol
developed for that environment. The other is the fine integrated PEM
system done by Wolfgang Schnieder at GMD and demonstrated at a recent
meeting I attended in Stockholm. (The latter may not be an example of
use of strong authentication by the DSA and DUA, Wolfgang can answer
that.) I expect to see more examples in the near future because the
DMS is soliciting commercial software that embodies these facilities,
and major players (e.g., Microsoft) are responding to the procurement.
There has also been confusion about whether X.500 "mandates" a
relationship between the certificate stored in a DIT entry and the Dn
of the entry. The 1993 version of X.500 makes more explicit the type
of identity-based access controls that were only alluded to in the
1988 version. I think an examination of the 1993 text will illustrate
that, if the directory cannot find the certificate for a user in the
DIT entry corresponding to that user's DN, then the user will be
denied access (assuming this sort of strong authentication access
control is used). I would bet that the NADF folks are not paying much
attention to these access control matters, probably not wanting to
change inducing any any delay in offering their services based on
silly stuff like strong authentication. So, I am not surpirzed to
hear that the NADF folks are not hung up on fine points of what
certificates are stored where, etc.
I was rather puzzled to see one message that criticized the
use of DNs because two people might have very similar common names
within the same organization, and thus there was a likelihood that one
could be fooled by the similar DNs. Is certainly true that one can
have very similar names within the same organization and thus even a
DN may wind up being deceptively similar to another DN. So, no, DNs
are not a perfect solution to this problem of descriptive names for
certificates. However, I don't think anyone can disagree with the
observation that, by using shorter names (a "fetaure" of many DNS
names), we substantially increase the risk of confusion. I like to
point out a real example: Ed Starr and Susan Tarr both work at BBN and
people inside the company (much less outsiders) often can't recall
whether "starr" is the email name for Susan or Ed. At least with
well-chosen DNs we could avoid a larger number of similar, confusing
names.
Arguments that DNS names are "adequate" today, don't address
the growth of the Internet email community, the influx of new users
and organizations, and the namespace collisions that are already
occuring in this space. Some have questioned the claims that the DNS
namespace is becoming crowded and that short DNS names can't serve as
adequate identifiers forever. Yet, in a recent message about "is this
the same Bork" the sender had to use out of band means to decode the
DNS name to see that it referred to the federal reserve board. Those
of us who have dealt with the U.S. Government, especially the
Department of Defense, are well aware of the problems arising from
excessive use of three letter acronyms (TLAs).
Certainly there can be no doubt that not all the companies in
the world, even in just the English speaking world, can be registered
using terse names. (One comment about whether IBM is allowed to use
IBM alos misses the point. In the U.S., "IBM" is the legal name for
the company in question; it has national standing and could quite
comformatbly reister "IBM" as its organization name!) First come,
first served may be a "fair" algorithm for resolving competition for
names, but is hardly helps identify a 3 or 4 letter abbreviated
organization name. Yes, phone numbers are compact and capable of
addressing lots of people and organizations, but they are not
descriptive and descriptiveness is what the name in a certificate is
about, not its ability to be compatctly represented nor its ability to
route email. The line of argument that says "no problem, DNS names
will continue to be adequately descriptive for the forseable future"
is clearly untennable.
There seems to be substantial agreement that, for more formal
(e.g., business) purposes, names that are more descriptive than most
DNS names are preferred, if not essential. While those of us who have
been involved with Internet email since the beginning are comfortable
with DNS names, new users are not, as noted by a network administrator
dealing with a very large population. Yes, DNS names can be almost as
descriptive as DNs, if we made the DNS names longer and impose
conventions that call for geopolitical qualifiers. But the
administration of the DNS imposes no such constraints and it is hard
to imagine getting people to go back and change the existing DNS
assignments to conform to some new set of naming conventions.
Arguments have been made that we start with DNS names in
certificates and evolve to DNs later. This sounds tempting, but these
arguments don't seem to be accompanied by an explanation of how users
will be persuaded to move to DNs later. A benefit of using DNs in
certificates is that it does not conflict with the existing DNS
infrastructure; the downside is that it fails to exploit that
infrastructure. Dave Clark, in a brief discussion at an IAB retreat
last month, wholeheartedly agreed with my prediction that if we adopt
DNS names for certificates now, that we will live with them for a very
long while. He, like, I, remember the "temporary" buildings at MIT
that were errected in WWII, and stayed in place for over 40 years!
Much of the argument against using X.500 names is based on the
obsevrtaion that they are harder to type than short DNS names.
Sometimes the arguments are based on a confusion between X.400 O/R
names and DNs, and sometimes the arguments seem to be beased primarily
on the belief that anything that is associated with IOS or the CCITT
is, per force, a bad idea. The latter examples of confusion or
bigotry do not require a response. It is certainly true that most DNs
are longer than most DNS names, but I can find examples in which the
relative sizes are reversed, and examples where the sizes are fairly
comparable. Christian Huitema correctly observes that his DNS names
is almost as descriptive as a DN, and I would not be so opposed to
using DNS names if this were true in general. But, sadly, it is not
true for most names.
We have examples of secure email implementations that avoid
the need for a user to EVER have to type a long name, whether it is a
DNS name or a DN. While the ones I have seen are on SUNs, the
support requirements are not so great that a Mac or PC can't provide
the same interface. I am disappointed that there are not more PEM
implementations that exhibit this type of good user interface, as it
would go a long way to defusing this particular line of argument.
Again, are we to select a naming scheme for use with certificate
because some implementations do a very poor job of provding a user
friendly interface? I argue that we should be making an architectural
decision based on architectural argumemnts, not on arguments derrived
from poor implementations. A poor TCP implementation is not an
argument against TCP, but rather an argument against that
implementation.
The arguments for putting an email name into a DN as another
RDN (or a component of a multi-value RDN) are different. Some suggest
that without a DNS name in a certificate, it is too hard to mamage the
mapping between DNS names and DNs. There are implementations that
demonstrate the feasibility of such mappings being maintained locally,
e.g., on a per-user basis, so infeasibility is clearly not at issue
here. Ease of implementation seems to be the primary argument put
forth here, but that favors particular implementation choices. Are we
to select a particular naming approach because some implementations
have adopted a local certificate cache management approach vs. other,
equally viable approaches?
There has been an arguyment that if we go with DNS addresses
in certificate now, but allow for "real" DNs later, then we have
addressed the immediate concern of getting more folks to use PEM
immediately, and in time we can move to better quality naming as it
becomes available. This is an inituitively attractive argument for
incremental deployment, but the same folks who make this argument,
have also stated that they believe that if the DNS proves to be
inadequate for the long term Internet growth, then a new system will
evolve, but will be backward compatible with the current system. So,
this latter argument implies that if we support DNS addresses in
certificates now, as an alternative to DNs, the proponents of this
approach really have no belief that we will ever migrate to DNs in the
future and thus we wil be "stuck" with DNS addresses in certificate
for ever. I'd feel more comfortable if these folks expressed a
single, consistent position in these discussions.
4. Self-signed certificates
What can I say? Self-signed certificates are almost an
oxymoron. I do not disagree with the observation that such
certificates allow bottom up system growth. But what you get when
you take this path is a mess, with no sense of assurance. RIPEM, with
a certificate server capability, is precisely a system that requires
trust in that server (or set of servers when one isn't enough) and
that is counter to the goal of certificate use.
An analogous line of reasoning is associated with criticism of
the PCA concept. Several contributors continue to confuse trsut in an
individual vs. trust in the accuracy with which the individula is
identified. In light of this confusion, its hard to be persuaded by
arguments made by such folks. I like to cite a simple exmaple as a
means of illustrating the difference between these two concepts.
Inmates in the Mass prison system are identified by the Mass
Department of Corrections (MCI). It is probably fair to say that the
MCI folks could do a good (trustable) job of identifying the inmates,
but that the inmates themselves, are not especially trustworthy.
5. What should be included in a certificate?
Bob Jueneman has argued that there are lots of attributes
that one might wish to bind, securely, to a user, beyond his
distinguished name. I agree completely. However, there is a
question, which I think Frank Sudia raised, as to whether all of the
attributes should be bound into one certiifcate. X.500 DSAs use
identity-based access control and a certificate must contain a DN to
satisfy that (internal) access control constraint. However, one can
certainly imagine other access control models that would make use of
signed authorizations, in lieu of or in addition to the identification
provided by a certificate. These other signed authorizations can be
linked to a base, identity-certificate, and need not give rise to
other keys. This was already discussed in my previous long missive.
6. Separate Keys for Signatures and Encryption
In principle, having separate keys for and/or certificates for
these two services is quite reasonable. It is fair to argue that PEM
would be more general if it were modified to accommodate this
capability. However, I am bothered by the justifications given by the
advicates for these changes. Thus, I find myself being concerned not
because the general principle is bad (it isn't) but because the
arguments put forth in favor of the idea are questionable.
On one hand we have suggestions that person X should use an
encryption certificate with a private key shared with his secretary,
so that his secretary can read his mail when he's out. This still
strikes me as a terrible idea, since it presumes person X giving up
privacy, potentially to the dismay of someone sending purportedly
private mail to X.
One contributor advocated use of separate keys and maybe
certifiactes for encryption vs. signature on the basis that it would
ease export control restrictions. I don't think this is generally
true. If PEM software restricts the use of the public key in a
certificate to signing and does not support encryption, I think export
control is a red herring in this argument. The recent announcement by
RSADSI of a general export license for a version of RIPEM that is
restricted to signatures only, seems to lend even less credence to
this claim.
The best argument for use of separate keys/certificates is
when the algorithms being used must be separate because they perform
different crypto functions. The one example we have in the literature
today is the "NIST" suite of algorithms: SKIPJACK, DSA, SHA, KEA.
Here, there are separate algortihms for signature (DSA) and for key
exchange (KEA). However, even in this specific case, the same key
could be used for both DSA and KEA, though there are potential
adcantages to using separate keys for each function. I don't see much
support for this particular algorithm suite in the Internet community,
especially because of the key excrow provisions assoiciated with
SKIPJACK.
7. Including Mail Headers in PEM "body parts"
There have been some suggestions for this, but without much
rationale provided in messages. The comment that omitting the headers
makes the PEM spec "strangely lacking" confuses me. PEM has taken an
architectually clean approach of trying to be larger indepeneden of
the mail transport system, and including message headers would violate
this layering. This is distinct from the fialed approach of X.400
security features, which bind the two together. I'm such the intent
in having headres included as optional material is not going as far as
the X.400 approach, but still I find the suggestion "strangely
lacking" in explicit rationale, though maybe the MIME-PEM spec will
provide the rationale.
Note that there are many circumstances where inclusion of the
headers could cause confusion or imporper operation at a recipient UA,
depending on what the UA plans to do with these headers. For example,
many mail systems transform header, so if PEM processing is applied
before the transformation, the protected header information may not be
suitable for use in responding to the originator.
There is laos the question of trusting any of the header
information, given that t is generally under the control of the
orginator. So, for example, one migh not want the user to be tricked
into believing that the CC list indicated in the protected header is
any indication that the message was sent to these purported recipients.
-----------------------------------------------------
So, based on the discussions on this list over the last several weeks,
plus recent distribition of IDs or ID-like proposals, here are the
agenda topics for the next PEM WG meeting, in Seattle (Monday
afternoon). Voulenteers for each topic are solicited from among those
who will be attending this IETF meeting. Each voulenteer should come
prepared with slides for a presentation, followed by debate.
1. MIME-PEM ID
- discussion of changes since previous draft
- rationale for features that differ from 1421
- other?
2. Use of DNS Addresses in Certificates
- in addition to DNs
- in lieu of DNs
- encoding details
- name subordination
- other?
3. Self-signed certificates
- relaxing 1422 validation rules
- new field option
- other?
4. DN conventions for CAs and related topics
- (Warwick Ford and Francisco Jordan messages)
5. Independent Keys for Signature & Encryption
- rationale(s)
- candidate algorithms that require this feature?
6. Changes to Certificate Format
- Issuer and Subject UIDs (from 1993 format)
- extensible options for non-DN attributes
- other