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.
(For a nunber of reasons, we have considered setting up a CA
for experimental purposes that would be deliberately disconnected from
any PCA and/or the IPRA hierarchy, so that we can play with these
concepts without exposing us to quite as much potential liability if
a certificate is misused.)
I've actually done this (set up an internal private PCA for experimentation),
for precisely these reasons.
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.
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?
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.
Amanda Walker
InterCon Systems Corporation
PGP Key fingerprint: 594F63C03B52DC4E37E9160DE733CD87
PEM MD5OfPublicKey: 8E4A21B7025943DE2EDC7CC038B3D6B1