>> I don’t think you should include #2 because it's a common practice to >> issue one certificate for Secure Mail that is used to both sign and >> encrypt, and this would preclude CA key generation for those types of >> certificates. >> >> I was attempting to match the existing "forbidden practice" >> requirement >that carves out an exception only for email encryption. >I don't know why that exception exists, but I do agree with you that it is >uncommon for an S/MIME certificate to support encryption but not signatures.
Actually it is very common: our CA has a couple of hundred thousand S/MIME certificates in the field, that are either for mail encryption or for mail signature but not for both. And I believe there are a lot of other enterprise CAs that do the same. There is a good reason for doing so: the private keys for both types of certificates are safely stored on our employees corporate ID smart card. But only the signature keys are also generated on the smart card. The encryption keys are generated centrally in the CA and then securely injected into the smart card. The reason for this split is, that we want to be absolutely sure, that the email signature is non-repudiationable by the holder of the card (as required by the European Unions eIDAS regulation for 'advanced electronic signature') but on the other hand side, we need to be able to perform a key escrow for the encryption keys, in case the card is damaged or lost or if there is court requirement to decrypt corporate emails and the holder of the card is not willing to do so. Don't hesitate to contact me, if you want to know more, how it works in our case. With best regards, Rufus Buschart Siemens AG GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
