I'm still waiting for current text from Jim before I make my suggestions,
but given the recent exchange between Bob and Ned I think I need to clarify
what I did and did not intend by my suggestion.
First, let me back up for a moment; I personally approve of the draft as is,
even without the "editorial changes" Jim has mentioned. My only interest
in making *any* suggestions at this point is in the (possibly Quixotic)
hope that I can bring the more vocal debaters into close enough agreement
by tweaking the language somewhat. I am *not* suggesting any changes to
the syntax defined by the proposal, only in the descriptive text. In other
words, I'm interested in addressing the political and collateral issues, not
the representational ones (which I repeat I think are fine as is).
Even this is sort of a last resort before I drop out of the discussion
completely and just deal with whatever gets standardized if it ever happens.
My own goals would be just as well served, in the absence of something
resembling an Internet standard, by using PKCS7 with the representation in
the current proposal. This is in fact even easier than trying to stay
aligned with RFC 1421, and makes some non-PEM interoperabilty problems
become much easier. In addition, I fully expect to be supporting multiple
security frameworks, just as I currently support multiple text formats,
graphics formats, authentication schemes, and so on. This is something
to keep in mind while reading the rest of this note.
The key selector issue seems to have mutated into the question of whether
or not the use of the X.509 certificate syntax should be mandated as the
only public key distribution syntax. I understand Bob (and some others)
as answering this with "yes," and Jim, Ned, and others as answering it with
"no."
My own point of view is that this is the wrong question. I think the
question is actually "should operation without certificates be allowed
to be called PEM?" Personally, I don't care. I'd be happy to have an
"application/pem-keys" which has a PEM certificate, an "application/pgp-keys"
which has a PGP key (perhaps signed), an "application/rsa-keys" which has
bare keys, and so on--whatever people actually want to use. From an
implementation standpoint, as long as the syntax for the actual algorithms
and keys is constant, this is all just tuning the user interface. This is
not to say it's not important--much of my job is designing and analyzing
user interfaces :). However, the question of whether or not to mandate
X.509 is to me very much a policy issue.
And as a policy issue, I find a number of arguments I've seen go past
recently to be specious. For example, X.509 is not going to die. Clearly,
many environments are well served by the PCA/CA framework, and more will
be as CAs come on line, ranging from the RSA Commercial and Unaffiliated
User CAs to the CAs that the U.S. Postal Service is bringing on line.
I fully expect X.509 to become the standard electronic form of identification,
analogous to drivers licenses, check cashing cards, and the like in
phsyical interchange. X.509 certainly doesn't somehow "need" our support
in a political sense. It simply exists, and we need to be able to support
operation in its framework (as the current draft does).
However, certificates are not necessary for all contexts, and simply for the
sake of parsimony I see no reason to mandate their use even where they are
irrelevant. Certificates are not the only way to verify public keys. If
I want to exchange private email with my mom, for example, all we'll do is
verify key hash values during a visit or over the phone. There is no
need for *any* certification infastructure in such a case. We just treat
it the same way as we do the exchange of postal addresses, new phone numbers,
or what have you. The same is true for interchange that involves formal
bilateral agreements as well as implicit ones. A contract may specify the
keys to be used in the course of the business governed by it, for example.
Getting a message encrypted with one of those keys is ipso facto certified.
On the other hand, It doesn't matter to me whether or not the certificate
and non-certificate based styles of operation use the same names for body
parts, or whether the certificate-less body parts have "pem" in their
names. If we want to make X.509 mandatory for something to be called "PEM,"
that's fine. It just means "PEM" will describe a smaller envelope.
Whether this is a bug or a feature depends on your point of view, I suppose.
To me, it literally doesn't matter. I'm already planning on supporting
RFC 1421, the MIME/PEM draft, PKCS7, and probably even PGP. Tracking
moving targets is nothing new to most Internet software developers :).
My entire reason for taking an active role in this discussion was in the
hope that a small investment of time now would result in a large savings
of both time and uncertainty later. I think I have failed, since it's
turned into a large investment of time now, with all too much uncertainty.
It'll be easier to just go back to watching and rev my software later if
necessary. At this point, this WG is no longer at the leading edge.
Even the Post Office is ahead of us.
Amanda Walker
InterCon Systems Corporation