RFC3261: SIP:23.2 S/MIME密钥交换

23.2 S/MIME Key Exchange
23.2 S/MIME密钥交换

   SIP itself can also be used as a means to distribute public keys in the following manner.

SIP本身也可以用作用于以以下方式分发公钥的手段。

   Whenever the CMS SignedData message is used in S/MIME for SIP, it MUST contain the certificate bearing the public key necessary to verify the signature.

无论何时在S/MIME for SIP中使用CMS SignedData消息，它都必须包含带有验证签名所需公钥的证书。

   When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body.  If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC SHOULD send the EnvelopedData message encapsulated within a SignedData message.

当UAC发送包含启动对话的S/MIME正文的请求，或在对话上下文之外发送非INVITE请求时，UAC应将正文结构为S/MIME“multipart/signed”CMS SignedData正文。如果所需的CMS服务是EnvelopedData（并且目标用户的公钥是已知的），则UAC应发送封装在SignedData消息中的Enveloped Data消息。

   When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS SHOULD first validate the certificate, if possible, with any available root certificates for certificate authorities.  The UAS SHOULD also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field of the request.  If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of request, the UAS MUST notify its user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint information) and request explicit permission before proceeding.  If the certificate was successfully verified and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after notification) explicitly authorizes the use of the certificate, the UAS SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate.

当UAS收到一个包含S/MIME CMS主体的请求，其中包含一个证书时，如果可能，UAS应首先使用证书颁发机构的任何可用根证书验证证书。UAS还应该确定证书的主题（对于S/MIME，SubjectAltName将包含适当的标识），并将该值与请求的From报头字段进行比较。如果证书无法验证，因为它是自签名的，或者没有已知的权威机构签名，或者如果它是可验证的，但其主题与请求的From报头字段不对应，UAS必须通知其用户证书的状态（包括证书的主题、签名者和任何密钥指纹信息）并在继续之前请求明确的许可。如果证书已成功验证，并且证书的主题对应于SIP请求的From报头字段，或者如果用户（在通知后）明确授权使用证书，则UAS应将此证书添加到本地密钥环中，该密钥环由证书持有人的记录地址编索引。

   When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body.  If the desired CMS service is EnvelopedData, the UAS SHOULD send the EnvelopedData message encapsulated within a SignedData message.

当UAS发送包含响应对话中第一个请求的S/MIME正文的响应，或在对话上下文之外对非INVITE请求的响应时，UAS应将正文结构为S/MIME“multipart/signed”CMS SignedData正文。如果所需的CMS服务是EnvelopedData，则UAS应发送封装在SignedData消息中的Enveloped Data消息。

   When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC SHOULD first validate the certificate, if possible, with any appropriate root certificate.  The UAC SHOULD also determine the subject of the certificate and compare this value to the To field of the response; although the two may very well be different, and this is not necessarily indicative of a security breach.  If the certificate cannot be verified because it is self-signed, or signed by no known authority, the UAC MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding.  If the certificate was successfully verified, and the subject of the certificate corresponds to the To header field in the response, or if the user (after notification) explicitly authorizes the use of the certificate, the UAC SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it SHOULD use a CMS SignedData body for its next request or response.

当UAC收到包含S/MIME CMS主体的响应（其中包含证书）时，如果可能，UAC应首先使用任何适当的根证书验证证书。UAC还应该确定证书的主题，并将该值与响应的To字段进行比较；尽管两者可能非常不同，并且这不一定表示安全漏洞。如果由于证书是自签名的或没有已知权威机构签名而无法验证证书，则UAC必须通知其用户证书的状态（包括证书的主题、签名者和任何密钥指纹信息），并在继续之前请求明确的许可。如果证书已成功验证，并且证书的主题对应于响应中的To报头字段，或者如果用户（在通知后）明确授权使用证书，则UAC应将此证书添加到本地密钥环中，该密钥环由证书持有人的记录地址编索引。如果UAC在之前的任何事务中都没有将自己的证书传输给UAS，那么它应该在下一个请求或响应中使用CMS SignedData主体。

   On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA SHOULD compare the certificate offered in these messages with the existing certificate in its keyring.  If there is a discrepancy, the UA MUST notify its user of a change of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the user's permission before continuing to process the signaling.  If the user authorizes this certificate, it SHOULD be added to the keyring alongside any previous value(s) for this address-of-record.

