This makes sense raised to the power of at least 10. It also makes the
"S" in S/MIME stand for both "Secure" and "Simple." Let's do it!
From: Paul Hoffman / IMC [SMTP:phoffman(_at_)imc(_dot_)org]
Sent: Monday, February 02, 1998 2:07 PM
To: ietf-smime(_at_)imc(_dot_)org [SMTP:ietf-smime(_at_)imc(_dot_)org]
Subject: Re: Redundant Cert Mgmt Protocols
I'd like to take a different approach to what John said. I think that
spec should simply get out of the PKI business. S/MIME v3 tells how to
end-to-end secure messages, and does not need to deal with how you
to your CA. The latest -cert spec shows how awful the PKI stuff can
A bit of history: S/MIME v2 included two PKI functions:
- enrolling or requesting a cert
- getting a CRL list
These both use PKCS 10 due to the fact that PKIX wasn't around.
PKIX part 3, which specifies how to do these actions, is still not
around, and I
suspect it is many months off due to political hassles in the PKIX WG.
CMP/CRS/CRMF debates seem like so much posturing, given that all
that the other parties have no or few technical problems. However,
absolutely getting in the way of S/MIME.
It is not clear to me that S/MIME v3 needs to do any PKI. Instead, we
- a sending MUA already has a cert (instead of telling them how to get
- a receiving MUA already know how to get a CRL (instead of telling
them how to
If we make these two assumptions, we can strip out most of the guck
appeared in -cert. Of course, we should give guidance about how both
were done in the past, as well as saying that it is likely that PKIX
at some point and implementors might want to look at that for PKI
If there is general agreement on the principle of us not specifying
how to do
PKI, I'll draft a list of changes to the current -cert draft and
here on the list so Blake has a good shot at both what to take out as
what suggestions to put in.
--Paul Hoffman, Director
--Internet Mail Consortium