类似于SSL 服务器证书问题,我应该为 S/MIME 使用哪些扩展,以及 CA 是否也应该以某种方式受到限制?
(我正在使用openssl,它目前创建CA和证书,基本上可以做所有事情)
类似于SSL 服务器证书问题,我应该为 S/MIME 使用哪些扩展,以及 CA 是否也应该以某种方式受到限制?
(我正在使用openssl,它目前创建CA和证书,基本上可以做所有事情)
RFC 3850中有详细说明。在实践中:
强烈建议将您的电子邮件地址包含在您的证书、Subject Alt Name
扩展名中(或者可能作为额外属性,subjectDN
但不推荐使用)。如果证书不包含电子邮件地址,您的通讯员将不得不寻找另一种方法将证书与您的电子邮件地址关联,并且大多数软件都会遇到问题(这意味着要支持,但这会让事情变得困难)其他人)。
如果您的证书使用受到Key Usage
扩展的限制,则digitalSignature
和/或nonRepudiation
必须在该扩展中明确允许。
如果证书包含Extended Key Usage
扩展,则它必须包含id-kp-emailProtection
OID (1.3.6.1.5.5.7.3.4) 或特殊的通用anyExtendedKeyUsage
OID (2.5.29.37.0)。
如果证书是仅签名证书(它包含 DSA 或 (EC)DSA 密钥,或通过 限制Key Usage
),则电子邮件加密将很难。有(曾经?)一种机制,您的软件会生成 Diffie-Hellman 密钥对,并将公钥附加到您发送的签名电子邮件中,从而允许收件人加密他们的回复。这在野外充其量是不支持的,并且它增加了一些额外的问题(例如额外的 DH 私钥的存储)。因此,您最好使用可加密的证书(RSA 密钥,不受Key Usage
扩展名的限制)。
理论上你可以有两个证书,一个用于电子邮件加密,一个用于电子邮件签名;这将是一个好主意。但是在该领域可能会发现有点缺乏支持。需要进行一些测试。
以前有一些特定于 Netscape 的扩展,它们是 Netscape Communicator 正确使用所必需的,但现在谁在运行呢?