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