在未来的情况下，当UA接收到包含与其密钥环中的值相对应的From报头字段的请求或响应时，UA应该将这些消息中提供的证书与其密钥环内的现有证书进行比较。如果存在差异，UA必须通知其用户证书的改变（优选地以指示这是潜在的安全漏洞的方式），并且在继续处理信令之前获得用户的许可。如果用户授权此证书，则应将其与此记录地址的任何以前的值一起添加到密钥环中。

   Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used - it is vulnerable to well-known attacks.  In the opinion of the authors, however, the security it provides is proverbially better than nothing; it is in fact comparable to the widely used SSH application. These limitations are explored in greater detail in Section 26.4.2.

​但是，请注意，当使用自签名证书或由不知名的权威机构签名的证书时，这种密钥交换机制并不能保证密钥的安全交换，它很容易受到众所周知的攻击。然而，在作者看来，众所周知，它提供的安全性总比什么都没有好；它实际上与广泛使用的SSH应用程序相当。第26.4.2节对这些限制进行了更详细的探讨。

   If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it MUST reject the request with a 493 (Undecipherable) response.  This response SHOULD contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a 'certs-only' "smime-type" parameter.

如果UA接收到用接收方未知的公钥加密的S/MIME主体，则它必须用493（不可加密）响应拒绝该请求。此响应应在MIME正文中包含一个有效的响应者证书（如果可能，对应于被拒绝请求的To报头字段中给定的任何记录地址），该MIME正文带有“certs-only”“smime type”参数。

   A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not utilize S/MIME encrypted messages, though they may still support S/MIME signatures.

在没有任何证书的情况下发送的493（不可加密）表明应答者不能或不会使用S/MIME加密的消息，尽管它们可能仍然支持S/MIME签名。

   Note that a user agent that receives a request containing an S/MIME body that is not optional (with a Content-Disposition header "handling" parameter of "required") MUST reject the request with a 415 Unsupported Media Type response if the MIME type is not understood.  A user agent that receives such a response when S/MIME is sent SHOULD notify its user that the remote device does not support S/MIME, and it MAY subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack.

请注意，如果无法理解MIME类型，则接收到包含非可选S/MIME正文的请求的用户代理（Content-Disposition报头“handling”参数为“required”）必须使用415不支持的媒体类型响应拒绝该请求。当发送S/MIME时接收到此类响应的用户代理应通知其用户远程设备不支持S/MIME，并且如果合适，它随后可以在没有S/MIME的情况下重新发送请求；然而，该415响应可能构成降级攻击。

   If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body that is not secured, the UAC SHOULD notify its user that the session could not be secured. However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured.

如果用户代理在请求中发送S/MIME正文，但接收到包含不安全的MIME正文的响应，则UAC应通知其用户会话不安全。但是，如果支持S/MIME的用户代理接收到具有不安全主体的请求，则不应使用安全主体进行响应，但如果它期望来自发件人的S/MIME（例如，因为发件人的From报头字段值与其密钥链上的标识相对应），则UAS应通知其用户会话无法得到保护。

   A number of conditions that arise in the previous text call for the notification of the user when an anomalous certificate-management event occurs.  Users might well ask what they should do under these circumstances.  First and foremost, an unexpected change in a certificate, or an absence of security when security is expected, are  causes for caution but not necessarily indications that an attack is in progress.  Users might abort any connection attempt or refuse a connection request they have received; in telephony parlance, they could hang up and call back.  Users may wish to find an alternate means to contact the other party and confirm that their key has legitimately changed.  Note that users are sometimes compelled to change their certificates, for example when they suspect that the secrecy of their private key has been compromised.  When their private key is no longer private, users must legitimately generate a new key and re-establish trust with any users that held their old key.

当发生异常证书管理事件时，前一个文本调用中出现的许多条件需要通知用户。用户可能会问他们在这种情况下应该做什么。首先，证书中的意外更改，或在预期安全性的情况下缺乏安全性，都是需要谨慎的原因，但不一定表明攻击正在进行。用户可能会中止任何连接尝试或拒绝他们收到的连接请求；用电话的说法，他们可以挂断电话再打回来。用户可能希望找到另一种方式来联系另一方，并确认他们的密钥已合法更改。请注意，用户有时会被迫更改其证书，例如，当他们怀疑其私钥的保密性已被泄露时。当他们的私钥不再是私钥时，用户必须合法地生成新密钥，并与持有旧密钥的任何用户重新建立信任。

   Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during a dialog, the UA MUST notify its user of the change, preferably in terms that indicate that this is a potential security breach.

最后，如果在对话过程中，UA在CMS SignedData消息中接收到与之前在对话期间交换的证书不一致的证书，则UA必须将更改通知其用户，最好是指示这是潜在的安全漏洞。