Ned, I'd like to address what I see as the most important of your points in the
last couple of messages. I think I am finally beginning to understand your
position, but given the same set of facts I come to different conclusions.
In this (lengthy) message I will attempt to restate what I think your (and
perhaps others) objections are to a system that would be based solely on the
use of certificates, including self-signed certificates, and then to try to
overcome or minimize those objections. Of course, if I have misunderstood your
objections you have the right to correct me. In a followup message I will
attempt to do the converse, that is lay out the reasons why I believe that an
exclusively certificate-based system is preferable, and the objections that I
have to non-certificate basd systems. You obviously have the right to try to
change my mind as well, and I trust that it is not too late for both of us to
have an open mind on these issues.
Steve Kent's summary of the July WG group meeting included the following
observation:
- It was noted that the format for use of email addresses as
user names (EN) does not have an accompanying certificate format
defined. The rationale for not using X.509 certificates is that
the use of email names as distinguished names is incompatible
with most X.500 directory schema conventions, even though it is
syntactically feasible.
I can't tell from that language whether those were his thoughts or someone
else's, perhaps yours, but some of your recent statements seem to be along the
same lines:
However, this sounds to me like a proposal that we do away with all forms but
those based on certs. This is not acceptable to me, as I've stated in a
previous message.
As far as key selectors go, they are not a big concern for me either way. I
think they are nice to have and the difficulty of supporting them has been
overstated, but I can live without them. What I cannot live without is some
alternative to the cert model.
I'm not making a big issue of the key selectors, either, but I don't want to
live WITH alternatives to the cert model, as I feel that the alternatives would
be generally harmful. Now that that issue is more clearly identified, let's try
to focus on why there is this difference in outlook. (I doubt that there is
some gene or DNA strand that is encoded for X.509 certificates, so presumably
the issue is nurture, rather than nature. We must have a different set of
expectations or premises.)
Well, my problem here is that you what you propose doesn't agree with this.
You're asking people to learn to ride without any sort of training wheels.
Even self-signed certs raise the bar too high. I would also argue that there's
a distinct advantage to having something of a transition between the
non-cert and cert-based approaches. Not much of one, mind you -- you should
not need to switch from PGP to PEM for example. But something that indicates
that you're getting something different now.
"Even self-signed certs raise the bar too high." That caught me totally by
surprise. So far, no one else has made that claim, not even Rhys Weatherley,
whom I respect and who is generally in favor of the simplest possible
mechanisms. But maybe your reasoning will become clearer later.
Once we have a basic self-signed certificate capability, we can progress to
an automatic, e-mail based certificate generator that is a real CA, albeit
with a limited amount of trust in its PCA policy. Some of the braver,
early-adopter users might skip the self-signed certificate step and go
directly to the e-mailed certificate.
But now you've bought everyone into setting up their distinguished names and
all that. I don't think this is a viable place to start when your entire goal
is to add a little security. In fact it is barely viable when setting up X.500
services, where your entire *intent* is this one capability.
Ah HA! At last! The old distinguished name issue raises its ugly head once
more! I thought by now that issue had been laid to rest, but obviously not.
Maaybe it's time for the wooden stake and garlic approach.
I think the issue is one of compatibility and commonality of mechanisms. The
difference in trust between a bare key that isn't bound to an identity by
anyone other than the recipient, and that provided by a self-signed
certificate, is very slight -- perhaps non-existant. But in my view, at
least, the compatible self-signed certificate mechanism provides a smooth,
easy growth path, with very little that has to be relearned or thrown away,
and no disruption in either the originator or the recipient's way of
communicating once the self-signed certificate is replaced with a "real"
one.
I think you are hoist on your own petard here. By using identical mechansisms
for what you see as different levels or qualities of service you are blurring
the distinction between the two to the casual user. MIME/PEM uses
non-identical mechanism for non-identical levels or qualities of service, and
I think this has MAJOR advantages over sleazing around with certs the way
you (and apparently RIPEM) want to do.
No, I don't think so. There is more than enough room for the "sleaze factor,"
if you want to call it that, within PEM and the existing PCA structure, so some
means of differentiating between good hierarchies and bad hierarchies must be
provided in that case as well. Both the mafia and the FBI are perfectly capable
of running PCA hierarchies that fit their intended purposes, and everyone
within each hierarchy will be able to adequately trust everyone else in that
same hierarchy. However, once you cross hierarchies, that trust model breaks
down, for it is no longer strictly an issue of identity confirmation. (This is
one of the problems that I have with the IPRA, but at least it allows you to
confirm that a PCA is what it claims to be, and gives you an opportunity to
examine the published policy. Cold comfort may be better than no comfort.
From my point of view a self-signed certificate received from a user is
(almost) the exact equivalent of a self-signed certificate received from a
PCA. It isn't registered with the IPRA, and I can't go to that PCA and expect
to find CRLs, necessarily, but as an expression of trust they are equivalent,
and I HAVE to have some way of managing them in my local cache of certificates
I trust. I also have to have some out-of-band trusted mechanism for receiving
them reliably, or someone could spoof me into believing that they were the
person or PCA described in the certificate.
I am assuming here that either the full chain of authorization is presented to
the user for his inspection (generally undesirable, because they will be
ignored after the second or third time), or the implementation will have some
way of specifying caution, warning, and error levels for more automatic
processing of certificate chains.
But lets come back to the issue of self-signed certs raising the bar too high,
and the question of distinguished names in certificates, for I suspect that in
your mind these issues are one and the same. This almost has to be the case,
for other than the DN of the issuer and the DN of the subject, there isn't much
else of value that is in a certificate (that's what's wrong with v1 and v2.)
(I'm ignoring the signature portion, obviously).
In order to be concrete, let me propose a certificate that looks something like
the following:
Certificate=signature{
SubjectDN=rfc822{"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>}, serial=1;
IssuerDN=rfc822{"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>, serial=0;
other necessary junk}
Assuming that the PEM/MIME implementation creates the certificate so that the
user doesn't have to calculate it by hand, why on earth does this raise the bar
more than about a centimeter off the floor? How much simpler could it possibly
get?
Likewise, if you want to use some other form of globally unique identifier as a
certificate DN, maybe even someone's country code and phone number, that's OK
too, although I personally might not give such a certificate much credance.
By your statement "But now you've bought everyone into setting up their
distinguished names and all that", I have to conclude that you don't agree that
the use of an RFC822 e-mail attribute would be acceptable for use as a DN in an
X.509 certificate.
I can only think of two reasons why you might think that. The first would be a
concern that the rfc822 attribute is not included in X.521's list of
(allegedly) "useful attributes," and is therefore nonstandard and difficult to
sell. I don't agree, but if you wish, use another attribute. How about
commonName, or even description? Using a more strongly typed and accurate
attribute like rfc822 would be preferable, but would the X.500 standards police
come and put us all in jail if we dared to misuse one of their holy attributes
in a PEM certificate, i.e., outside of X.500? If so, put a different OID on it
and call it "pemCommonName."
The second reason might be that you are hung up on equating the DN in the
certificate with a DN that is used to uniquely qualify and sometimes look up an
entry in an X.500 directory, and are concerned that existing directory schemas
might not support that usage. In other words, you might feel that both the DN
in the certificate and the DN in the directory have to make use of the same
organizational or geopolitical naming scheme, as God, ISO, and the ITU
apparently intended.
Balderdash!
(Although I will say that you might have some strange bedfellows in such a
belief, perhaps including Steve Kent and maybe Peter Williams, but I don't mind
if you don't, and I'll apologize if I've defamed anyone. :-)
But I don't think that viewpoint is correct, or that it reflects the viewpoint
of people who are trying to deploy X.500 systems very widely, including the
NADF.
I want to assure you that I am NOT basing my concern for using non-certificate
based systems on any assumption that X.500 will someday be the mechanism of
choice for distributing certificates and CRLs, although I hope and trust that
it will.
At this point in the deployment of PEM and/or PEM/MIME, I don't think it would
be prudent to even assume that X.500 exists, much less that it is the norm.
So concerns about whether the use of an rfc822 attribute as a DN in a
certificate would conform to someone's X.500 directory schema should be of very
little concern.
In point of fact, however, there is no reason at all that I am aware of that
would require that the DN in the certificate match the DN of the entry that
contains the certificate. Indeed, the users identified by the directory DN are
not necessarily even one-to-one with the number of certificates, so such a
correlation will generally be impossible.
I may have several different DNs, depending on how the directory is organized
and what I want to do with them. I might have one DN that includes my home
address, and another to goes to a blind PO box or a cottage on the beach.
Another DN might point to my CompuServe account, and a fourth to my home
computer which is connected to the Internet via a link to my company. A fifth
might be a "parent of" type of listing, if I still had a child living with me
and someone wanted to talk to me about a certain broken window. Finally, if I
were Madonna, or F. Lee Bailey, or Rush Limbaugh (heaven forefend!), and I
wanted people to be able to find me easily, I might very well take out listings
in multiple states, implying a different DN or at least an alias, even though
my actual address was the same in each case. (I am assuming here a more or less
conventional form of DN is used for listing purposes. If my DN were
surname=Smith, uniqueid=random_number, some of this wouldn't apply, but we
might still have the issue of Jane Doe, AKA Mrs. John Smith-Doe.)
All of these DNs would represent the same person, me, in the same role each
time, i.e., as a single residential person, so I am not talking about reusing a
single public key in multiple certificates. Only a single certificate is
involved, although copies might exist. Some of these DNs might be aliases of
each other, but in other cases I might actually have different listings and
different payload contents and/or access controls, and I might want people to
find me in different ways. More to the point, a single common certiificate
might be used for all of those different entries. In some cases, one or more
aliases might point to to a common set of entries, but in other cases, e.g.,
where different access controls are provided, the same certificate might
actually be replicated a number of times under different DNs.
Likewise, for a single given DN, say my organizational person DN, I might have
multiple certificates. One might be my PEM certificate, one my PKCS
certificate, one for DMS with my Tessera card, etc. Finally, if I want to solve
the manager/secretary problem, I may have one certificate for signatures and
another for encrypted mail which is sent to me.And even if my X.500 DN is my
rfc822 email name, I might have different roles that woudl require different
certificates.
To summarize, the DN that is in the certificate does not have to match the DN
that is used to look up the certificate in the directory, or vice versa. they
can't. They don't even have to have anything to do with each other. Period.
(That isn't to say that it might not be useful to have an optional reference
to the directory DN included within the certificate once we get to v3, for
backtracking or other purposes that we haven't yet thought of.)
In summary, I hope that I have illustrated why certificate-based systems can be
simple and easy to use, especially if rfc822 email names are used as DNs in
self-signed certificates.
BTW, Jeff Thompson pointed out to me that there could be some confusion as to
who the "self" is in self-signed certificates. Although the recipient of a
another user's bare key could conceivably create a certificate and sign it
himself and then return it to the originator to be included in the next
message, this is not what I was referring to. I am assuming that the originator
of the message creates a certificate containing his own name and public key,
and signs it using his own private key.
In a subsequent message I will spell out the reasons why I think that
certificate-based systems, even allegedly sleazy self-signed certificates, are
significantly superior to the use of bare keys which are bound to someother
user's identity only in the mind and local processor of the recipient of the
key or message.
I hope this is helpful. At a minimum, it s should help us understand more
precisely what our various positions and objections are.
Bob
----------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820