Amanda, I've enjoyed this discussion and your approach to it. I think we are
getting somewhere. I'm waiting to hear some other folks chime in, either to
agree or disagree (or best of all propose a synthesis that we can all agree
with.) I'm not trying to carry this banner all by myself.
Although there may be pros and cons with respect to
its suitability to a particular application, an RFC822 e-mail name is
a perfectly good distinguished name to put in a certificate,
Indeed. This is generally what RSA's Persona CA puts into its
certificates.
Good. We have some agreement.
4. Because a user may have more than one key pair, some means of
uniquely identifying which key pair to use is required. But if you
hadn't effectively thrown out the use of conventional X.509
certificates, you could have used the same common mechanism for each
case, i.e, the issuer and serial numnber, even when the user is his
own issuer.
I have to agree with you on this one. I still think that a representation for
"bare key" is useful, especially in cases where you want encryption but not
signature, but I agree that the email/selector approach can be accomodated
with the existing X.509 format.
Just as a matter of curiosity, why do you think that a bare key is more useful
for encryption than for signature? I have tended to think that there was a very
strong duality between the two concepts, and almost always what was required
for one was required for the other. I should think that the need to be
reasonably sure exactly who it was that you were confiding your deep dark
secrets to would be very similar to the need to verify your correspondent's
bone fides before believe him. Why then would a bare key be more useful for
encryption?
But I have a lot of difficultly with your inventing new mechanisms
to solve problems that the old mechanisms were perfectly capable
of solving, if it means that many groups will have to modify or
abondon the infrastructure support tools that are having to be created.
I do not see how this is required; it would seem to me that those tools will
have to be modified anyway to support the new MIME-based representation; what
additional work do see this as requiring?
Just as you are champing at the bit to release a PEM/MIME implementation, I'm
working hard to develop a system for issuing and managing certificates within
an organization. The more I work with X.500 the more I am convinced that this
is a highly desirable way to accomplish this. In addition, we need to manage,
archive, revoke, etc. these certificates within an organization. None of this
has anything at all to do with MIME, and little to do with the integration of
PEM and MIME, or MIME and e-mail, or even PEM, MIME, and an X.500 directory
user agent.
In addition, I need to support and interoperate with other existing and
developing applications, including AOCE, forthcoming releases of Lotus Notes
and cc:mail, etc. Standards are important in this arena, and now I'm speaking
as a potential customer. The fact that AOCE and PEM began to diverge and
haven't yet begun the process of converging is bad enough -- now I'm likely to
have yet another PC/Mac incompatibility to worry about. I'm just hoping that it
won't get any worse. Jeff and Steve Dusse could probably come up with
additional and perhaps better examples and reasons.
I would therefore prefer that we begin the process of updating both
the existing PEM spec and the PEM/MIME spec to take advantgae of the
v3 certificate format, which would make what you are trying to do
even easier and add a lot of other capabilities as well.
I disagree. I don't mind modifying the proposal to allow version 1
certificates (self-signed or not) which use email addresses and the like in
DNs. I do, however, object to tying progress on MIME/PEM to future
development on X.509.
I'll agree that the ink on the draft technical corrigendum isn't quite dry yet.
But there has been a substantial amount of consensus on the basic direction,
and lots of folks in other groups have been looking at this -- notably X9. Just
as I'm willing to take on faith the work that others have done in the MIME area
(after a few ritual quibbles), I'd like to see us stay as close as possible to
the X.509 standards track. As George Allen used to say when he was coaching the
Redskins, "The future is now." I don't think that we would be tying progress on
PEM/MIME to future development of X.509 in any significant or deleterious
manner.
I and others are trying to get the NADF to move in this direction in a
concerted way, and even if they don't GTE and/or other potential directory
service providers may offer such capabilities unilaterally. In addition, the
Post Office has a major effort underway to support the certificate-based public
key infrastructure, and they will be able to devote far more resources to that
effort than RSA has to date. Even though we might be competitors in a certain
sense, I would like to see that effort succeed.
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820