Phill and Steve,
I respectfully disagree that we should add complexity to the S/MIME specs to
support key recovery. If a user community desires to support key recovery,
then they can populate a private extension in each of their subscriber's
certs that specifies the "corporate key" cert. When the application builds
a CMS envelopedData for the recipient, then the app examines the private
extension in the recipient's cert to detemine the "corporate key" cert.
Then the app can build a recipientInfo for the "corporate key" cert in
addition to the recipient's recipientInfo. This strategy can be implemented
without mentioning it in the S/MIME specs at all.
- John Pawling
At 04:18 PM 1/23/98 -0800, phil wrote:
Basically, what is involved is changing the user certificate format to
designate a field for a second certificate which represents the corporate
public key appropriate for that user. An application intending to encrypt
mail to that user MUST then encrypt the message to both the user key and the
corporate key.
I would word it differently, I would instread say that what we wish to do is
to define an attribute which defines a KEY, not a certificate to which the
message SHOULD also be encrypted.
The reason for prefering a key over a certificate is that all the
information is provided in a single package. The purpose of the certificate
is to perform identity binding to the key. I would like a direct binding to
what our PGP friends would call a 'mobby key'.
If it was desirable to achieve binding to a certificate to leverage key
revocation systems than I would suggest an OID with a required key
specificateion and an optional certificate serial number attribute.
The reasons I would specify SHOULD is simple, first we have to be backwards
compatible with the deployed base if possible, second I think you will find
that there is much more pushback on making a key recovery system mandatory
than optional.
In practice support for recovery will be optional for users since they can
always use an older mail client.
Phill