Nelson Bolyard wrote: > I wrote: >>> If Microsoft has merely taken a DER-encoded object from another standard >>> and has incorporated it into a cert extension, that seems fine to me. >>> I hope they did it in such a way that existing BER/DER parsers of the >>> sMIMECapabilities attribute can just parse the extension body directly. > [..] > I have subsequently learned that this is specified in RFC 4262.
IMHO there are pros and cons for using this cert extension. I think section 3. and 4. of RFC 4262 are a bit vague about the implementation details and security considerations. I don't know how NSS caches the S/MIME capabilities received in signed S/MIME messages. But I'd suggest to add a time-stamp and update the S/MIME capabilities and timestamp whenever a new S/MIME message is received. I'd suggest to use the cert extension solely when no signed S/MIME message was received so far or the notBefore date of the e-mail cert is newer than the timestamp of the last S/MIME caps stored. Still this assumes that the issuing CA really knows about the correct S/MIME caps which could be true for corporate CAs issuing e-mail certs for a well-defined set of MUAs. Ciao, Michael. -- Michael Ströder E-Mail: mich...@stroeder.com http://www.stroeder.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
