Re: Redundant Cert Mgmt Protocols

I'd like to take a different approach to what John said. I
think that the S/MIME spec should simply get out of the PKI business.
S/MIME v3 tells how to send end-to-end secure messages, and does not need
to deal with how you should talk to your CA. The latest -cert spec shows
how awful the PKI stuff can get.

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.
Unfortunately, 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. The CMP/CRS/CRMF debates seem like so much
posturing, given that all parties agree that the other parties have no or
few technical problems. However, they are 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 can
mandate:
- a sending MUA already has a cert (instead of telling them how to get
one)
- a receiving MUA already know how to get a CRL (instead of telling them
how to get one)
If we make these two assumptions, we can strip out most of the guck that
has appeared in -cert. Of course, we should give guidance about how both
of these were done in the past, as well as saying that it is likely that
PKIX will finish at some point and implementors might want to look at
that for PKI work.

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
circulate it here on the list so Blake has a good shot at both what to
take out as well as what suggestions to put in.

--Paul Hoffman, Director

--Internet Mail Consortium