We've all talked until we are blue in the face, and I suspect that no serious
change of position is likely to occur unless someone bends. I'd therefore like
to propose a horse trade of sorts -- not the usual type of compromise where the
two parties meet in the middle of a technical position, but a simple "you
scratch my back, I'll scratch yours" type of political deal.
I want to see v3 of X.509 standardized,implemented, and popularized, and I'll
do almost anything to make that happen. The key selectors may cause me a little
grief in generating and filing certificates, but if we gain widespread support
for v3 it will be worth it. So this is my proposal:
PROPOSAL:
I propose that we approve the current PEM/MIME specification for standards
track consideration, including the present key selector syntax, alleged warts
and all, AND SIMULTANEOUSLY that we formally adopt version 3 of X.509 (as
proposed in the Draft Technical Corrigendum distributed by Warwick Ford) as an
integral part of the PEM/MIME spec. This would be with the understanding that
the first one or two implementations of that spec may not fully support the v3
certificate extensions, maybe not even those flagged as critical.
I'm quite sure that we could all get in and debate the merits of one bit or
another in the new X.509 specification, but I think that a number of people
have already gone through a lot of that. At this point, I am willing to take on
faith the fact that the new certificate standard is reasonably sound
technically and an adequate basis for us to move ahead, just as I am prepared
to accept that the current PEM/MIME spec is technically sound with respect to
the basic MIME functionality.
Assuming that is the case, I believe that we need not wait for ISO/ITU to
finally and formally approve the new certificate format -- people like Warwick
and Hoyt Kesterson can push that forward will all deliberate speed. If
necessary, instead of waiting for the ink to dry, the IETF could register the
currently proposed X.509 v3 under the IETF's own OID and move on. If minor
changes become necessary and/or the ISO/ITU changes the spec slightly, we can
catch up with v4 of the IETF version in a year or so.)
In other words, I am NOT proposing that we hold up the PEM/MIME specification
(much less any particular implementation) for a protracted discussion of the
merits of the third bit from the left in v3, but rather that we accept it as
valid and move on. Since the concensus seems to be to twiddle bits first, and
then adjust the policy as required, let's assume that the X.509 committee has
done its job correctly and accept it as a given. If we find something seriously
worng, we'll fix it then.
I believe that if we do not seize the opportunity to fix what in my opinion has
been _the_ basic problem with PEM for the last several years, as all of the
discussion about naming and addressing schemes has shown, then the door will
close and all of the work we have done in the past will be for nought.
DISCUSSION:
The current discussion has pitted the purists who would like to do things
"right, now," vs. (some of) the potential vendors, who would like to do
something "right now."
The key issue (pun intended) seems to be the question of the key selector, and
despite Jeff Thompson's repeated pleas we still haven't heard a convincing
rationale for why we need one, or why the public key or a fixed length digest
of the public key isn't sufficient. (Warwick has recently suggested that a key
selector is necessary for proper key administration, and I'd like to see him
elaborate on that notion some more, but it isn't clear whether the current key
selector mechanism would support what he wants in any case.)
I suspect, however, that it goes back to Steve Crocker or Jim Galvin's issue
of not having a way of linking together an outbound e-mail message (which
contains only the destination e-mail addresses) with the original x.509
certificate, which only had a geopolitical-style DN in it. There was no simple
way to tell the TIS-PEM post-processor which certificate to retrieve to use to
encrypt the message. I don't think it had anything to do with hiding the public
keys, or with selecting the appropriate key at the destination, but I'd be
happy to be corrected.
As I have pointed out an almost uncountable number of times, there is
ABSOLUTELY NOTHING that has been proposed to go into a key selector that could
not be crammed into the DN field of an v1 X.509 certificate as a unique,
strongly-typed attribute, or even in a catch-all attribute such as
"Description", even at the risk of seeming to overconstrain the DN. X.500
directory services are more than flexible enough to cope with such a construct,
since the DN in the certificate doesn't have to match the DN of the user in the
directory, and probably won't. It's a damned shame that the PEM community,
myself included, didn't realize that fact before everyone's position's
hardened, but by then the damage was done.
As has also been pointed out a number of times, to the best of my knowledge at
least, there is also ABSOLUTELY NOTHING that PGP can do that can't be done with
PEM as well, using self-signed certificates and the "I'm my own PCA" approach.
(I won't argue triple-DES and other side issues for the moment.)
Why, then, can't we move forward? It seems that it is because people have a
lot of emotional capital, and maybe real capital invested in their respective
positions, and aren't willing to budge. It's Christmas time, and the __dog's__
in the manger.
Summarizing the various arguments as follows:
1. PGP doesn't provide a good way of institutionalizing the identification
process and the binding of a claimed identity to a claimed public key by means
of a third party, and in fact some of the PGP users think that is a Good Thing.
PGP does, however, provide a way for people or organizations who do trust their
correpondent's procedures to go ahead and exchange encrypted mail and perhaps
even honor digitally signed mail. The non-repudiation aspects of the system
aren't very robust, and there is a rather laissez-faire approach to issues of
certificate revocation, but the system has been proven to have some utility,
and I will concede the fact that it is in wide use.
2. PEM provides a policy mechanism whereby individuals and organizations who
agree to be bound by (and presumably will honor) a common identification policy
can all rally around a common PCA. In addition, even if you don't trust some
other PCA, perhaps because you or your organization doesn't have any kind of an
enforceable contract or relationship with that other PCA, you can still
syntactically validate the certificate. A more robust mechanism is required for
exchanging CRLs, and although there are still serious obstacles,a reasonably
sound foundation for nonrepudiation is provided. Unfortunately, for a number of
different reasons that have nothing to do with X.500 or X.509 but have a lot to
do with liability, the necessary CA infrastructure has been very slow to
develop, and people haven't adopted self-signed certificates as a near-term
alternative. In addition, the available PEM prototypes have (arguably) been
awkward, ugly, and on the wrong platforms.
3. PEM/MIME provides all of the functions of PEM (perhaps give or take a
niggling detail here and there), AND it potentially offers a much better, more
elegant user interface, and it makes a bow in the direction of the PGP
community by more directly addressing the issue of the direct trust model. The
implicit concern of some of the purists (myself included) is that it perhaps
makes too much of a bow in that direction, and that we will never be able to
put the genie back in the bottle again. The key selector seems to go to the
heart of this issue, by providing a mechanism for selecting public keys that is
not tied to X.509 certificates. Most, but not all, of those of us who have been
working on PEM for the last several years think it would be a tragic mistake if
the marketplace were to continue to move in that direction, and so a small
compromise in order to gain the larger objective may be in order. Of course,
the market may move in that direction despite our best efforts,
4. None of these systems as yet provide for a capability or ticket model, as
does Kerberos. None address the user's authority to direct or carry out a
particular action. None specifically address the liability issue, or really
solve the nonrepudiation problem. In addition to having to work out the legal
and social infrastructure to support these concepts, we as yet don't have the
technical infrastructure to support such notions, because of the constraints of
the version 1 and version 2 of X.509. HOWEVER, THE V3 VERSION OF X.509 DOES
PROVIDE AN ADEQUATE BASIS TO MOVE FORWARD ON SUCH ISSUES.
Jim, Ned, and Amanda, among others, have argued convincingly that the
integrated PEM/MIME spec has the functionality necessary to draw significant
numbers of additional users on board. I hope so, and I hope that by including
the v3 version of X.059 in the specification, even if not in the earliest
releases, that we can light a more substantial fire under the infrastructure
problem.
Comments? Acclamation? Applause??
Bob