Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 8591 Standard Velocity
Updates: 3261, 3428, 4975 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 April 2019
Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 8591 Standard Velocity
Updates: 3261, 3428, 4975 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 April 2019
SIP-Based Messaging with S/MIME
基于SIP的S/MIME消息传递
Abstract
摘要
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFCs 3261, 3428, and 4975.
与会话发起协议（SIP）一起使用的移动消息传递应用程序通常使用SIP消息方法和消息会话中继协议（MSRP）的某种组合。虽然它们提供了逐跳安全机制，但它们都不提供端到端保护。本文档提供了有关如何使用安全/多用途Internet邮件扩展（S/MIME）提供端到端身份验证、完整性保护和机密性的指导。它更新并澄清了RFC 3261、3428和4975。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8591.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8591.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 5
4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 6
4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 6
4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 7
4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 9
4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 9
4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 9
4.4.2. Certificate Validation . . . . . . . . . . . . . . . 9
5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 9
6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 10
7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 11
7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. SIP User Agent Capabilities . . . . . . . . . . . . . . . 11
7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12
8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 12
8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 13
8.3. Indicating Support for S/MIME . . . . . . . . . . . . . . 14
8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 15
9. S/MIME Interaction with Other SIP Messaging Features . . . . 15
9.1. Common Profile for Instant Messaging . . . . . . . . . . 15
9.2. Instant Message Disposition Notifications . . . . . . . . 16
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Signed Message in SIP including the Sender's Certificate 17
10.2. Signed Message in SIP with No Certificate . . . . . . . 19
10.3. MSRP Signed and Encrypted Message in a Single Chunk . . 20
10.4. MSRP Signed and Encrypted Message Sent in Multiple
Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Message Details . . . . . . . . . . . . . . . . . . 30
A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 30
A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 32
A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 33
A.3.1. Signed Message prior to Encryption . . . . . . . . . 33
A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 5
4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 6
4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 6
4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 7
4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 9
4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 9
4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 9
4.4.2. Certificate Validation . . . . . . . . . . . . . . . 9
5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 9
6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 10
7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 11
7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. SIP User Agent Capabilities . . . . . . . . . . . . . . . 11
7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12
8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 12
8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 13
8.3. Indicating Support for S/MIME . . . . . . . . . . . . . . 14
8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 15
9. S/MIME Interaction with Other SIP Messaging Features . . . . 15
9.1. Common Profile for Instant Messaging . . . . . . . . . . 15
9.2. Instant Message Disposition Notifications . . . . . . . . 16
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Signed Message in SIP including the Sender's Certificate 17
10.2. Signed Message in SIP with No Certificate . . . . . . . 19
10.3. MSRP Signed and Encrypted Message in a Single Chunk . . 20
10.4. MSRP Signed and Encrypted Message Sent in Multiple
Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Message Details . . . . . . . . . . . . . . . . . . 30
A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 30
A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 32
A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 33
A.3.1. Signed Message prior to Encryption . . . . . . . . . 33
A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
Several mobile messaging systems use the Session Initiation Protocol (SIP) [RFC3261], typically as some combination of the SIP MESSAGE method [RFC3428] and the Message Session Relay Protocol (MSRP) [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE method to send Short Message Service (SMS) messages. The Open Mobile Alliance (OMA) Converged IP Messaging (CPM) system [CPM] uses the SIP MESSAGE method for short "pager mode" messages and uses MSRP for large messages and for sessions of messages. The Global System for Mobile Communications Association (GSMA) Rich Communication Services (RCS) uses CPM for messaging [RCS].
一些移动消息传递系统使用会话发起协议（SIP）[RFC3261]，通常作为SIP消息方法[RFC3428]和消息会话中继协议（MSRP）[RFC4975]的某种组合。例如，LTE语音（VoLTE）使用SIP消息方法发送短消息服务（SMS）消息。开放移动联盟（OMA）聚合IP消息（CPM）系统[CPM]将SIP消息方法用于短“寻呼机模式”消息，并将MSRP用于大型消息和消息会话。全球移动通信系统协会（GSMA）丰富的通信服务（RCS）使用CPM进行消息传递[RCS]。
At the same time, organizations increasingly depend on mobile messaging systems to send notifications to their customers. Many of these notifications are security sensitive. For example, such notifications are commonly used for notice of financial transactions, notice of login or password change attempts, and the sending of two-factor authentication codes.
与此同时，企业越来越依赖移动消息系统向客户发送通知。这些通知中有许多是安全敏感的。例如，此类通知通常用于金融交易通知、登录或密码更改尝试通知以及发送双因素身份验证代码。
Both SIP and MSRP can be used to transport any content using Multipurpose Internet Mail Extensions (MIME) formats. The SIP MESSAGE method is typically limited to short messages (under 1300 octets for the MESSAGE request). MSRP can carry arbitrarily large messages and can break large messages into chunks.
SIP和MSRP都可以用于使用多用途Internet邮件扩展（MIME）格式传输任何内容。SIP消息方法通常仅限于短消息（消息请求少于1300个八位字节）。MSRP可以携带任意大的消息，并且可以将大消息分解成块。
While both SIP and MSRP provide mechanisms for hop-by-hop security, neither provides native end-to-end protection. Instead, they depend on S/MIME [RFC8550] [RFC8551]. However, at the time of this writing, S/MIME is not in common use for SIP-based and MSRP-based messaging services. This document updates and clarifies RFCs 3261, 3428, and 4975 in an attempt to make S/MIME for SIP and MSRP easier to implement and deploy in an interoperable fashion.
虽然SIP和MSRP都提供逐跳安全机制，但都不提供本机端到端保护。相反，它们依赖于S/MIME[RFC8550][RFC8551]。然而，在撰写本文时，基于SIP和基于MSRP的消息传递服务并不普遍使用S/MIME。本文档更新并澄清了RFC 3261、3428和4975，以使SIP和MSRP的S/MIME更易于以可互操作的方式实现和部署。
This document updates RFCs 3261, 3428, and 4975 to update the cryptographic algorithm recommendations and the handling of S/MIME data objects. It updates RFC 3261 to allow S/MIME signed messages to be sent without embedded certificates in some situations. Finally, it updates RFCs 3261, 3428, and 4975 to clarify error-reporting requirements for certain situations.
本文档更新了RFCs 3261、3428和4975，以更新加密算法建议和S/MIME数据对象的处理。它更新了RFC3261，以允许在某些情况下发送S/MIME签名的消息，而无需嵌入证书。最后，它更新了RFCs 3261、3428和4975，以澄清特定情况下的错误报告要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document discusses the use of S/MIME with SIP-based messaging. Other standardized messaging protocols exist, such as the Extensible Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other end-to-end protection formats exist, such as JSON Web Signatures [RFC7515] and JSON Web Encryption [RFC7516].
本文档讨论S/MIME与基于SIP的消息传递的使用。还存在其他标准化的消息传递协议，例如可扩展消息传递和存在协议（XMPP）[RFC6121]。同样，也存在其他端到端保护格式，如JSON Web签名[RFC7515]和JSON Web加密[RFC7516]。
This document focuses on SIP-based messaging because its use is becoming more common in mobile environments. It focuses on S/MIME, since several mobile operating systems already have S/MIME libraries installed. While there may also be value in specifying end-to-end security for other messaging and security mechanisms, it is out of scope for this document.
本文档重点介绍基于SIP的消息传递，因为它在移动环境中的使用越来越普遍。它主要关注S/MIME，因为一些移动操作系统已经安装了S/MIME库。虽然为其他消息传递和安全机制指定端到端安全性也可能有价值，但它不在本文档的范围之内。
MSRP sessions are negotiated using the Session Description Protocol (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar mechanisms. This document assumes that SIP is used for the offer/answer exchange. However, the techniques should be adaptable to other signaling protocols.
MSRP会话使用会话描述协议（SDP）[RFC4566]提供/应答机制[RFC3264]或类似机制进行协商。本文档假设SIP用于提供/应答交换。然而，这些技术应该适用于其他信令协议。
[RFC3261], [RFC3428], and [RFC4975] already describe the use of S/MIME. [RFC3853] updates SIP to support the Advanced Encryption Standard (AES). In aggregate, that guidance is incomplete, contains inconsistencies, and is still out of date in terms of supported and recommended algorithms.
[RFC3261]、[RFC3428]和[RFC4975]已经描述了S/MIME的使用。[RFC3853]更新SIP以支持高级加密标准（AES）。总的来说，该指南是不完整的，包含不一致性，并且在支持和推荐的算法方面仍然过时。
The guidance in RFC 3261 is based on an implicit assumption that S/MIME is being used to secure signaling applications. That advice is not entirely appropriate for messaging applications. For example, it assumes that message decryption always happens before the SIP transaction completes.
RFC 3261中的指南基于一个隐含的假设，即S/MIME用于保护信令应用程序。这一建议并不完全适用于消息传递应用程序。例如，它假设消息解密总是在SIP事务完成之前发生。
This document offers normative updates and clarifications to the use of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt to define a complete secure messaging system. Such a system would require considerable work around user enrollment, certificate and key generation and management, multi-party chats, device management, etc. While nothing herein should preclude those efforts, they are out of scope for this document.
本文档对S/MIME与SIP消息方法和MSRP的使用进行了规范性更新和澄清。它不试图定义完整的安全消息传递系统。这样一个系统需要围绕用户注册、证书和密钥生成和管理、多方聊天、设备管理等进行大量工作。虽然本文中的任何内容都不应排除这些工作，但它们不在本文档的范围之内。
This document primarily covers the sending of single messages -- for example, "pager-mode messages" sent using the SIP MESSAGE method and "large messages" sent in MSRP. Techniques to use a common signing or encryption key across a session of messages are out of scope for this document.
本文档主要介绍单个消息的发送——例如，使用SIP消息方法发送的“寻呼机模式消息”和在MSRP中发送的“大型消息”。在消息会话中使用公共签名或加密密钥的技术超出了本文档的范围。
Cryptographic algorithm requirements in this document are intended to supplement those already specified for SIP and MSRP.
本文件中的加密算法要求旨在补充已经为SIP和MSRP规定的要求。
The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation syntax that is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. The CMS supports a variety of architectures for certificate-based key management, especially the one defined by the IETF PKIX (Public Key Infrastructure using X.509) Working Group [RFC5280]. The CMS values are generated using ASN.1 [X680], using the Basic Encoding Rules (BER) and Distinguished Encoding Rules (DER) [X690].
加密消息语法（CMS）[RFC5652]是一种封装语法，用于对任意消息内容进行数字签名、摘要、身份验证或加密。CMS支持各种基于证书的密钥管理体系结构，特别是IETF PKIX（使用X.509的公钥基础设施）工作组[RFC5280]定义的体系结构。CMS值是使用ASN.1[X680]，使用基本编码规则（BER）和区分编码规则（DER）[X690]生成的。
The S/MIME Message Specification [RFC8551] defines MIME body parts based on the CMS. In this document, the application/pkcs7-mime media type is used to digitally sign an encapsulated body part, and it is also used to encrypt an encapsulated body part.
S/MIME消息规范[RFC8551]基于CMS定义MIME正文部分。在本文档中，application/pkcs7 mime媒体类型用于对封装的主体部分进行数字签名，也用于对封装的主体部分进行加密。
While both SIP and MSRP require support for the multipart/signed format, the use of application/pkcs7-mime is RECOMMENDED for most signed messages. Experience with the use of S/MIME in electronic mail has shown that multipart/signed bodies are at greater risk of "helpful" tampering by intermediaries, a common cause of signature validation failure. This risk is also present for messaging applications; for example, intermediaries might insert Instant Message Disposition Notification (IMDN) requests [RFC5438] into messages. (See Section 9.2.) The application/pkcs7-mime format is also more compact, which can be important for messaging applications, especially when using the SIP MESSAGE method. (See Section 7.1.) The use of multipart/signed may still make sense if the message needs to be readable by receiving agents that do not support S/MIME.
虽然SIP和MSRP都需要支持多部分/签名格式，但对于大多数签名消息，建议使用application/pkcs7 mime。在电子邮件中使用S/MIME的经验表明，多部分/签名机构更容易被中间人“有用”篡改，这是签名验证失败的常见原因。消息传递应用程序也存在这种风险；例如，中介可以将即时消息处置通知（IMDN）请求[RFC5438]插入消息中。（参见第9.2节。）application/pkcs7 mime格式也更加紧凑，这对于消息传递应用程序非常重要，尤其是在使用SIP消息方法时。（参见第7.1节。）如果消息需要由不支持S/MIME的接收代理读取，则使用多部分/签名仍然有意义。
When generating a signed message, sending User Agents (UAs) SHOULD follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=signed-data. When validating a signed message, receiving UAs MUST follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=signed-data.
生成签名消息时，发送用户代理（UAs）应遵循[RFC8551]中针对smime type=签名数据的应用程序/pkcs7 mime媒体类型指定的约定。验证签名消息时，接收UAs必须遵循[RFC8551]中为smime type=签名数据的应用程序/pkcs7 mime媒体类型指定的约定。
Sending and receiving UAs MUST support the SHA-256 message digest algorithm [RFC5754]. For convenience, the SHA-256 algorithm identifier is repeated here:
发送和接收UAs必须支持SHA-256消息摘要算法[RFC5754]。为方便起见，此处重复SHA-256算法标识符：
id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
Sending and receiving UAs MAY support other message digest algorithms.
发送和接收UAs可能支持其他消息摘要算法。
Sending and receiving UAs MUST support the Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST P-256 elliptic curve and the SHA-256 message digest algorithm [RFC5480] [RFC5753]. Sending and receiving UAs SHOULD support the Edwards-curve Digital Signature Algorithm (EdDSA) with curve25519 (Ed25519) [RFC8032] [RFC8419]. For convenience, the ECDSA with SHA-256 algorithm identifier, the object identifier for the well-known NIST P-256 elliptic curve, and the Ed25519 algorithm identifier are repeated here:
发送和接收UAs必须支持使用NIST P-256椭圆曲线和SHA-256消息摘要算法[RFC5480][RFC5753]的椭圆曲线数字签名算法（ECDSA）。发送和接收UAs应支持带有Curve2519（Ed25519）[RFC8032][RFC8419]的爱德华兹曲线数字签名算法（EdDSA）。为方便起见，此处重复使用具有SHA-256算法标识符的ECDSA、著名NIST P-256椭圆曲线的对象标识符和Ed25519算法标识符：
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 }
-- Note: The NIST P-256 elliptic curve is also known as secp256r1.
--注：NIST P-256椭圆曲线也称为secp256r1。
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
id-Ed25519 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) thawte(101) 112 }
id-Ed25519 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) thawte(101) 112 }
When generating an encrypted message, sending UAs MUST follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=auth-enveloped-data. When decrypting a received message, receiving UAs MUST follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=auth-enveloped-data.
生成加密消息时，发送UAs必须遵循[RFC8551]中为smime type=auth信封数据的应用程序/pkcs7 mime媒体类型指定的约定。解密接收到的消息时，接收UAs必须遵循[RFC8551]中为smime type=auth信封数据的应用程序/pkcs7 mime媒体类型指定的约定。
Sending and receiving UAs MUST support the AES-128-GCM algorithm for content encryption [RFC5084]. For convenience, the AES-128-GCM algorithm identifier is repeated here:
发送和接收UAs必须支持AES-128-GCM算法进行内容加密[RFC5084]。为方便起见，此处重复AES-128-GCM算法标识符：
id-aes128-GCM OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 6 }
id-aes128-GCM OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 6 }
Sending and receiving UAs MAY support other content-authenticated encryption algorithms.
发送和接收UAs可能支持其他内容认证加密算法。
Sending and receiving UAs MUST support the AES-128-WRAP algorithm for encryption of one AES key with another AES key [RFC3565]. For convenience, the AES-128-WRAP algorithm identifier is repeated here:
发送和接收UAs必须支持AES-128-WRAP算法，用于将一个AES密钥与另一个AES密钥进行加密[RFC3565]。为方便起见，此处重复AES-128-WRAP算法标识符：
id-aes128-wrap OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 5 }
id-aes128-wrap OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 5 }
Sending and receiving UAs MAY support other key-encryption algorithms.
发送和接收UAs可能支持其他密钥加密算法。
Symmetric key-encryption keys can be distributed before messages are sent. If sending and receiving UAs support previously distributed key-encryption keys, then they MUST assign a KEKIdentifier [RFC5652] to the previously distributed symmetric key.
可以在发送消息之前分发对称密钥加密密钥。如果发送和接收UAs支持以前分发的密钥加密密钥，则它们必须为以前分发的对称密钥分配KEKIdentifier[RFC5652]。
Alternatively, a key agreement algorithm can be used to establish a single-use key-encryption key. If sending and receiving UAs support key agreement, then they MUST support the Elliptic Curve Diffie-Hellman (ECDH) algorithm using the NIST P-256 elliptic curve and the ANSI-X9.63-KDF key derivation function with the SHA-256 message digest algorithm [RFC5753]. If sending and receiving UAs support key agreement, then they SHOULD support the ECDH algorithm using curve25519 (X25519) [RFC7748] [RFC8418]. For convenience, (1) the identifier for the ECDH algorithm using the ANSI-X9.63-KDF with the SHA-256 algorithm and (2) the identifier for the X25519 algorithm are repeated here:
或者，可以使用密钥协商算法来建立一次性密钥加密密钥。如果发送和接收UAs支持密钥协商，则它们必须支持使用NIST P-256椭圆曲线的椭圆曲线Diffie-Hellman（ECDH）算法和使用SHA-256消息摘要算法的ANSI-X9.63-KDF密钥派生函数[RFC5753]。如果发送和接收UAs支持密钥协商，那么它们应该支持使用curve25519（X25519）[RFC7748][RFC8418]的ECDH算法。为方便起见，（1）此处重复使用ANSI-X9.63-KDF和SHA-256算法的ECDH算法标识符和（2）X25519算法标识符：
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
id-X25519 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) thawte(101) 110 }
id-X25519 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) thawte(101) 110 }
RFC 3261, Section 23.2 says that when a User Agent Client (UAC) sends signed and encrypted data, it "SHOULD" send an EnvelopedData object encapsulated within a SignedData message. That essentially says that one should encrypt first, then sign. This document updates RFC 3261 to say that, when sending signed and encrypted user content in a SIP MESSAGE request, the sending UAs MUST sign the message first, and then encrypt it. That is, it must send the SignedData object inside an AuthEnvelopedData object. For interoperability reasons, recipients SHOULD accept messages signed and encrypted in either order.
RFC 3261第23.2节指出，当用户代理客户端（UAC）发送签名和加密数据时，它“应该”发送封装在签名数据消息中的信封数据对象。这本质上是说应该先加密，然后签名。本文档更新了RFC 3261，说明在SIP消息请求中发送经过签名和加密的用户内容时，发送UAs必须首先对消息进行签名，然后对其进行加密。也就是说，它必须在AuthEnvelopedData对象内发送SignedData对象。出于互操作性原因，收件人应接受按任意顺序签名和加密的邮件。
Sending and receiving UAs MUST follow the S/MIME certificate-handling procedures [RFC8550], with a few exceptions detailed below.
发送和接收UAs必须遵循S/MIME证书处理过程[RFC8550]，以下详述了一些例外情况。
In both SIP and MSRP, the identity of the sender of a message is typically expressed as a SIP URI.
在SIP和MSRP中，消息发送者的身份通常表示为SIPURI。
The subject alternative name extension is used as the preferred means to convey the SIP URI of the subject of a certificate. Any SIP URI present MUST be encoded using the uniformResourceIdentifier CHOICE of the GeneralName type as described in [RFC5280], Section 4.2.1.6. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs MAY be present.
使用者替代名称扩展用作传送证书使用者的SIP URI的优选手段。必须使用[RFC5280]第4.2.1.6节所述的通用名称类型的uniformResourceIdentifier选项对存在的任何SIP URI进行编码。由于SubjectAltName类型是GeneralName的序列，因此可能存在多个URI。
Other methods of identifying a certificate subject MAY be used.
可以使用识别证书主体的其他方法。
When validating a certificate, receiving UAs MUST support the ECDSA using the NIST P-256 elliptic curve and the SHA-256 message digest algorithm [RFC5480].
验证证书时，接收UAs必须使用NIST P-256椭圆曲线和SHA-256消息摘要算法[RFC5480]支持ECDSA。
Sending and receiving UAs MAY support other digital signature algorithms for certificate validation.
发送和接收UAs可能支持用于证书验证的其他数字签名算法。
SIP and MSRP UAs are always capable of receiving binary data. Inner S/MIME entities do not require base64 encoding [RFC4648].
SIP和MSRP UAs始终能够接收二进制数据。内部S/MIME实体不需要base64编码[RFC4648]。
Both SIP and MSRP provide 8-bit safe transport channels; base64 encoding is not generally needed for the outer S/MIME entities.
SIP和MSRP都提供8位安全传输通道；外部S/MIME实体通常不需要base64编码。
However, if there is a chance a message might cross a 7-bit transport (for example, gateways that convert to a 7-bit transport for intermediate transfer), base64 encoding may be needed for the outer entity.
但是，如果消息可能会通过7位传输（例如，转换为7位传输以进行中间传输的网关），则外部实体可能需要base64编码。
Messaging UAs may implement a subset of S/MIME capabilities. Even when implemented, some features may not be available due to configuration. For example, UAs that do not have user certificates cannot sign messages on behalf of the user or decrypt encrypted messages sent to the user. At a minimum, a UA that supports S/MIME MUST be able to validate a signed message.
消息UAs可以实现S/MIME功能的子集。即使在实施时，由于配置原因，某些功能也可能不可用。例如，没有用户证书的UAs不能代表用户对消息进行签名或解密发送给用户的加密消息。至少，支持S/MIME的UA必须能够验证签名消息。
End-user certificates have long been a barrier to large-scale S/MIME deployment. But since UAs can validate signatures even without local certificates, the use case of organizations sending secure notifications to their users becomes a sort of "low-hanging fruit". That being said, the signed-notification use case still requires shared trust anchors.
长期以来，最终用户证书一直是大规模S/MIME部署的障碍。但是，由于UAs即使没有本地证书也可以验证签名，因此组织向其用户发送安全通知的用例就成了一种“低挂果实”。尽管如此，签名通知用例仍然需要共享信任锚。
SIP and MSRP UAs advertise their level of support for S/MIME by indicating their capability to receive the "application/pkcs7-mime" media type.
SIP和MSRP UAs通过指示其接收“application/pkcs7 MIME”媒体类型的能力来宣传其对S/MIME的支持级别。
The fact that a UA indicates support for the "multipart/signed" media type does not necessarily imply support for S/MIME. The UA might just be able to display clear-signed content without validating the signature. UAs that wish to indicate the ability to validate signatures for clear-signed messages MUST also indicate support for "application/pkcs7-signature".
UA表示支持“多部分/签名”媒体类型的事实并不一定意味着支持S/MIME。UA可能只是能够显示清晰的签名内容，而无需验证签名。希望表明能够验证清晰签名消息的签名的UAs还必须表明支持“应用程序/pkcs7签名”。
A UA can indicate that it can receive all smime-types by advertising "application/pkcs7-mime" with no parameters. If a UA does not accept all smime-types, it advertises the media type with the appropriate parameters. If more than one smime-type is supported, the UA includes a separate instance of the media-type string, appropriately parameterized, for each.
UA可以通过不带参数的“application/pkcs7 mime”广告来表示它可以接收所有smime类型。如果UA不接受所有smime类型，它将使用适当的参数播发媒体类型。如果支持多个smime类型，UA会为每个smime类型包含一个单独的媒体类型字符串实例，并进行适当的参数化。
For example, a UA that can only receive signed-data would advertise "application/pkcs7-mime; smime-type=signed-data".
例如，只能接收签名数据的UA将公布“application/pkcs7 mime；smime type=signed data”。
SIP signaling can fork to multiple destinations for a given Address of Record (AoR). A user might have multiple UAs with different capabilities; the capabilities remembered from an interaction with one such UA might not apply to another. (See Section 7.2.)
SIP信令可以为给定的记录地址（AoR）分叉到多个目的地。一个用户可能有多个具有不同功能的UAs；从与这样一个UA的交互中记住的能力可能不适用于另一个UA。（见第7.2节。）
UAs can also advertise or discover S/MIME using out-of-band mechanisms. Such mechanisms are beyond the scope of this document.
UAs还可以使用带外机制发布或发现S/MIME。这种机制超出了本文件的范围。
The use of S/MIME with the SIP MESSAGE method is described in Section 11.3 of [RFC3428], and for SIP in general in Section 23 of [RFC3261]. This section and its child sections offer clarifications for the use of S/MIME with the SIP MESSAGE method, along with related updates to RFCs 3261 and 3428.
[RFC3428]第11.3节中描述了S/MIME与SIP消息方法的结合使用，而[RFC3261]第23节中描述了SIP的一般用法。本节及其子节对S/MIME与SIP消息方法的使用进行了说明，并对RFCs 3261和3428进行了相关更新。
SIP MESSAGE requests are typically limited to 1300 octets. That limit applies to the entire message, including both SIP header fields and the message content. This is due to the potential for fragmentation of larger requests sent over UDP. In general, it is hard to be sure that no proxy or other intermediary will forward a SIP request over UDP somewhere along the path. Therefore, S/MIME messages sent using the SIP MESSAGE method should be kept as small as possible. Messages that will not fit within the limit can be sent using MSRP.
SIP消息请求通常限于1300个八位字节。该限制适用于整个消息，包括SIP头字段和消息内容。这是因为通过UDP发送的较大请求可能会出现碎片。一般来说，很难确定没有代理或其他中介将通过UDP在路径的某个位置转发SIP请求。因此，使用SIP消息方法发送的S/MIME消息应尽可能小。不符合限制的消息可以使用MSRP发送。
Section 23.2 of [RFC3261] requires that a SignedData message contain a certificate to be used to validate the signature. In order to reduce the message size, this document updates that text to say that a SignedData message sent in a SIP MESSAGE request SHOULD contain the certificate but MAY omit it if the sender has reason to believe that the recipient (1) already has the certificate in its keychain or (2) has some other method of accessing the certificate.
[RFC3261]第23.2节要求SignedData消息包含用于验证签名的证书。为了减小消息大小，本文档更新该文本，说明在SIP消息请求中发送的SignedData消息应包含该证书，但如果发送方有理由相信接收方（1）已在其密钥链中拥有该证书，或者（2）具有访问该证书的其他方法，则可以忽略该证书。
SIP UAs can theoretically indicate support for S/MIME by including the appropriate media type or types in the SIP Accept header field in a response to an OPTIONS request, or in a 415 (Unsupported Media Type) response to a SIP request that contained an unsupported media type in the body. Unfortunately, this approach may not be reliable in the general case. In the case where a downstream SIP proxy forks an OPTIONS or other non-INVITE request to multiple User Agent Servers (UASs), that proxy will only forward the "best" response. If the recipient has multiple devices, the sender may only learn the capabilities of the device that sent the forwarded response. Blindly trusting this information could result in S/MIME messages being sent to UAs that do not support it, which would be at best confusing and at worst misleading to the recipient.
SIP UAs理论上可以通过在对选项请求的响应中，或在对主体中包含不支持的媒体类型的SIP请求的415（不支持的媒体类型）响应中，在SIP Accept header字段中包括适当的媒体类型来指示对S/MIME的支持。不幸的是，这种方法在一般情况下可能不可靠。在下游SIP代理将选项或其他非INVITE请求分叉到多个用户代理服务器（UAS）的情况下，该代理将只转发“最佳”响应。如果收件人有多个设备，则发件人可能只了解发送转发响应的设备的功能。盲目信任此信息可能会导致S/MIME消息被发送到不支持它的UAs，这充其量会让收件人感到困惑，最坏的情况下会误导收件人。
UAs might be able to use the UA capabilities framework [RFC3840] to indicate support. However, doing so would require the registration of one or more media feature tags with IANA.
UAs可能能够使用UA能力框架[RFC3840]来表示支持。但是，这样做需要向IANA注册一个或多个媒体功能标签。
UAs MAY use other out-of-band methods to indicate their level of support for S/MIME.
UAs可以使用其他带外方法来表示其对S/MIME的支持级别。
Section 23.2 of [RFC3261] requires that the recipient of a SIP request that includes a body part of an unsupported media type and a Content-Disposition header field "handling" parameter of "required" return a 415 (Unsupported Media Type) response. Given that SIP MESSAGE exists for no reason other than to deliver content in the body, it is reasonable to treat the top-level body part as always required. However, [RFC3428] makes no such assertion. This document updates Section 11.3 of [RFC3428] to add the statement that a UAC that receives a SIP MESSAGE request with an unsupported media type MUST return a 415 response.
[RFC3261]第23.2节要求SIP请求的接收者返回415（不支持的媒体类型）响应，该SIP请求包括不支持的媒体类型的主体部分和“必需”的内容处置头字段“handling”参数。鉴于SIP消息的存在除了在主体中传递内容之外没有其他原因，因此，将顶层主体部分视为始终需要的是合理的。但是，[RFC3428]没有这样的断言。本文档更新了[RFC3428]的第11.3节，以添加以下语句：接收不支持媒体类型的SIP消息请求的UAC必须返回415响应。
Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME body encrypted to the wrong certificate, it MUST return a SIP 493 (Undecipherable) response and SHOULD send a valid certificate in that response. This is not always possible in practice for SIP MESSAGE requests. The UAS may choose not to decrypt a message until the user is ready to read it. Messages may be delivered to a message store or sent via a store-and-forward service. This document updates RFC 3261 to say that the UAS SHOULD return a SIP 493 response if it immediately attempts to decrypt the message and determines that the message was encrypted to the wrong certificate. However, it MAY return a 200-class response if decryption is deferred.
[RFC3261]第23.2节规定，如果收件人收到加密为错误证书的S/MIME正文，则必须返回SIP 493（不可解密）响应，并应在该响应中发送有效证书。对于SIP消息请求，这在实践中并不总是可能的。UAS可以选择在用户准备好阅读消息之前不解密消息。消息可以传递到消息存储或通过存储转发服务发送。本文档更新了RFC 3261，说明如果UAS立即尝试解密消息并确定消息加密到错误的证书，则应返回SIP 493响应。但是，如果延迟解密，它可能会返回200类响应。
MSRP has features that interact with the use of S/MIME. In particular, the ability to send messages in chunks, the ability to send messages of unknown size, and the use of SDP to indicate media-type support create considerations for the use of S/MIME.
MSRP具有与S/MIME的使用交互的功能。特别是，以块形式发送消息的能力、发送大小未知的消息的能力以及使用SDP指示媒体类型支持为使用S/MIME创建考虑事项。
MSRP allows a message to be broken into "chunks" for transmission. In this context, the term "message" refers to an entire message that one user might send to another. A chunk is a fragment of that message sent in a single MSRP SEND request. All of the chunks that make up a particular message share the same Message-ID value.
MSRP允许将消息分成“块”进行传输。在此上下文中，术语“消息”指的是一个用户可能发送给另一个用户的整个消息。区块是在单个MSRP发送请求中发送的消息的片段。组成特定消息的所有区块共享相同的消息ID值。
The sending UA may break a message into chunks, which the receiving UA will reassemble to form the complete message. Intermediaries such as MSRP relays [RFC4976] might break chunks into smaller chunks or might reassemble chunks into larger ones; therefore, the message received by the recipient may be broken into a different number of chunks than were sent by the recipient. Intermediaries might also cause chunks to be received in a different order than sent.
发送UA可以将消息分解成块，接收UA将重新组合以形成完整的消息。MSRP中继[RFC4976]等中介机构可能会将块分解成更小的块，或者可能会将块重新组合成更大的块；因此，收件人收到的消息可能被分成与收件人发送的消息不同数量的数据块。中介还可能导致块的接收顺序与发送顺序不同。
The sender MUST apply any S/MIME operations to the whole message prior to breaking it into chunks. Likewise, the receiver needs to reassemble the message from its chunks prior to decrypting, validating a signature, etc.
发送方必须对整个消息应用任何S/MIME操作，然后才能将其分块。同样，在解密、验证签名等之前，接收者需要从消息块重新组装消息。
MSRP chunks are framed using an end-line. The end-line comprises seven hyphens, a 64-bit random value taken from the start line, and a continuation flag. MSRP requires the sending UA to scan data to be sent in a specific chunk to ensure that the end-line does not accidentally occur as part of the data. This scanning occurs on a chunk rather than a whole message; consequently, it must occur after the sender applies any S/MIME operations.
MSRP块使用一条终点线进行框定。结束行包括七个连字符、一个从起始行获取的64位随机值和一个延续标志。MSRP要求发送UA扫描特定数据块中要发送的数据，以确保结束行不会作为数据的一部分意外出现。这种扫描发生在一个区块上，而不是整个消息上；因此，它必须在发送方应用任何S/MIME操作之后发生。
MSRP allows a mode of operation where a UA sends some chunks of a message prior to knowing the full length of the message. For example, a sender might send streamed data over MSRP as a single message, even though it doesn't know the full length of that data in advance. This mode is incompatible with S/MIME, since a sending UA must apply S/MIME operations to the entire message in advance of breaking it into chunks.
MSRP允许一种操作模式，即UA在知道消息的完整长度之前发送一些消息块。例如，发送方可以通过MSRP将流式数据作为单个消息发送，即使它事先不知道该数据的完整长度。此模式与S/MIME不兼容，因为发送UA必须在将整个消息分解为块之前对其应用S/MIME操作。
Therefore, when sending a message in an S/MIME format, the sender MUST include the Byte-Range header field for every chunk, including the first chunk. The Byte-Range header field MUST include the total length of the message.
因此，当以S/MIME格式发送消息时，发送方必须包含每个区块（包括第一个区块）的字节范围标头字段。字节范围标头字段必须包括消息的总长度。
A higher layer could choose to break such streamed data into a series of messages prior to applying S/MIME operations, so that each fragment appears as a distinct (separate) S/MIME message in MSRP. Such mechanisms are beyond the scope of this document.
在应用S/MIME操作之前，更高层可以选择将此类流数据分解为一系列消息，以便每个片段在MSRP中显示为一个不同的（单独的）S/MIME消息。这种机制超出了本文件的范围。
A UA that supports this specification MUST explicitly include the appropriate media type or types in the "accept-types" attribute in any SDP offer or answer that proposes MSRP. It MAY indicate that it requires S/MIME wrappers for all messages by putting appropriate S/MIME media types in the "accept-types" attribute and putting all other supported media types in the "accept-wrapped-types" attribute.
支持本规范的UA必须在提出MSRP的任何SDP报价或应答中的“接受类型”属性中明确包含适当的媒体类型。通过将适当的S/MIME媒体类型放在“接受类型”属性中，并将所有其他支持的媒体类型放在“接受包装类型”属性中，它可能表示需要对所有消息使用S/MIME包装器。
For backwards compatibility, a sender MAY treat a peer that includes an asterisk ("*") in the "accept-types" attribute as potentially supporting S/MIME. If the peer returns an MSRP 415 (MIME type not understood) response to an attempt to send an S/MIME message, the sender should treat the peer as not supporting S/MIME for the duration of the session, as indicated in Section 7.3.1 of [RFC4975].
为了向后兼容，发送方可以将“接受类型”属性中包含星号（“*”）的对等方视为可能支持S/MIME。如果对等方对发送S/MIME消息的尝试返回MSRP 415（MIME类型不可理解）响应，则发送方应将对等方视为在会话期间不支持S/MIME，如[RFC4975]第7.3.1节所示。
While these SDP attributes allow an endpoint to express support for certain media types only when wrapped in a specified envelope type, it does not allow the expression of more complex structures. For example, an endpoint can say that it supports text/plain and text/html, but only when inside an application/pkcs7 or message/cpim container, but it cannot express a requirement for the leaf types to always be contained in an application/pkcs7 container nested inside a message/cpim container. This has implications for the use of S/MIME with the message/cpim format. (See Section 9.1.)
虽然这些SDP属性允许端点仅在包装在指定的信封类型中时表示对某些媒体类型的支持，但不允许表示更复杂的结构。例如，端点可以说它支持text/plain和text/html，但仅在应用程序/pkcs7或消息/cpim容器内时才支持，但它不能表示叶类型始终包含在嵌套在消息/cpim容器内的应用程序/pkcs7容器中的要求。这对将S/MIME与message/cpim格式一起使用有影响。（见第9.1节。）
MSRP allows multiple reporting modes that provide different levels of feedback. If the sender includes a Failure-Report header field with a value of "no", it will not receive failure reports. This mode should not be used carelessly, since such a sender would never see a 415 response as described above and would have no way to learn that the recipient could not process an S/MIME body.
MSRP允许多种报告模式，提供不同级别的反馈。如果发送方包含值为“否”的故障报告标题字段，则它将不会接收故障报告。不应粗心地使用该模式，因为这样的发送方将永远不会看到如上所述的415响应，并且将无法得知接收方无法处理S/MIME主体。
MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to identify certificates or insert MSRP URIs into certificate Subject Alternative Name fields. When MSRP sessions are negotiated using SIP [RFC3261], the SIP AoRs of the peers are used instead.
MSRP URI是短暂的。端点不得使用MSRP URI来标识证书或将MSRP URI插入证书使用者备选名称字段。当使用SIP[RFC3261]协商MSRP会话时，将使用对等方的SIP AOR。
Note that MSRP allows messages to be sent between peers in either direction. A given MSRP message might be sent from the SIP offerer to the SIP answerer. Thus, the sender and recipient roles may reverse between one message and another in a given session.
请注意，MSRP允许在对等方之间以任意方向发送消息。给定的MSRP消息可能会从SIP提供方发送到SIP应答方。因此，发送者和接收者角色可以在给定会话中的一条消息和另一条消息之间反转。
Successful delivery of an S/MIME message does not indicate that the recipient successfully decrypted the contents or validated a signature. Decryption and/or validation may not occur immediately on receipt, since the recipient may not immediately view the message, and the UA may choose not to attempt decryption or validation until the user requests it.
成功传递S/MIME消息并不表示收件人成功解密了内容或验证了签名。解密和/或验证可能不会在接收时立即发生，因为接收者可能不会立即查看消息，并且UA可能选择在用户请求之前不尝试解密或验证。
Likewise, successful delivery of S/MIME enveloped data does not, on its own, indicate that the recipient supports the enclosed media type. If the peer only implicitly indicated support for the enclosed media type through the use of a wildcard in the "accept-types" or "accept-wrapped types" SDP attributes, it may not decrypt the message in time to send a 415 response.
同样，成功交付S/MIME封装数据本身并不表示收件人支持封装的媒体类型。如果对等方仅通过在“接受类型”或“接受包装类型”SDP属性中使用通配符来隐式指示对封闭媒体类型的支持，则其可能无法及时解密消息以发送415响应。
The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an abstract messaging service, with the goal of creating gateways between different messaging protocols that could relay instant messages without change. The SIP MESSAGE method and MSRP were initially designed to map to the CPIM abstractions. However, at the time of this writing, CPIM-compliant gateways have not been deployed. To the authors' knowledge, no other IM protocols have been explicitly mapped to CPIM.
即时消息通用配置文件（CPIM）[RFC3860]定义了一个抽象的消息服务，其目标是在不同的消息协议之间创建网关，该网关可以在不改变的情况下中继即时消息。SIP消息方法和MSRP最初设计为映射到CPIM抽象。但是，在撰写本文时，尚未部署符合CPIM的网关。据作者所知，没有其他IM协议明确映射到CPIM。
CPIM also defines the abstract messaging URI scheme "im:". As of the time of this writing, the "im:" scheme is not in common use.
CPIM还定义了抽象消息URI方案“im:”。截至撰写本文之时，“im:”方案还没有得到普遍使用。
The CPIM message format [RFC3862] allows UAs to attach transport-neutral metadata to arbitrary MIME content. The format was designed as a canonicalization format to allow signed data to cross protocol-converting gateways without loss of metadata needed to verify the signature. While it has not typically been used for that purpose, it has been used for other metadata applications -- for example, IMDNs [RFC5438] and MSRP multi-party chat [RFC7701].
CPIM消息格式[RFC3862]允许UAs将传输无关元数据附加到任意MIME内容。该格式被设计为规范化格式，以允许签名数据跨协议转换网关，而不会丢失验证签名所需的元数据。虽然它通常不用于此目的，但它已用于其他元数据应用程序，例如IMDNs[RFC5438]和MSRP多方聊天[RFC7701]。
In the general case, a sender applies end-to-end signature and encryption operations to the entire MIME body. However, some messaging systems expect to inspect and in some cases add or modify metadata in CPIM header fields. For example, CPM-based and RCS-based services include application servers that may need to insert timestamps into chat messages and may use additional metadata to characterize the content and purpose of a message to determine application behavior. The former will cause validation failure for
在一般情况下，发送方对整个MIME正文应用端到端签名和加密操作。但是，一些消息传递系统希望检查并在某些情况下添加或修改CPIM头字段中的元数据。例如，基于CPM和基于RCS的服务包括可能需要在聊天消息中插入时间戳的应用程序服务器，并且可能使用附加元数据来描述消息的内容和目的，以确定应用程序行为。前者将导致验证失败
signatures that cover CPIM metadata, while the latter is not possible if the metadata is encrypted. Clients intended for use in such networks MAY choose to apply end-to-end signatures and encryption operations to only the CPIM payload, leaving the CPIM metadata unprotected from inspection and modification. UAs that support S/MIME and CPIM SHOULD be able to validate signatures and decrypt enveloped data both (1) when those operations are applied to the entire CPIM body and (2) when they are applied to just the CPIM payload. This means that the receiver needs to be flexible in its MIME document parsing and that it cannot make assumptions that S/MIME-protected body parts will always be in the same position or level in the message payload.
包含CPIM元数据的签名，而如果对元数据进行加密，则无法使用后者。拟在此类网络中使用的客户端可选择仅对CPIM有效载荷应用端到端签名和加密操作，从而使CPIM元数据不受检查和修改的保护。支持S/MIME和CPIM的UAs应该能够验证签名并解密封装的数据（1）当这些操作应用于整个CPIM主体时，（2）当它们仅应用于CPIM有效负载时。这意味着接收方需要灵活地解析MIME文档，并且不能假设受S/MIME保护的主体部分在消息负载中始终处于相同的位置或级别。
If such clients need to encrypt or sign CPIM metadata end to end, they can nest a protected CPIM message format payload inside an unprotected CPIM message envelope.
如果此类客户端需要端到端加密或签署CPIM元数据，则可以将受保护的CPIM消息格式有效负载嵌套在未受保护的CPIM消息信封中。
The use of CPIM metadata fields to identify certificates or to authenticate SIP or MSRP header fields is out of scope for this document.
使用CPIM元数据字段来标识证书或验证SIP或MSRP头字段超出了本文档的范围。
The IMDN mechanism [RFC5438] allows both endpoints and intermediary application servers to request and to generate delivery notifications. The use of S/MIME does not impact strictly end-to-end use of IMDNs. The IMDN mechanism recommends that devices that are capable of doing so sign delivery notifications. It further requires that delivery notifications that result from encrypted messages also be encrypted.
IMDN机制[RFC5438]允许端点和中间应用程序服务器请求和生成传递通知。S/MIME的使用不会严格影响IMDNs的端到端使用。IMDN机制建议能够这样做的设备对传递通知进行签名。它还要求对加密邮件产生的传递通知也进行加密。
However, the IMDN mechanism allows intermediary application servers to insert notification requests into messages, to add routing information to messages, and to act on notification requests. It also allows list servers to aggregate delivery notifications.
但是，IMDN机制允许中间应用程序服务器将通知请求插入到消息中，向消息添加路由信息，并对通知请求采取行动。它还允许列表服务器聚合传递通知。
Such intermediaries will be unable to read end-to-end encrypted messages in order to interpret delivery notice requests. Intermediaries that insert information into end-to-end signed messages will cause the signature validation to fail. (See Section 9.1.)
这样的中介机构将无法读取端到端的加密消息以解释传递通知请求。将信息插入端到端签名消息的中介将导致签名验证失败。（见第9.1节。）
The following sections show examples of S/MIME messages in SIP and MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to denote binary content shown in hexadecimal. The tags are not part of the actual message and do not count towards the Content-Length header field values.
以下各节显示了SIP和MSRP中的S/MIME消息示例。示例包括标记“[start hex]”和“[end hex]”，以表示以十六进制显示的二进制内容。标记不是实际消息的一部分，并且不计入内容长度标头字段值。
In all of these examples, the cleartext message is the string "Watson, come here - I want to see you." followed by a newline character.
在所有这些示例中，明文消息都是字符串“Watson，过来-我要见你。”后跟一个换行符。
The cast of characters includes Alice, with a SIP AoR of "alice@example.com", and Bob, with a SIP AoR of "bob@example.org".
演员阵容中包括爱丽丝，她的SIP AoR为“alice@example.com，和鲍勃，喝了一小口bob@example.org".
Appendix A shows the detailed content of each S/MIME body.
附录A显示了每个S/MIME正文的详细内容。
Figure 1 shows a message signed by Alice. This body uses the "application/pkcs7-mime" media type with an smime-type parameter value of "signed-data".
图1显示了一条由Alice签名的消息。此正文使用“application/pkcs7 mime”媒体类型，smime类型参数值为“signed data”。
The S/MIME body includes Alice's signing certificate. Even though the original message content is fairly short and only minimal SIP header fields are included, the total message size approaches the maximum allowed for the SIP MESSAGE method unless the UAC has advance knowledge that all SIP hops will use congestion-controlled transport protocols. A message that included all the SIP header fields that are commonly in use in some SIP deployments would likely exceed the limit.
S/MIME正文包括Alice的签名证书。尽管原始消息内容相当短，并且只包含最小的SIP头字段，但总消息大小接近SIP消息方法允许的最大值，除非UAC事先知道所有SIP跳将使用拥塞控制传输协议。包含在某些SIP部署中常用的所有SIP头字段的消息可能会超出限制。
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 762
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 762
[start-hex] 308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 6d652068657265202d20492077616e7420746f2073656520796f752e0d0aa082 016b308201673082010da003020102020900b8793ec0e4c21530300a06082a86 48ce3d040302302631143012060355040a0c0b6578616d706c652e636f6d310e 300c06035504030c05416c696365301e170d3137313231393233313230355a17 0d3138313231393233313230355a302631143012060355040a0c0b6578616d70 6c652e636f6d310e300c06035504030c05416c6963653059301306072a8648ce 3d020106082a8648ce3d03010703420004d87b54729f2c22feebd9ddba0efa40 642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db fc0a4b91c953cbd022a751b914807bb794a324302230200603551d1104193017 86157369703a616c696365406578616d706c652e636f6d300a06082a8648ce3d 040302034800304502207879be1c27f846276fdf15e333e53c6f17a757388a02 cb7b8ae481c1641ae7a9022100ff99cd9c94076c82b02fea3b1350179a4b7752 e16fa30a3f9ab29650b0e2818931820109308201050201013033302631143012 060355040a0c0b6578616d706c652e636f6d310e300c06035504030c05416c69 6365020900b8793ec0e4c21530300b0609608648016503040201a06930180609 2a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d 010905310f170d3139303132363036313335345a302f06092a864886f70d0109 0431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a227adaf35fa22c 050d8d195a300a06082a8648ce3d04030204473045022005fdc2b55b0f444a46 be468dfc7ef3b7de30019ef0952a223e8521890b35bb4e02210090e43a9d9846 cf2af8159c5c0ef48848fa2f39f998b1bb99b52a6fc6c776f2c8 [end-hex]
[开始十六进制]308202F606092A864886F70D010702A08202E7308202E03020101310D300B0609 608648801503040201305306092A864886F70D010701A04604436F6E74656E 742D547970653A207474747742F706C61696E0A0D0A576174736F6D6520686572202D2049207616E74207460D0746F207365652076F752E0080AA082 B30808307810DA0030207080EC090E4080808080808648CE3D040303026311430120355040A0C0B6578616D706C652E636F6D310E 300C06035504030C05416C696365301E170D313731323139323331320355A17 0D313833231393233310355A3026311430112060355040A0C0B6578616D70 6C652E636F6D310E300C06035504030C005416C6965353059303013072A8648CE 3D02010060806082A2868CE03003420004D8747F22FEEBD9DD642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db FC0A4B91C953CBD022A751B914807B794A324302230200603551D11104193017 86157369703A616 C696365406578616D706C652E636F6D300A060822A8648CE3D 04030034800450220787BE1C27F8467FDF146275E333E536F17A57388A02 CB1007AE647A907B1707CF707B1707B775CF077B7952E16FA30A3F9AB2965B0E2818931820201093082010502001013033302631143012 060355040A0C0B6578616D706C652E636F6D310E300C06035504030C005416C69 6365020900B8793EC0E4C21530300B06096086480165030402001A06930180609 2A864886F70D010903310B06092A864886F70D01070136092A4886F70D 010905310F170D31390335133635A30860A090908A0909090908A4801908D010904312220420EF778FC940D5E6DC2576F47A599B3126195A9F1A227ADAF35FA22C 050D8D195A300A06082A8648CE3D0403004473045022005FDC2B55B0F44A46 BE468DFC7EF3B7DE30019EF0952A223E8521890B35BB4E022100E43A9D9846 CF2A159C5C0EF48848FA2F39F998BF8B998B52A6FC6C776F2C8[end hex]
Figure 1: Signed Message in SIP
图1:SIP中的签名消息
Figure 2 shows the same message from Alice without the embedded certificate. The shorter total message length may be more manageable.
图2显示了来自Alice的相同消息，但没有嵌入证书。较短的消息总长度可能更易于管理。
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 395
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 395
[start-hex] 3082018706092a864886f70d010702a082017830820174020101310d300b0609 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 6d652068657265202d20492077616e7420746f2073656520796f752e0d0a3182 0109308201050201013033302631143012060355040a0c0b6578616d706c652e 636f6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b 0609608648016503040201a069301806092a864886f70d010903310b06092a86 4886f70d010701301c06092a864886f70d010905310f170d3139303132363036 313335345a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576 f47a599b3126195a9f1a227adaf35fa22c050d8d195a300a06082a8648ce3d04 03020447304502203607275592d30c8c5a931041a01804d60c638ac9a8080918 87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcde16dd3e9 48d0f5f78a969e26382682 [end-hex]
[开始十六进制]3082018706092A864886F70D010702A0820178308201740200101310D300B0609 6086488016503040201305306092A864886F70D010701A04604436F6E74656E 742D547970653A20747474747472F706C61696E0A0A0A576174736F6E2C20636F 6D6520686572202D204920777616E7420746F2075652075652076F752E0D0A30109308201050133033114060506050607606E636F6D310E300C06035504030C005416C696365020900B8793EC0E4C21530300B 060960864864801503040201A69301806092A864886F70D010903310B06092A86 4886F70D010701301C06092A864886F70D010905310F170D31391363036 3133345A302F06092A864886F70D01090431420EF778FC940D5E6DC2576 F47A5990126A959A227ADA2505C00403020447304502203607275592D30C8C5A931041A01804D60C638AC9A080918 87172A0887C8D4AA022100CD9E14BD21817336E9052FE590AF2BCDE16DD3E9 48d0f5f78a969e26382682[端部六角]
Figure 2: Signed Message in SIP with No Certificate Included
图2:SIP中未包含证书的已签名消息
Figure 3 shows a signed and encrypted message from Bob to Alice sent via MSRP.
图3显示了通过MSRP从Bob发送给Alice的经过签名和加密的消息。
MSRP dsdfoe38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-1940/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=auth-enveloped-data;
name="smime.p7m"
MSRP dsdfoe38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-1940/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=auth-enveloped-data;
name="smime.p7m"
[start-hex]
30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
06096086480165030401063011040c4d8757222eac5294117f0c120201108082
04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
[start-hex]
30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
06096086480165030401063011040c4d8757222eac5294117f0c120201108082
04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
a8db0410f6ffc6e1aef19cd23d985a921976352d
[end-hex]
-------dsdfoe38sd$
1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
a8db0410f6ffc6e1aef19cd23d985a921976352d
[end-hex]
-------dsdfoe38sd$
Figure 3: Signed and Encrypted Message in MSRP
图3：MSRP中的签名和加密消息
Figure 4 shows the same message as in Figure 3 except that the message is broken into two chunks. The S/MIME operations were performed prior to breaking the message into chunks.
图4显示了与图3相同的消息，只是消息被分为两个块。S/MIME操作是在将消息分块之前执行的。
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-960/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-960/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
06096086480165030401063011040c4d8757222eac5294117f0c120201108082
04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
[end-hex]
-------d93kswow+
[start-hex]
30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
06096086480165030401063011040c4d8757222eac5294117f0c120201108082
04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
[end-hex]
-------d93kswow+
MSRP op2nc9a SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 961-1940/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
MSRP op2nc9a SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 961-1940/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
a8db0410f6ffc6e1aef19cd23d985a921976352d
[end-hex]
-------op2nc9a$
[start-hex]
f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
a8db0410f6ffc6e1aef19cd23d985a921976352d
[end-hex]
-------op2nc9a$
Figure 4: Signed, Encrypted, and Chunked MSRP Message
图4：签名、加密和分块的MSRP消息
This document has no IANA actions.
本文档没有IANA操作。
The security considerations for S/MIME [RFC8550] [RFC8551] and elliptic curves in CMS [RFC5753] apply. The S/MIME-related security considerations for SIP [RFC3261], SIP MESSAGE [RFC3428], and MSRP [RFC4975] apply.
CMS[RFC5753]中S/MIME[RFC8550][RFC8551]和椭圆曲线的安全注意事项适用。SIP[RFC3261]、SIP消息[RFC3428]和MSRP[RFC4975]的S/MIME相关安全注意事项适用。
The security considerations for algorithms recommended in this document also apply; see [RFC3565], [RFC5480], [RFC5753], [RFC5754], [RFC7748], [RFC8032], [RFC8418], and [RFC8419].
本文件中推荐的算法的安全注意事项也适用；参见[RFC3565]、[RFC5480]、[RFC5753]、[RFC5754]、[RFC7748]、[RFC8032]、[RFC8418]和[RFC8419]。
This document assumes that end-entity certificate validation is provided by a chain of trust to a certification authority (CA), using a public key infrastructure. The security considerations from [RFC5280] apply. However, other validations methods may be possible -- for example, sending a signed fingerprint for the end entity in SDP. The relationship between this work and the techniques discussed in [RFC8224] and [RTP-Sec] are out of scope for this document.
本文档假设最终实体证书验证是通过使用公钥基础设施由对证书颁发机构（CA）的信任链提供的。[RFC5280]中的安全注意事项适用。但是，也可以使用其他验证方法——例如，在SDP中为最终实体发送签名指纹。这项工作与[RFC8224]和[RTP Sec]中讨论的技术之间的关系超出了本文档的范围。
When matching an end-entity certificate to the sender or recipient identity, the respective SIP AoRs are used. Typically, these will match the SIP From and To header fields. Some UAs may extract the sender identity from SIP AoRs in other header fields -- for example, P-Asserted-Identity [RFC3325]. In general, the UAS should compare the certificate to the identity that it relies upon -- for example, for display to the end user or comparison against message-filtering rules.
将终端实体证书与发送方或接收方身份匹配时，将使用相应的SIP AOR。通常，这些字段将匹配SIP From和To头字段。一些UAs可以从其他报头字段中的SIP AOR中提取发送方标识——例如，P-Asserted-identity[RFC3325]。一般来说，UAS应该将证书与它所依赖的身份进行比较——例如，用于向最终用户显示或与消息过滤规则进行比较。
The secure notification use case discussed in Section 1 has significant vulnerabilities when used in an insecure environment. For example, "phishing" messages could be used to trick users into revealing credentials. Eavesdroppers could learn confirmation codes from unprotected two-factor authentication messages. Unsolicited messages sent by impersonators could tarnish the reputation of an organization. While hop-by-hop protection can mitigate some of those risks, it still leaves messages vulnerable to malicious or compromised intermediaries. End-to-end protection prevents modification by intermediaries. However, neither provides much protection unless the recipient knows to expect messages from a particular sender to be signed and refuses to accept unsigned messages that appear to be from that source.
第1节中讨论的安全通知用例在不安全环境中使用时存在严重漏洞。例如，“网络钓鱼”消息可以用来欺骗用户泄露凭据。窃听者可以从未受保护的双因素身份验证消息中学习确认码。冒名顶替者发送的未经请求的消息可能会损害组织的声誉。虽然逐跳保护可以减轻其中一些风险，但它仍然会使消息容易受到恶意或受损中介的攻击。端到端保护可防止中介进行修改。但是，这两种方法都不能提供太多的保护，除非收件人知道来自某个特定发件人的邮件需要签名，并且拒绝接受似乎来自该发件人的未签名邮件。
Mobile messaging is typically an online application; online certificate revocation checks should usually be feasible.
移动消息通常是一种在线应用程序；在线证书撤销检查通常是可行的。
S/MIME does not normally protect the SIP or MSRP headers. While it normally does protect the CPIM header, certain CPIM header fields may not be protected if the sender excludes them from the encrypted or signed part of the message. (See Section 9.1.) Certain messaging services -- for example, those based on RCS -- may include intermediaries that attach metadata to user-generated messages in the form of SIP, MSRP, or CPIM header fields. This metadata could possibly reveal information to third parties that the sender might
S/MIME通常不保护SIP或MSRP头。虽然它通常会保护CPIM头，但如果发件人将某些CPIM头字段从消息的加密或签名部分排除，则这些字段可能不会受到保护。（参见第9.1节。）某些消息传递服务（例如，基于RCS的服务）可能包括将元数据以SIP、MSRP或CPIM头字段的形式附加到用户生成的消息的中介。此元数据可能会向第三方透露发送方可能提供的信息
prefer not to send as cleartext. Implementors and operators should consider whether inserted metadata may create privacy leaks. Such an analysis is beyond the scope of this document.
不希望以明文形式发送。实现者和运营商应该考虑插入的元数据是否可能造成隐私泄漏。这种分析超出了本文件的范围。
MSRP messages broken into chunks must be reassembled by the recipient prior to decrypting or validation of signatures. (See Section 8.1.) Section 14.5 of [RFC4975] describes a potential denial-of-service attack where the attacker puts large values in the Byte-Range header field. Implementations should sanity-check these values before allocating memory space for reassembly.
在解密或验证签名之前，MSRP消息必须由收件人重新组合成块。（参见第8.1节）。[RFC4975]第14.5节描述了一种潜在的拒绝服务攻击，攻击者在字节范围标头字段中输入大值。在为重新组装分配内存空间之前，实现应该检查这些值。
Modification of the ciphertext in EnvelopedData can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it. This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData, as the authenticated encryption algorithms provide the authentication without needing the SignedData layer.
如果未使用身份验证，则信封数据中的密文修改可能无法被检测到，这是在发送信封数据时没有将其包装在SignedData中或将SignedData封装在其中的情况。这是从EnvelopedData移动到AuthEnvelopedData的原因之一，因为经过身份验证的加密算法提供身份验证而不需要SignedData层。
An attack on S/MIME implementations of HTML and multipart/mixed messages is highlighted in [Efail]. To avoid this attack, clients MUST ensure that a text/html content type is a complete HTML document. Clients SHOULD treat each of the different pieces of the multipart/mixed construct as coming from different origins. Clients MUST treat each encrypted or signed piece of a MIME message as being from different origins both from unprotected content and from each other.
[Efail]中突出显示了对HTML和多部分/混合消息的S/MIME实现的攻击。为了避免这种攻击，客户端必须确保文本/html内容类型是完整的html文档。客户端应将多部分/混合构造的每个不同部分视为来自不同的来源。客户端必须将MIME消息的每个加密或签名部分视为来自不同的来源，既来自未受保护的内容，也来自彼此。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<https://www.rfc-editor.org/info/rfc3264>.
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, DOI 10.17487/RFC3428, December 2002, <https://www.rfc-editor.org/info/rfc3428>.
[RFC3428]Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 3428，DOI 10.17487/RFC3428，2002年12月<https://www.rfc-editor.org/info/rfc3428>.
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.
[RFC3565]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，DOI 10.17487/RFC3565，2003年7月<https://www.rfc-editor.org/info/rfc3565>.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, DOI 10.17487/RFC3853, July 2004, <https://www.rfc-editor.org/info/rfc3853>.
[RFC3853]Peterson，J.，“会话启动协议（SIP）的S/MIME高级加密标准（AES）要求”，RFC 3853，DOI 10.17487/RFC3853，2004年7月<https://www.rfc-editor.org/info/rfc3853>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<https://www.rfc-editor.org/info/rfc4566>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 4975，DOI 10.17487/RFC4975，2007年9月<https://www.rfc-editor.org/info/rfc4975>.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, <https://www.rfc-editor.org/info/rfc5084>.
[RFC5084]Housley，R.，“在加密消息语法（CMS）中使用AES-CCM和AES-GCM认证加密”，RFC 5084，DOI 10.17487/RFC5084，2007年11月<https://www.rfc-editor.org/info/rfc5084>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 5480，DOI 10.17487/RFC5480，2009年3月<https://www.rfc-editor.org/info/rfc5480>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5753]Turner，S.和D.Brown，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 5753，DOI 10.17487/RFC5753，2010年1月<https://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC5754]Turner，S.，“使用具有加密消息语法的SHA2算法”，RFC 5754，DOI 10.17487/RFC5754，2010年1月<https://www.rfc-editor.org/info/rfc5754>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", RFC 8418, DOI 10.17487/RFC8418, August 2018, <https://www.rfc-editor.org/info/rfc8418>.
[RFC8418]Housley，R.，“在加密消息语法（CMS）中使用带有X25519和X448的椭圆曲线Diffie-Hellman密钥协商算法”，RFC 8418，DOI 10.17487/RFC8418，2018年8月<https://www.rfc-editor.org/info/rfc8418>.
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, <https://www.rfc-editor.org/info/rfc8419>.
[RFC8419]Housley，R.，“在加密消息语法（CMS）中使用爱德华兹曲线数字签名算法（EdDSA）签名”，RFC 8419，DOI 10.17487/RFC8419，2018年8月<https://www.rfc-editor.org/info/rfc8419>.
[RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, April 2019, <https://www.rfc-editor.org/info/rfc8550>.
[RFC8550]Schaad，J.，Ramsdell，B.，和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本4.0证书处理”，RFC 8550，DOI 10.17487/RFC8550，2019年4月<https://www.rfc-editor.org/info/rfc8550>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551]Schaad，J.，Ramsdell，B.，和S.Turner，“安全/多用途互联网邮件扩展（S/MIME）版本4.0消息规范”，RFC 8551，DOI 10.17487/RFC8551，2019年4月<https://www.rfc-editor.org/info/rfc8551>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680>.
[X680]ITU-T，“信息技术——抽象语法符号一（ASN.1）：基本符号规范”，ITU-T建议X.680，ISO/IEC 8824-12015年8月<https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/>.
[X690]ITU-T，“信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-12015年8月<https://www.itu.int/rec/T-REC-X.690/>.
[CPM] Open Mobile Alliance, "OMA Converged IP Messaging System Description, Candidate Version 2.2", September 2017.
[CPM]开放移动联盟，“OMA融合IP消息系统说明，候选版本2.2”，2017年9月。
[Efail] Poddebniak, D., Dresen, C., Muller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", August 2018, <https://www.usenix.org/system/files/conference/ usenixsecurity18/sec18-poddebniak.pdf>.
[Efail]Poddebniak，D.，Dresen，C.，Muller，J.，Ising，F.，Schinzel，S.，Friedberger，S.，Somorovsky，J.，和J.Schwenk，“Efail:使用Exfilter通道破坏S/MIME和OpenPGP电子邮件加密”，2018年8月<https://www.usenix.org/system/files/conference/ 请使用nixsecurity18/sec18 poddebniak.pdf>。
[RCS] GSMA, "RCS Universal Profile Service Definition Document, Version 2.2", May 2018, <https://www.gsma.com/futurenetworks/wp-content/uploads/2018/05/ Universal-Profile-RCC.71-v2.2.pdf>.
[RCS]GSMA，“RCS通用配置文件服务定义文件，版本2.2”，2018年5月<https://www.gsma.com/futurenetworks/wp-content/uploads/2018/05/ 通用配置文件RCC.71-v2.2.pdf>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<https://www.rfc-editor.org/info/rfc3325>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <https://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<https://www.rfc-editor.org/info/rfc3840>.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, <https://www.rfc-editor.org/info/rfc3860>.
[RFC3860]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC 3860，DOI 10.17487/RFC3860，2004年8月<https://www.rfc-editor.org/info/rfc3860>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <https://www.rfc-editor.org/info/rfc3862>.
[RFC3862]Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，DOI 10.17487/RFC3862，2004年8月<https://www.rfc-editor.org/info/rfc3862>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <https://www.rfc-editor.org/info/rfc4976>.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 4976，DOI 10.17487/RFC4976，2007年9月<https://www.rfc-editor.org/info/rfc4976>.
[RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, February 2009, <https://www.rfc-editor.org/info/rfc5438>.
[RFC5438]Burger，E.和H.Khartabil，“即时消息处置通知（IMDN）”，RFC 5438，DOI 10.17487/RFC5438，2009年2月<https://www.rfc-editor.org/info/rfc5438>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <https://www.rfc-editor.org/info/rfc6121>.
[RFC6121]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 6121DOI 10.17487/RFC6121，2011年3月<https://www.rfc-editor.org/info/rfc6121>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<https://www.rfc-editor.org/info/rfc7516>.
[RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, <https://www.rfc-editor.org/info/rfc7701>.
[RFC7701]Niemi，A.，Garcia Martin，M.，和G.Sandbakken，“使用消息会话中继协议（MSRP）的多方聊天”，RFC 7701，DOI 10.17487/RFC7701，2015年12月<https://www.rfc-editor.org/info/rfc7701>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748]兰利，A.，汉堡，M.和S.特纳，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032]Josefsson，S.和I.Liusvaara，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<https://www.rfc-editor.org/info/rfc8032>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.
[RFC8224]Peterson，J.，Jennings，C.，Rescorla，E.，和C.Wendt，“会话启动协议（SIP）中的身份验证管理”，RFC 8224，DOI 10.17487/RFC82242018年2月<https://www.rfc-editor.org/info/rfc8224>.
[RTP-Sec] Peterson, J., Barnes, R., and R. Housley, "Best Practices for Securing RTP Media Signaled with SIP", Work in Progress, draft-ietf-sipbrandy-rtpsec-08, April 2019.
[RTP Sec]Peterson，J.，Barnes，R.，和R.Housley，“用SIP信号保护RTP媒体的最佳实践”，正在进行的工作，草案-ietf-sipbrandy-rtpsec-082019年4月。
The following section shows the detailed content of the S/MIME bodies used in Section 10.
下一节显示了第10节中使用的S/MIME主体的详细内容。
Figure 5 shows the details of the message signed by Alice used in the example in Section 10.1.
图5显示了第10.1节示例中使用的Alice签名的消息的详细信息。
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 13292724773353297200
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.com, CN=Alice
validity:
notBefore: Dec 19 23:12:05 2017 GMT
notAfter: Dec 19 23:12:05 2018 GMT
subject: O=example.com, CN=Alice
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"......
000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8......
001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d
002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S..
0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{..
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 13292724773353297200
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.com, CN=Alice
validity:
notBefore: Dec 19 23:12:05 2017 GMT
notAfter: Dec 19 23:12:05 2018 GMT
subject: O=example.com, CN=Alice
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"......
000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8......
001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d
002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S..
0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{..
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: BOOL ABSENT
value:
0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice
000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 20 78 79 be 1c-27 f8 46 27 6f df 15 0E. xy..'.F'o..
000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a e4 .3.<o..W8...{..
001e - 81 c1 64 1a e7 a9 02 21-00 ff 99 cd 9c 94 07 ..d....!.......
002d - 6c 82 b0 2f ea 3b 13 50-17 9a 4b 77 52 e1 6f l../.;.P..KwR.o
003c - a3 0a 3f 9a b2 96 50 b0-e2 81 89 ..?...P....
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: BOOL ABSENT
value:
0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice
000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 20 78 79 be 1c-27 f8 46 27 6f df 15 0E. xy..'.F'o..
000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a e4 .3.<o..W8...{..
001e - 81 c1 64 1a e7 a9 02 21-00 ff 99 cd 9c 94 07 ..d....!.......
002d - 6c 82 b0 2f ea 3b 13 50-17 9a 4b 77 52 e1 6f l../.;.P..KwR.o
003c - a3 0a 3f 9a b2 96 50 b0-e2 81 89 ..?...P....
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 20 58 79 cc 62-85 e0 86 06 19 d3 bf 0E. Xy.b.......
000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b S.g..s.E .V..U[
001e - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d {.a.r..!...SD(M
002d - 4c ef de 31 07 9c f9 71-bd 69 5d 6e c8 71 e9 L..1...q.i]n.q.
003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d .`...e+w.bM
unsignedAttrs:
<ABSENT>
signature:
0000 - 30 45 02 20 58 79 cc 62-85 e0 86 06 19 d3 bf 0E. Xy.b.......
000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b S.g..s.E .V..U[
001e - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d {.a.r..!...SD(M
002d - 4c ef de 31 07 9c f9 71-bd 69 5d 6e c8 71 e9 L..1...q.i]n.q.
003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d .`...e+w.bM
unsignedAttrs:
<ABSENT>
Figure 5: Signed Message
图5：签名消息
Figure 6 shows the message signed by Alice with no embedded certificate, as used in the example in Section 10.2.
图6显示了由Alice签名且没有嵌入证书的消息，如第10.2节中的示例所示。
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
<ABSENT>
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
<ABSENT>
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 44 02 20 1c 51 6e ed-9c 10 10 a2 87 e1 11 0D. .Qn........
000f - 6b af 76 1d f1 c4 e6 48-da ea 17 89 bc e2 8a k.v....H.......
001e - 9d 8a f4 a4 ae f9 02 20-72 7f 5e 4b cc e2 0b ....... r.^K...
002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 e0 f6 a0 .<.....d.!.p...
003c - 96 2e 0a 7b 19 b7 42 ad-cb 34 ...{..B..4
unsignedAttrs:
<ABSENT>
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 44 02 20 1c 51 6e ed-9c 10 10 a2 87 e1 11 0D. .Qn........
000f - 6b af 76 1d f1 c4 e6 48-da ea 17 89 bc e2 8a k.v....H.......
001e - 9d 8a f4 a4 ae f9 02 20-72 7f 5e 4b cc e2 0b ....... r.^K...
002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 e0 f6 a0 .<.....d.!.p...
003c - 96 2e 0a 7b 19 b7 42 ad-cb 34 ...{..B..4
unsignedAttrs:
<ABSENT>
Figure 6: Signed Message without Embedded Certificate
图6：没有嵌入证书的签名消息
The following sections show details for the message signed by Bob and encrypted to Alice, as used in the examples in Sections 10.3 and 10.4.
以下各节显示了由Bob签名并向Alice加密的消息的详细信息，如第10.3节和第10.4节中的示例所示。
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 11914627415941064473
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.org, CN=Bob
validity:
notBefore: Dec 20 23:07:49 2017 GMT
notAfter: Dec 20 23:07:49 2018 GMT
subject: O=example.org, CN=Bob
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~'
000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;..
001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7..
002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o
0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H....
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: TRUE
value:
0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e
000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8..
000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04
001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q..
002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6
003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG...
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.org, CN=Bob
serialNumber: 11914627415941064473
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 11914627415941064473
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.org, CN=Bob
validity:
notBefore: Dec 20 23:07:49 2017 GMT
notAfter: Dec 20 23:07:49 2018 GMT
subject: O=example.org, CN=Bob
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~'
000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;..
001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7..
002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o
0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H....
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: TRUE
value:
0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e
000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8..
000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04
001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q..
002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6
003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG...
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.org, CN=Bob
serialNumber: 11914627415941064473
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 21 00 f7 88 ed-44 6a b7 0f ff 2c 1f 0E.!....Dj...,.
000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3 .L.t..w.a..|1E.
001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00 ..v..F.. w.....
002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4 a...a#.nT...e..
003c - cc 12 99 76 a6 b1 fc 6d-bc 28 d6 ...v...m.(.
unsignedAttrs:
<ABSENT>
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 21 00 f7 88 ed-44 6a b7 0f ff 2c 1f 0E.!....Dj...,.
000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3 .L.t..w.a..|1E.
001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00 ..v..F.. w.....
002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4 a...a#.nT...e..
003c - cc 12 99 76 a6 b1 fc 6d-bc 28 d6 ...v...m.(.
unsignedAttrs:
<ABSENT>
Figure 7: Message Signed by Bob prior to Encryption
图7：加密前由Bob签名的消息
CMS_ContentInfo:
contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23)
d.authEnvelopedData:
version: 0
originatorInfo: <ABSENT>
recipientInfos:
d.ktri:
version: <ABSENT>
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 9508519069068149774
keyEncryptionAlgorithm:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
CMS_ContentInfo:
contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23)
d.authEnvelopedData:
version: 0
originatorInfo: <ABSENT>
recipientInfos:
d.ktri:
version: <ABSENT>
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 9508519069068149774
keyEncryptionAlgorithm:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
encryptedKey:
0000 - 75 9a 61 b4 dd f1 f1 af-24 66 80 05 63 5e 47 u.a.....$f..c^G
000f - 61 10 fa 27 23 c1 b9 e4-54 84 b6 d3 3e 83 87 a..'#...T...>..
001e - de 96 7d c5 e0 ca fb 35-57 1a 56 a1 97 5c b5 ..}....5W.V..\.
002d - 50 e7 be 31 c1 31 da 80-fb 73 10 24 84 5b ab P..1.1...s.$.[.
003c - b8 d6 4c ac 26 04 04 24-d9 33 05 61 c8 43 99 ..L.&..$.3.a.C.
004b - 94 15 dd 64 4b 3c ad 95-07 2f 71 45 13 93 c9 ...dK<.../qE...
005a - 9f 28 2c 48 83 bd 0c cc-5d d5 4b 93 14 64 e0 .(,H....].K..d.
0069 - 0a 6e 55 e5 92 c5 1a 68-de 10 62 51 6e c7 d3 .nU....h..bQn..
0078 - ca 8e 76 4b b8 ac 78 9a-88 37 77 65 ef 8d c3 ..vK..x..7we...
0087 - 6c 0a 6e d3 ec ae 52 85-ca c6 a2 9d 50 59 44 l.n...R.....PYD
0096 - 57 19 a1 bd cf 90 6e 0f-f3 7e 2c 2e f0 f4 ec W.....n..~,....
00a5 - 62 25 10 0c c0 62 e1 c7-48 96 3b bc 88 b8 e3 b%...b..H.;....
00b4 - df cf 71 40 73 72 9d d5-c7 58 3e 75 8a cf 3d ..q@sr...X>u..=
00c3 - 18 6f 2f a4 17 be 22 c3-7c 9a 76 c6 b4 27 29 .o/...".|.v..')
00d2 - aa d2 7f 73 ae 44 ac 98-47 4d 1e eb 48 94 8c ...s.D..GM..H..
00e1 - 12 a4 03 d0 b3 ce 08 a2-18 d6 af 45 69 24 89 ...........Ei$.
00f0 - 7c c5 c9 66 4f 6d fe b3-f1 81 41 15 8d fc 3b |..fOm....A...;
00ff - 84 09 0a a6 03 80 aa 86-51 37 e1 69 9c 5c 81 ........Q7.i.\.
010e - 97 41 67 9d 7a 3c 90 ba-79 e6 d7 d5 c8 d8 9b .Ag.z<..y......
011d - b5 4a 66 74 23 e4 3b 0b-7d 6f 78 c0 b4 ab 67 .Jft#.;.}ox...g
012c - bc 34 36 62 a6 35 fe 59-5f 11 49 c5 39 50 ca .46b.5.Y_.I.9P.
013b - c2 e0 ba 31 8c 22 7e 6f-76 a8 d9 40 40 0f d3 ...1."~ov..@@..
014a - d3 ea 1c 8e ce a0 03 dc-ce 2f 1f b0 0f 5c ea ........./...\.
0159 - 33 5d e1 30 3f cb f9 3d-8e 1c bf d6 82 f1 9b 3].0?..=.......
0168 - eb 62 4b ac d1 d7 b8 f5-80 f1 14 a1 3b 89 08 .bK.........;..
0177 - 94 fb 40 44 a5 da a7 64-b7 f8 c5 ff 92 94 94 ..@D...d.......
0186 - 52 b3 5a eb 96 39 b8 ad-63 c0 51 5c 95 cc c6 R.Z..9..c.Q\...
0195 - f8 23 c2 20 10 67 ea 22-62 41 3f ef 39 7d 48 .#. .g."bA?.9}H
01a4 - f7 b6 14 3f 84 2a e8 e1-a4 8c ad 3a e0 1a ba ...?.*.....:...
01b3 - a3 cf 9e e7 e3 66 20 e0-5c ca 06 11 bf ac 00 .....f .\......
01c2 - ee f1 a4 98 f2 d2 59 b9-f0 f7 da 83 ef 6f 1b ......Y......o.
01d1 - 06 1f 38 7c 2d c4 8c 8b-5d ba ca 86 23 08 f3 ..8|-...]...#..
01e0 - 2f 47 92 51 65 c9 e5 eb-b4 67 79 98 84 91 8d /G.Qe....gy....
01ef - d6 97 b4 47 f4 c4 07 98-9b 88 9b 0c 2e 95 80 ...G...........
01fe - af 78 .x
authEncryptedContentInfo:
contentType: pkcs7-data (1.2.840.113549.1.7.1)
contentEncryptionAlgorithm:
algorithm: aes-128-gcm (2.16.840.1.101.3.4.1.6)
parameter:
aes-nonce:
0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 M.W"..R.....
aes-ICVlen: 16
encryptedContent:
0000 - fe 2f b3 de 0b f0 69 98-c3 9b f4 a9 52 fa bf ./....i.....R..
000f - 8b 0f ee 3d 7e 2e 85 18-1a ec f1 a8 9e 1a 2e ...=~..........
001e - de cd 94 04 88 56 12 df-c6 98 43 34 d8 60 2b .....V....C4..+
encryptedKey:
0000 - 75 9a 61 b4 dd f1 f1 af-24 66 80 05 63 5e 47 u.a.....$f..c^G
000f - 61 10 fa 27 23 c1 b9 e4-54 84 b6 d3 3e 83 87 a..'#...T...>..
001e - de 96 7d c5 e0 ca fb 35-57 1a 56 a1 97 5c b5 ..}....5W.V..\.
002d - 50 e7 be 31 c1 31 da 80-fb 73 10 24 84 5b ab P..1.1...s.$.[.
003c - b8 d6 4c ac 26 04 04 24-d9 33 05 61 c8 43 99 ..L.&..$.3.a.C.
004b - 94 15 dd 64 4b 3c ad 95-07 2f 71 45 13 93 c9 ...dK<.../qE...
005a - 9f 28 2c 48 83 bd 0c cc-5d d5 4b 93 14 64 e0 .(,H....].K..d.
0069 - 0a 6e 55 e5 92 c5 1a 68-de 10 62 51 6e c7 d3 .nU....h..bQn..
0078 - ca 8e 76 4b b8 ac 78 9a-88 37 77 65 ef 8d c3 ..vK..x..7we...
0087 - 6c 0a 6e d3 ec ae 52 85-ca c6 a2 9d 50 59 44 l.n...R.....PYD
0096 - 57 19 a1 bd cf 90 6e 0f-f3 7e 2c 2e f0 f4 ec W.....n..~,....
00a5 - 62 25 10 0c c0 62 e1 c7-48 96 3b bc 88 b8 e3 b%...b..H.;....
00b4 - df cf 71 40 73 72 9d d5-c7 58 3e 75 8a cf 3d ..q@sr...X>u..=
00c3 - 18 6f 2f a4 17 be 22 c3-7c 9a 76 c6 b4 27 29 .o/...".|.v..')
00d2 - aa d2 7f 73 ae 44 ac 98-47 4d 1e eb 48 94 8c ...s.D..GM..H..
00e1 - 12 a4 03 d0 b3 ce 08 a2-18 d6 af 45 69 24 89 ...........Ei$.
00f0 - 7c c5 c9 66 4f 6d fe b3-f1 81 41 15 8d fc 3b |..fOm....A...;
00ff - 84 09 0a a6 03 80 aa 86-51 37 e1 69 9c 5c 81 ........Q7.i.\.
010e - 97 41 67 9d 7a 3c 90 ba-79 e6 d7 d5 c8 d8 9b .Ag.z<..y......
011d - b5 4a 66 74 23 e4 3b 0b-7d 6f 78 c0 b4 ab 67 .Jft#.;.}ox...g
012c - bc 34 36 62 a6 35 fe 59-5f 11 49 c5 39 50 ca .46b.5.Y_.I.9P.
013b - c2 e0 ba 31 8c 22 7e 6f-76 a8 d9 40 40 0f d3 ...1."~ov..@@..
014a - d3 ea 1c 8e ce a0 03 dc-ce 2f 1f b0 0f 5c ea ........./...\.
0159 - 33 5d e1 30 3f cb f9 3d-8e 1c bf d6 82 f1 9b 3].0?..=.......
0168 - eb 62 4b ac d1 d7 b8 f5-80 f1 14 a1 3b 89 08 .bK.........;..
0177 - 94 fb 40 44 a5 da a7 64-b7 f8 c5 ff 92 94 94 ..@D...d.......
0186 - 52 b3 5a eb 96 39 b8 ad-63 c0 51 5c 95 cc c6 R.Z..9..c.Q\...
0195 - f8 23 c2 20 10 67 ea 22-62 41 3f ef 39 7d 48 .#. .g."bA?.9}H
01a4 - f7 b6 14 3f 84 2a e8 e1-a4 8c ad 3a e0 1a ba ...?.*.....:...
01b3 - a3 cf 9e e7 e3 66 20 e0-5c ca 06 11 bf ac 00 .....f .\......
01c2 - ee f1 a4 98 f2 d2 59 b9-f0 f7 da 83 ef 6f 1b ......Y......o.
01d1 - 06 1f 38 7c 2d c4 8c 8b-5d ba ca 86 23 08 f3 ..8|-...]...#..
01e0 - 2f 47 92 51 65 c9 e5 eb-b4 67 79 98 84 91 8d /G.Qe....gy....
01ef - d6 97 b4 47 f4 c4 07 98-9b 88 9b 0c 2e 95 80 ...G...........
01fe - af 78 .x
authEncryptedContentInfo:
contentType: pkcs7-data (1.2.840.113549.1.7.1)
contentEncryptionAlgorithm:
algorithm: aes-128-gcm (2.16.840.1.101.3.4.1.6)
parameter:
aes-nonce:
0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 M.W"..R.....
aes-ICVlen: 16
encryptedContent:
0000 - fe 2f b3 de 0b f0 69 98-c3 9b f4 a9 52 fa bf ./....i.....R..
000f - 8b 0f ee 3d 7e 2e 85 18-1a ec f1 a8 9e 1a 2e ...=~..........
001e - de cd 94 04 88 56 12 df-c6 98 43 34 d8 60 2b .....V....C4..+
002d - 77 49 b2 50 4e 45 f5 7c-3b 06 66 26 b0 fc 74 wI.PNE.|..f&..t
003c - 62 36 1e ec 26 7c 56 01-39 be 5c d2 86 a2 af b6..&|V.9.\....
004b - 96 96 cf 51 85 22 78 e5-2c 38 18 ca b0 a6 8c ...Q."x.,8.....
005a - 59 8d e4 fc e1 4a 33 38-84 e4 de 5d df 57 ed Y....J38...].W.
0069 - d7 88 67 02 7a 31 e4 a7-c0 c0 29 91 44 c5 de ..g.z1....).D..
0078 - 6b ae 39 69 9e 70 0e 05-7e b0 f0 da d7 3b 8b k.9i.p..~......
0087 - 36 9f 42 eb 32 1b 41 53-87 81 d9 82 a1 1a 0b 6.B.2.AS.......
0096 - 39 43 ac 10 c9 7b 54 ee-b7 3b 38 ec 13 1a fc 9C...{T...8....
00a5 - 56 10 e3 73 48 72 74 d6-9c af a9 54 19 02 88 V..sHrt....T...
00b4 - 6c 64 f6 96 2d 42 eb 33-f9 04 1a 4a e1 1b 88 ld..-B.3...J...
00c3 - dc 69 58 d5 3d f5 0b 8b-b5 2a a3 5e 22 99 88 .iX.=....*.^"..
00d2 - 5d 0a ae 41 6b 86 f0 a8-8d 0e b7 a9 81 db b2 ]..Ak..........
00e1 - 83 e8 b9 4e 9d 50 bf 62-65 c2 34 8a 18 a1 69 ...N.P.be.4...i
00f0 - aa cb 5a 37 a5 29 bd a2-f9 cb 10 ef dd cf 14 ..Z7.).........
00ff - 23 10 95 d8 79 64 63 7b-d3 3f b1 3c 68 b4 cf #...ydc{.?.<h..
010e - f9 a1 90 69 60 c1 ea 23-01 d3 25 b7 a1 5c 58 ...i...#..%..\X
011d - 29 f3 ea 03 8f 24 df 6b-23 18 03 77 d3 71 31 )....$.k#..w.q1
012c - f7 5d b1 8f 41 f9 d8 5b-65 3d fa 46 bf 26 17 .]..A..[e=.F.&.
013b - 12 63 26 cc f1 cb 83 34-57 75 23 52 c8 41 7a .c&....4Wu#R.Az
014a - 09 44 84 d7 b6 4b cf 51-b2 6a 9b eb 3a 0e d4 .D...K.Q.j..:..
0159 - b9 ca f1 bd 23 c6 90 c6-54 f7 eb 9c e9 85 2e ....#...T......
0168 - 2f 6d 06 8e ef 8b a3 3b-c6 c4 dd dc a7 ae f4 /m.............
0177 - d3 57 47 37 d7 c4 dc 1e-93 77 0d 8f 4f 22 de .WG7.....w..O".
0186 - a6 1d 73 08 3c 32 c4 03-8c 1e b3 dd 33 83 a8 ..s.<2......3..
0195 - 9a 87 95 e2 41 c2 ed 7c-b6 80 75 8c 04 10 69 ....A..|..u...i
01a4 - 48 98 60 fc 9f 49 0e 85-23 60 72 54 8b 32 49 H....I..#.rT.2I
01b3 - 69 8f 99 95 3a cf 1e c6-58 b7 aa 85 e5 54 c4 i...:...X....T.
01c2 - 49 70 1a 6d 4b 03 9e d1-03 dc 45 8d f4 b2 9c Ip.mK.....E....
01d1 - b0 4b 8c ed d5 40 c8 43-48 da 79 c1 86 56 d5 .K...@.CH.y..V.
01e0 - 18 8f 9f 3a 9e 4b 9b 84-0c 70 66 4b 90 29 6c ...:.K...pfK.)l
01ef - 60 b7 ac 98 4e 91 8d 48-a0 9d bd df b2 81 fc ....N..H.......
01fe - 86 25 10 db 59 d9 fa 9d-c9 3f 10 f9 c6 d7 be .%..Y....?.....
020d - f7 29 31 d1 84 ca d7 ac-13 c1 a5 29 5f c8 9f .)1........)_..
021c - e3 bb 7e b8 e0 20 85 a8-28 c5 a1 38 78 6e 60 ..~.....(..8xn.
022b - 7a de 4f 5e 8d 41 15 90-92 09 ba 87 8a 79 30 z.O^.A.......y0
023a - 5a 53 16 c2 22 29 e4 2b-88 6d 06 48 1c 84 73 ZS..").+.m.H..s
0249 - f9 d5 12 69 e2 af 63 41-bc e2 0f 76 8e 86 0d ...i..cA...v...
0258 - 77 84 ed 46 15 0e 04 ff-50 cd 20 9c 5b 12 75 w..F....P...[.u
0267 - 11 36 9f e0 6b c4 aa 9a-72 d8 f1 fe 4f cf 08 .6..k...r...O..
0276 - 66 d6 64 b3 65 ff a8 6e-8c 1b 43 e7 a9 21 2a f.d.e..n..C..!*
0285 - ec c1 6c a3 50 a2 8e fa-e2 5f ac 05 4d d9 34 ..l.P...._..M.4
0294 - bf e7 e5 fa 4f 75 3a a4-15 96 8c 7e be c4 39 ....Ou:....~..9
02a3 - e0 ac 02 70 b4 87 4a 06-8d 22 48 4c 09 d9 e8 ...p..J.."HL...
02b2 - ab e1 7f 13 72 b4 b2 f6-5f 11 48 e8 93 3e da ....r..._.H..>.
02c1 - 92 e5 d1 77 45 64 96 3b-39 1c 3b bd 9f 1c 27 ...wEd..9......
02d0 - ff e3 6f 83 2e 05 15 5f-c3 9e e6 65 2f a7 b4 ..o...._...e/..
02df - 18 89 75 ec 5c 67 b3 2c-9f 21 3c 8a c6 b8 e1 ..u.\g.,.!<....
02ee - 32 a5 a7 c3 bf 74 f0 16-40 5c d8 c2 01 d1 05 2....t..@\.....
002d - 77 49 b2 50 4e 45 f5 7c-3b 06 66 26 b0 fc 74 wI.PNE.|..f&..t
003c - 62 36 1e ec 26 7c 56 01-39 be 5c d2 86 a2 af b6..&|V.9.\....
004b - 96 96 cf 51 85 22 78 e5-2c 38 18 ca b0 a6 8c ...Q."x.,8.....
005a - 59 8d e4 fc e1 4a 33 38-84 e4 de 5d df 57 ed Y....J38...].W.
0069 - d7 88 67 02 7a 31 e4 a7-c0 c0 29 91 44 c5 de ..g.z1....).D..
0078 - 6b ae 39 69 9e 70 0e 05-7e b0 f0 da d7 3b 8b k.9i.p..~......
0087 - 36 9f 42 eb 32 1b 41 53-87 81 d9 82 a1 1a 0b 6.B.2.AS.......
0096 - 39 43 ac 10 c9 7b 54 ee-b7 3b 38 ec 13 1a fc 9C...{T...8....
00a5 - 56 10 e3 73 48 72 74 d6-9c af a9 54 19 02 88 V..sHrt....T...
00b4 - 6c 64 f6 96 2d 42 eb 33-f9 04 1a 4a e1 1b 88 ld..-B.3...J...
00c3 - dc 69 58 d5 3d f5 0b 8b-b5 2a a3 5e 22 99 88 .iX.=....*.^"..
00d2 - 5d 0a ae 41 6b 86 f0 a8-8d 0e b7 a9 81 db b2 ]..Ak..........
00e1 - 83 e8 b9 4e 9d 50 bf 62-65 c2 34 8a 18 a1 69 ...N.P.be.4...i
00f0 - aa cb 5a 37 a5 29 bd a2-f9 cb 10 ef dd cf 14 ..Z7.).........
00ff - 23 10 95 d8 79 64 63 7b-d3 3f b1 3c 68 b4 cf #...ydc{.?.<h..
010e - f9 a1 90 69 60 c1 ea 23-01 d3 25 b7 a1 5c 58 ...i...#..%..\X
011d - 29 f3 ea 03 8f 24 df 6b-23 18 03 77 d3 71 31 )....$.k#..w.q1
012c - f7 5d b1 8f 41 f9 d8 5b-65 3d fa 46 bf 26 17 .]..A..[e=.F.&.
013b - 12 63 26 cc f1 cb 83 34-57 75 23 52 c8 41 7a .c&....4Wu#R.Az
014a - 09 44 84 d7 b6 4b cf 51-b2 6a 9b eb 3a 0e d4 .D...K.Q.j..:..
0159 - b9 ca f1 bd 23 c6 90 c6-54 f7 eb 9c e9 85 2e ....#...T......
0168 - 2f 6d 06 8e ef 8b a3 3b-c6 c4 dd dc a7 ae f4 /m.............
0177 - d3 57 47 37 d7 c4 dc 1e-93 77 0d 8f 4f 22 de .WG7.....w..O".
0186 - a6 1d 73 08 3c 32 c4 03-8c 1e b3 dd 33 83 a8 ..s.<2......3..
0195 - 9a 87 95 e2 41 c2 ed 7c-b6 80 75 8c 04 10 69 ....A..|..u...i
01a4 - 48 98 60 fc 9f 49 0e 85-23 60 72 54 8b 32 49 H....I..#.rT.2I
01b3 - 69 8f 99 95 3a cf 1e c6-58 b7 aa 85 e5 54 c4 i...:...X....T.
01c2 - 49 70 1a 6d 4b 03 9e d1-03 dc 45 8d f4 b2 9c Ip.mK.....E....
01d1 - b0 4b 8c ed d5 40 c8 43-48 da 79 c1 86 56 d5 .K...@.CH.y..V.
01e0 - 18 8f 9f 3a 9e 4b 9b 84-0c 70 66 4b 90 29 6c ...:.K...pfK.)l
01ef - 60 b7 ac 98 4e 91 8d 48-a0 9d bd df b2 81 fc ....N..H.......
01fe - 86 25 10 db 59 d9 fa 9d-c9 3f 10 f9 c6 d7 be .%..Y....?.....
020d - f7 29 31 d1 84 ca d7 ac-13 c1 a5 29 5f c8 9f .)1........)_..
021c - e3 bb 7e b8 e0 20 85 a8-28 c5 a1 38 78 6e 60 ..~.....(..8xn.
022b - 7a de 4f 5e 8d 41 15 90-92 09 ba 87 8a 79 30 z.O^.A.......y0
023a - 5a 53 16 c2 22 29 e4 2b-88 6d 06 48 1c 84 73 ZS..").+.m.H..s
0249 - f9 d5 12 69 e2 af 63 41-bc e2 0f 76 8e 86 0d ...i..cA...v...
0258 - 77 84 ed 46 15 0e 04 ff-50 cd 20 9c 5b 12 75 w..F....P...[.u
0267 - 11 36 9f e0 6b c4 aa 9a-72 d8 f1 fe 4f cf 08 .6..k...r...O..
0276 - 66 d6 64 b3 65 ff a8 6e-8c 1b 43 e7 a9 21 2a f.d.e..n..C..!*
0285 - ec c1 6c a3 50 a2 8e fa-e2 5f ac 05 4d d9 34 ..l.P...._..M.4
0294 - bf e7 e5 fa 4f 75 3a a4-15 96 8c 7e be c4 39 ....Ou:....~..9
02a3 - e0 ac 02 70 b4 87 4a 06-8d 22 48 4c 09 d9 e8 ...p..J.."HL...
02b2 - ab e1 7f 13 72 b4 b2 f6-5f 11 48 e8 93 3e da ....r..._.H..>.
02c1 - 92 e5 d1 77 45 64 96 3b-39 1c 3b bd 9f 1c 27 ...wEd..9......
02d0 - ff e3 6f 83 2e 05 15 5f-c3 9e e6 65 2f a7 b4 ..o...._...e/..
02df - 18 89 75 ec 5c 67 b3 2c-9f 21 3c 8a c6 b8 e1 ..u.\g.,.!<....
02ee - 32 a5 a7 c3 bf 74 f0 16-40 5c d8 c2 01 d1 05 2....t..@\.....
02fd - 21 93 e1 86 d4 43 58 de-38 8d 73 21 1b a2 f1 !....CX.8.s!...
030c - 79 2f 3c fe b9 bb de 72-11 d2 6f 56 ab 06 e1 y/<....r..oV...
031b - 1c cc 9c cd e2 b8 8c d8-37 37 73 ea fc 37 fd ........77s..7.
032a - 85 b7 a7 a2 bc ae c7 52-e6 17 d6 e0 1c 02 b8 .......R.......
0339 - 6e 9d 9a 40 f3 20 46 2c-5d 66 f8 35 17 16 dc n..@..F,]f.5...
0348 - d6 01 4b df 30 a6 0f 75-fc 06 31 c9 20 84 5e ..K.0..u..1...^
0357 - d8 c0 ba d3 5d df 19 84-f2 24 1c d3 b5 29 dc ....]....$...).
0366 - 10 28 84 5f 80 89 54 3d-f4 f1 44 1e de 36 b1 .(._..T=..D..6.
0375 - bf 31 af 5a fc 8c 2b 70-8d 50 b6 45 d4 e7 db .1.Z..+p.P.E...
0384 - 88 64 8c 3e ef e1 47 65-15 8f b0 e8 d3 bb 53 .d.>..Ge......S
0393 - dd cb e2 6d 71 24 c6 e1-d9 92 f8 32 30 aa 95 ...mq$.....20..
03a2 - 33 76 ee 8c 68 10 95 68-e8 57 1f 0c 9b bd a4 3v..h..h.W.....
03b1 - 8f 4d f3 06 fe 74 7f 37-11 75 14 8f 31 83 27 .M...t.7.u..1..
03c0 - 67 cd 76 6c f0 7b 45 0c-bf 62 ca d2 a7 bd 71 g.vl.{E..b....q
03cf - f1 f8 82 33 f1 16 a1 a7-f3 ca f1 2f 34 bc f4 ...3......./4..
03de - 0d 21 e7 9f fc 98 27 22-1b 68 b0 80 ff 03 ad .!.....".h.....
03ed - 78 2d 6d 6d 07 87 16 76-f7 98 94 3e 54 f1 3f x-mm...v...>T.?
03fc - d7 5c 89 c0 b4 26 3b f1-0f 56 24 3f 9e 72 ef .\...&...V$?.r.
040b - 3b 38 99 a5 39 d9 a3 ac-5b e2 b6 94 00 a3 cf .8..9...[......
041a - 8d 19 6c 5c ed 69 7b 2e-d8 03 b9 87 a5 ee 85 ..l\.i{........
0429 - c5 09 5b 48 da 7a 5b 03-b4 7e 2b 9f e4 cd 4b ..[H.z[..~+...K
0438 - c3 09 8e 86 4e 0c e7 d4-67 da 99 cd 7f 3a 9e ....N...g....:.
0447 - 94 7b 5e ea 77 f7 a6 be-16 c8 c7 e9 e0 de cc .{^.w..........
0456 - 1f f1 32 55 9c 23 43 21-7b 9c 29 50 38 6e 85 ..2U.#C!{.)P8n.
0465 - d2 94 21 21 08 6c df a1-96 58 19 5b e6 d7 f8 ..!!.l...X.[...
0474 - 6b ca 98 81 b6 95 08 29-64 f1 2e 7c f8 01 02 k......)d..|...
0483 - 5d 67 92 c6 88 24 09 41-4d 70 33 21 ec 83 ab ]g...$.AMp3!...
0492 - d6 98 d6 89 56 11 87 13-a0 ff 12 72 ac bc 9a ....V......r...
04a1 - 6d 14 89 00 c7 4c 16 92-1d f9 b3 8f 29 ec 46 m....L......).F
04b0 - d4 f1 00 60 ff fe 5e 36-bb ba ca f2 d1 ba d7 ......^6.......
04bf - dd 05 7e d3 e3 0e bc d6-90 83 f9 d3 a2 a2 6e ..~...........n
04ce - f9 0b 75 1d 6a 1a df a0-59 0d b1 9d a1 07 cf ..u.j...Y......
04dd - 3e a8 db >..
authAttrs:
<EMPTY>
mac:
0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35 ........=.Z..v5
000f - 2d -
unauthAttrs:
<EMPTY>
02fd - 21 93 e1 86 d4 43 58 de-38 8d 73 21 1b a2 f1 !....CX.8.s!...
030c - 79 2f 3c fe b9 bb de 72-11 d2 6f 56 ab 06 e1 y/<....r..oV...
031b - 1c cc 9c cd e2 b8 8c d8-37 37 73 ea fc 37 fd ........77s..7.
032a - 85 b7 a7 a2 bc ae c7 52-e6 17 d6 e0 1c 02 b8 .......R.......
0339 - 6e 9d 9a 40 f3 20 46 2c-5d 66 f8 35 17 16 dc n..@..F,]f.5...
0348 - d6 01 4b df 30 a6 0f 75-fc 06 31 c9 20 84 5e ..K.0..u..1...^
0357 - d8 c0 ba d3 5d df 19 84-f2 24 1c d3 b5 29 dc ....]....$...).
0366 - 10 28 84 5f 80 89 54 3d-f4 f1 44 1e de 36 b1 .(._..T=..D..6.
0375 - bf 31 af 5a fc 8c 2b 70-8d 50 b6 45 d4 e7 db .1.Z..+p.P.E...
0384 - 88 64 8c 3e ef e1 47 65-15 8f b0 e8 d3 bb 53 .d.>..Ge......S
0393 - dd cb e2 6d 71 24 c6 e1-d9 92 f8 32 30 aa 95 ...mq$.....20..
03a2 - 33 76 ee 8c 68 10 95 68-e8 57 1f 0c 9b bd a4 3v..h..h.W.....
03b1 - 8f 4d f3 06 fe 74 7f 37-11 75 14 8f 31 83 27 .M...t.7.u..1..
03c0 - 67 cd 76 6c f0 7b 45 0c-bf 62 ca d2 a7 bd 71 g.vl.{E..b....q
03cf - f1 f8 82 33 f1 16 a1 a7-f3 ca f1 2f 34 bc f4 ...3......./4..
03de - 0d 21 e7 9f fc 98 27 22-1b 68 b0 80 ff 03 ad .!.....".h.....
03ed - 78 2d 6d 6d 07 87 16 76-f7 98 94 3e 54 f1 3f x-mm...v...>T.?
03fc - d7 5c 89 c0 b4 26 3b f1-0f 56 24 3f 9e 72 ef .\...&...V$?.r.
040b - 3b 38 99 a5 39 d9 a3 ac-5b e2 b6 94 00 a3 cf .8..9...[......
041a - 8d 19 6c 5c ed 69 7b 2e-d8 03 b9 87 a5 ee 85 ..l\.i{........
0429 - c5 09 5b 48 da 7a 5b 03-b4 7e 2b 9f e4 cd 4b ..[H.z[..~+...K
0438 - c3 09 8e 86 4e 0c e7 d4-67 da 99 cd 7f 3a 9e ....N...g....:.
0447 - 94 7b 5e ea 77 f7 a6 be-16 c8 c7 e9 e0 de cc .{^.w..........
0456 - 1f f1 32 55 9c 23 43 21-7b 9c 29 50 38 6e 85 ..2U.#C!{.)P8n.
0465 - d2 94 21 21 08 6c df a1-96 58 19 5b e6 d7 f8 ..!!.l...X.[...
0474 - 6b ca 98 81 b6 95 08 29-64 f1 2e 7c f8 01 02 k......)d..|...
0483 - 5d 67 92 c6 88 24 09 41-4d 70 33 21 ec 83 ab ]g...$.AMp3!...
0492 - d6 98 d6 89 56 11 87 13-a0 ff 12 72 ac bc 9a ....V......r...
04a1 - 6d 14 89 00 c7 4c 16 92-1d f9 b3 8f 29 ec 46 m....L......).F
04b0 - d4 f1 00 60 ff fe 5e 36-bb ba ca f2 d1 ba d7 ......^6.......
04bf - dd 05 7e d3 e3 0e bc d6-90 83 f9 d3 a2 a2 6e ..~...........n
04ce - f9 0b 75 1d 6a 1a df a0-59 0d b1 9d a1 07 cf ..u.j...Y......
04dd - 3e a8 db >..
authAttrs:
<EMPTY>
mac:
0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35 ........=.Z..v5
000f - 2d -
unauthAttrs:
<EMPTY>
Figure 8: Message Encrypted by Bob for Alice
图8:Bob为Alice加密的消息
Authors' Addresses
作者地址
Ben Campbell Standard Velocity, LLC
本坎贝尔标准速度有限责任公司
Email: ben@nostrum.com
Email: ben@nostrum.com
Russ Housley Vigil Security, LLC
Russ Housley Vigil安全有限责任公司
Email: housley@vigilsec.com
Email: housley@vigilsec.com