Steve,
OK, I see your point. If the S/MIME WG agree that this is a valid
requirement, then I recommend that the S/MIME v3 Certificate Handling spec
could be changed so that it includes a section defining a certificate
extension that identifies the "corporate key" cert. The ASN.1 syntax could
be a SEQUENCE of issuer GeneralNames and serialNumber (to uniquely identify
the cert). The text would state that the extension would be non-critical so
that non-S/MIME apps could share the use of the cert. The text would state
that a compliant S/MIME v3 agent MUST implement this extension (i.e.
recognize the OID and be able to decode the syntax) and MUST implement the
following rules: "When the application builds a CMS envelopedData for the
recipient, then the app MUST search for the "corporate key" extension in the
recipient's certificate. If the "corporate key" extension is present, then
the application MUST build a recipientInfo for the identified "corporate
key" certificate in addition to building a recipientInfo for the recipient's
certificate. Furthermore, the application MUST search for the "corporate
key" extension in the originator's cert. If the "corporate key" extension
is present, then the application MUST build a recipientInfo for the
identified "corporate key" cert." The text would also state that the
"corporate key" extension MAY be present in a cert. The "MAY" allows those
who want this feature to use it, but those that don't want the feature
implemented for their users can omit the extension from their users' certs
(but they still have to implement the feature to meet the MUST requirements
and so that they can honor the wishes of others that do populate the
extension in their users' certs).
- John Pawling
At 02:36 PM 1/23/98 -0700, Steve Russell wrote:
IMHO, the problem with someone using an extension is that generally
speaking, they will only be able to recover half of the mail (i.e. the mail
that the modified client sent). If the methodology for using corporate keys
(differentiated from key recovery which I agree shouldn't be in the spec) is
not included in the spec then from an customer implementation point of view,
the solution is not practical. Unless a customer can say that in order to
send me an S/MIME message you must also encrypt to this key, then the
majority of clients will not perform that encryption. If multiple client
vendors are going to be pushed for this type of solution (which we and at
least one other that may choose to identify themselves are), then it will
make everyone's life easier to agree of a methodology in a standard based way.
Steve