Internet Engineering Task Force (IETF) P. Gutmann
Request for Comments: 6476 University of Auckland
Category: Standards Track January 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Gutmann
Request for Comments: 6476 University of Auckland
Category: Standards Track January 2012
ISSN: 2070-1721
Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)
在加密消息语法（CMS）中使用消息身份验证码（MAC）加密
Abstract
摘要
This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community.
本文档规定了将消息认证码（MAC）加密与加密消息语法（CMS）认证的信封数据内容类型一起使用的约定。这反映了MAC与IPsec、安全套接字层/传输层安全（SSL/TLS）和安全外壳（SSH）中已采用的加密算法相结合的使用，现有加密库和硬件广泛支持该算法，加密社区对此进行了广泛分析。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6476.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6476.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Background ......................................................2
3. CMS Encrypt-and-Authenticate Overview ...........................3
3.1. Rationale ..................................................3
4. CMS Encrypt-and-Authenticate ....................................4
4.1. Encrypt-and-Authenticate Message Processing ................5
4.2. Rationale ..................................................6
4.3. Test Vectors ...............................................8
5. SMIMECapabilities Attribute ....................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Background ......................................................2
3. CMS Encrypt-and-Authenticate Overview ...........................3
3.1. Rationale ..................................................3
4. CMS Encrypt-and-Authenticate ....................................4
4.1. Encrypt-and-Authenticate Message Processing ................5
4.2. Rationale ..................................................6
4.3. Test Vectors ...............................................8
5. SMIMECapabilities Attribute ....................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
This document specifies the conventions for using MAC-authenticated encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, SSL/ TLS and SSH, which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community.
本文档规定了使用MAC认证加密和加密消息语法（CMS）认证信封数据内容类型的约定。这反映了MAC与已在IPsec、SSL/TLS和SSH中使用的加密算法的结合使用，现有加密库和硬件广泛支持该算法，加密社区对此进行了广泛分析。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Integrity-protected encryption is a standard feature of session-oriented security protocols like [IPsec], [SSH], and [TLS]. Until recently, however, integrity-protected encryption wasn't available for message-based security protocols like CMS, although [OpenPGP] added a form of integrity protection by encrypting a SHA-1 hash of the message alongside the message contents to provide authenticate-and-encrypt protection. Usability studies have shown that users expect encryption to provide integrity protection [Garfinkel], creating cognitive dissonance problems when the security mechanisms don't in fact provide this assurance.
完整性保护加密是[IPsec]、[SSH]和[TLS]等面向会话的安全协议的标准功能。然而，直到最近，完整性保护加密还不能用于基于消息的安全协议，如CMS，尽管[OpenPGP]通过加密消息内容旁边的消息SHA-1散列来提供身份验证和加密保护，增加了一种完整性保护形式。可用性研究表明，用户期望加密提供完整性保护[Garfinkel]，当安全机制实际上不能提供这种保证时，就会产生认知不一致问题。
This document applies the same encrypt-and-authenticate mechanism already employed in IPsec, SSH, and SSL/TLS to CMS (technically some of these actually use authenticate-and-encrypt rather than encrypt-and-authenticate, since what's authenticated is the plaintext and not the ciphertext). This mechanism is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community [EncryptThenAuth].
本文档将IPsec、SSH和SSL/TLS中已经采用的相同加密和身份验证机制应用于CMS（从技术上讲，其中一些实际上使用了身份验证和加密，而不是加密和身份验证，因为经过身份验证的是明文而不是密文）。这种机制在现有的加密库和硬件中得到了广泛的支持，加密社区[EncryptThenAuth]对此进行了广泛的分析。
Conventional CMS encryption uses a content-encryption key (CEK) to encrypt a message payload, with the CEK typically being in turn encrypted by a key-encryption key (KEK). Authenticated encryption requires two keys: one for encryption and a second one for authentication. Like other mechanisms that use authenticated encryption, this document employs a pseudorandom function (PRF) to convert a single block of keying material into the two keys required for encryption and authentication. This converts the standard CMS encryption operation:
传统的CMS加密使用内容加密密钥（CEK）加密消息有效载荷，CEK通常依次由密钥加密密钥（KEK）加密。经过身份验证的加密需要两个密钥：一个用于加密，另一个用于身份验证。与使用认证加密的其他机制一样，本文档使用伪随机函数（PRF）将单个密钥材料块转换为加密和认证所需的两个密钥。这将转换标准CMS加密操作：
KEK( CEK ) || CEK( data )
KEK（CEK）| | CEK（数据）
into:
进入：
KEK( master_secret ) || MAC( CEK( data ) )
KEK( master_secret ) || MAC( CEK( data ) )
where the MAC key MAC-K and encryption key CEK-K are derived from the master_secret via:
其中，MAC密钥MAC-K和加密密钥CEK-K通过以下方式从主密钥导出：
MAC-K := PRF( master_secret, "authentication" );
CEK-K := PRF( master_secret, "encryption" );
MAC-K := PRF( master_secret, "authentication" );
CEK-K := PRF( master_secret, "encryption" );
There are several possible means of deriving the two keys required for the encrypt-and-authenticate process from the single key normally provided by the key exchange or key transport mechanisms. Several of these, however, have security or practical issues. For example, any mechanism that uses the single exchanged key in its entirety for encryption (using, perhaps, PRF( key ) as the MAC key) can be converted back to unauthenticated data by removing the outer MAC layer and rewriting the CMS envelope back to plain EnvelopedData or EncryptedData. By applying the PRF intermediate step, any attempt at a rollback attack will result in a decryption failure.
有几种可能的方法可以从通常由密钥交换或密钥传输机制提供的单个密钥派生加密和身份验证过程所需的两个密钥。然而，其中有几个存在安全或实际问题。例如，通过移除外部MAC层并将CMS信封重写回普通信封数据或加密数据，可以将全部使用单个交换密钥进行加密（可能使用PRF（密钥）作为MAC密钥）的任何机制转换回未经验证的数据。通过应用PRF中间步骤，任何回滚攻击的尝试都将导致解密失败。
The option chosen here -- the use of a PRF to derive the necessary sets of keying material from a master secret -- is well-established through its use in IPsec, SSH, and SSL/TLS and is widely supported in both crypto libraries and in encryption hardware.
这里选择的选项——使用PRF从主密钥派生必要的密钥材料集——通过在IPsec、SSH和SSL/TLS中的使用而得到了广泛的支持，并且在加密库和加密硬件中都得到了广泛的支持。
The PRF used is Password-Based Key Derivation Function 2 (PBKDF2) because its existing use in CMS makes it the most obvious candidate for such a function. In the future, if a universal PRF -- for example, [HKDF] -- is adopted, then this can be substituted for PBKDF2 by specifying it in the prfAlgorithm field covered in Section 4.
使用的PRF是基于密码的密钥派生函数2（PBKDF2），因为它在CMS中的现有使用使其成为此类函数的最明显候选。将来，如果采用通用PRF（例如，[HKDF]），则可通过在第4节所述的PRF字段中指定PBKDF2来替代PBKDF2。
The resulting processing operations consist of a combination of the operations used for the existing CMS content types EncryptedData and AuthenticatedData, allowing them to be implemented relatively simply using existing code.
产生的处理操作包括用于现有CMS内容类型EncryptedData和AuthenticatedData的操作组合，允许使用现有代码相对简单地实现这些操作。
The encrypt-and-authenticate mechanism is implemented within the existing CMS RecipientInfo framework by defining a new pseudo-algorithm type, authEnc, which is used in place of a monolithic encrypt and hash algorithm. The RecipientInfo is used as a key container for the master secret used by the pseudo-algorithm from which the encryption and authentication keys for existing single-purpose encrypt-only and MAC-only algorithms are derived. Thus, instead of using the RecipientInfo to communicate (for example) an AES or HMAC-SHA1 key, it communicates a master secret from which the required AES encryption and HMAC-SHA1 authentication keys are derived.
加密和身份验证机制是在现有CMS RecipientInfo框架内通过定义新的伪算法类型authEnc来实现的，authEnc用于替代单一加密和哈希算法。RecipientInfo用作伪算法使用的主密钥的密钥容器，从中导出现有单用途encrypt only和MAC only算法的加密和身份验证密钥。因此，它不是使用RecipientInfo来传送（例如）AES或HMAC-SHA1密钥，而是传送从中派生所需AES加密和HMAC-SHA1认证密钥的主密钥。
The authEnc pseudo-algorithm comes in two forms: one conveying 128 bits of keying material and one conveying 256 bits:
authEnc伪算法有两种形式：一种传输128位密钥材料，另一种传输256位：
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-alg OBJECT IDENTIFIER ::= { id-smime 3 }
id-alg OBJECT IDENTIFIER ::= { id-smime 3 }
id-alg-authEnc-128 OBJECT IDENTIFIER ::= { id-alg 15 }
id-alg-authEnc-256 OBJECT IDENTIFIER ::= { id-alg 16 }
id-alg-authEnc-128 OBJECT IDENTIFIER ::= { id-alg 15 }
id-alg-authEnc-256 OBJECT IDENTIFIER ::= { id-alg 16 }
The algorithm parameters are as follows:
算法参数如下：
AuthEncParams ::= SEQUENCE {
prfAlgorithm [0] AlgorithmIdentifier DEFAULT PBKDF2,
encAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier
}
AuthEncParams ::= SEQUENCE {
prfAlgorithm [0] AlgorithmIdentifier DEFAULT PBKDF2,
encAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier
}
prfAlgorithm is the PRF algorithm used to convert the master secret into the encryption and MAC keys. The default PRF is [PBKDF2], which in turn has a default PRF algorithm of HMAC-SHA1. When this default setting is used, the PBKDF2-params 'salt' parameter is an empty string, and the 'iterationCount' parameter is one, turning the KDF into a pure PRF.
PRF算法是用于将主密钥转换为加密密钥和MAC密钥的PRF算法。默认的PRF是[PBKDF2]，它又有一个默认的PRF算法HMAC-SHA1。使用此默认设置时，PBKDF2 params'salt'参数为空字符串，而'iterationCount'参数为一，将KDF转换为纯PRF。
encAlgorithm is the encryption algorithm and associated parameters to be used to encrypt the content.
encAlgorithm是用于加密内容的加密算法和相关参数。
macAlgorithm is the MAC algorithm and associated parameters to be used to authenticate/integrity-protect the content.
macAlgorithm是用于验证/完整性保护内容的MAC算法和相关参数。
When the prfAlgorithm AlgorithmIdentifier is used in conjunction with PBKDF2 to specify a PRF other than the default PBKDF2-with-HMAC-SHA1 one, the PBKDF2-params require that two additional algorithm parameters be specified. The 'salt' parameter MUST be an empty (zero-length) string, and the 'iterationCount' parameter MUST be one, since these values aren't used in the PRF process. In their encoded form as used for the PBKDF2-params, these two parameters have the value 08 00 02 01 01.
当prfAlgorithm AlgorithmIdentifier与PBKDF2一起用于指定除默认PBKDF2-with-HMAC-SHA1之外的PRF时，PBKDF2参数要求指定两个额外的算法参数。“salt”参数必须是空（零长度）字符串，“iterationCount”参数必须是一个，因为这些值在PRF过程中不使用。在用于PBKDF2参数的编码形式中，这两个参数的值为08 00 02 01。
As a guideline for authors specifying the use of PRFs other than PBKDF2, any additional parameters such as salts, tags, and identification strings SHOULD be set to empty strings, and any iteration count SHOULD be set to one.
作为指定使用PBKDF2以外的PRF的作者的指南，任何附加参数（如盐、标记和标识字符串）都应设置为空字符串，任何迭代计数都应设置为1。
The randomly generated master secret to be communicated via the RecipientInfo(s) is converted to separate encryption and authentication keys and applied to the encrypt-and-authenticate process as follows. The notation "PRF( key, salt, iterations )" is used to denote an application of the PRF to the given keying value and salt, for the given number of iterations:
要通过RecipientInfo通信的随机生成的主密钥被转换为单独的加密和身份验证密钥，并应用于加密和身份验证过程，如下所示。符号“PRF（键、盐、迭代）”用于表示针对给定迭代次数对给定键控值和盐的PRF应用：
1. The MAC algorithm key is derived from the master secret via:
1. MAC算法密钥通过以下方式从主密钥派生：
MAC-K ::= PRF( master_secret, "authentication", 1 );
MAC-K ::= PRF( master_secret, "authentication", 1 );
2. The encryption algorithm key is derived from the master secret via:
2. 加密算法密钥通过以下方式从主密钥派生：
Enc-K ::= PRF( master_secret, "encryption", 1 );
Enc-K ::= PRF( master_secret, "encryption", 1 );
3. The data is processed as described in [AuthEnv], and specifically since the mechanisms used are a union of EncryptedData and AuthenticatedData, as per [CMS]. The one exception to this is that the EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier data is MACed before the encrypted content is MACed. The EncryptedData processing is applied to the data first, and then the AuthenticatedData processing is applied to the result, so that the nesting is as follows:
3. 数据按照[AuthEnv]中的描述进行处理，特别是因为使用的机制是EncryptedData和AuthenticatedData的联合，符合[CMS]。唯一的例外是，加密内容之前会对EncryptedContentInfo.ContentEncryptionalGorithmidIdentifier数据进行缓冲。首先对数据应用EncryptedData处理，然后对结果应用AuthenticatedData处理，因此嵌套如下：
MAC( contentEncrAlgoID || encrypt( content ) );
MAC( contentEncrAlgoID || encrypt( content ) );
4. If authenticated attributes are present, then they are encoded as described in [AuthEnv] and MACed after the encrypted content, so that the processing is as follows:
4. 如果存在经过身份验证的属性，则按照[AuthEnv]中的描述对其进行编码，并在加密内容后进行MACE，以便处理如下：
MAC( contentEncrAlgoID || encrypt( content ) || authAttr );
MAC( contentEncrAlgoID || encrypt( content ) || authAttr );
When choosing between encrypt-and-authenticate and authenticate-and-encrypt, the more secure option is encrypt-and-authenticate. There has been extensive analysis of this in the literature; the best coverage is probably [EncryptThenAuth].
在选择加密和身份验证以及身份验证和加密时，更安全的选项是加密和身份验证。文献中对此进行了广泛的分析；最好的覆盖范围可能是[EncryptThenAuth]。
The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier is the SEQUENCE containing the id-alg-authEnc-128/id-alg-authEnc-256 OBJECT IDENTIFIER and its associated AuthEncParams. This data is MACed exactly as encoded, without any attempt to re-code it into a canonical form like DER.
EncryptedContentInfo.ContentEncryptionalGorithMidIdentifier是包含id-alg-authEnc-128/id-alg-authEnc-256对象标识符及其关联AuthEncParams的序列。这些数据完全按照编码的方式进行处理，没有任何尝试将其重新编码为像DER这样的规范形式。
The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be protected alongside the encrypted content; otherwise, an attacker could manipulate the encrypted data indirectly by manipulating the encryption algorithm parameters, which wouldn't be detected through MACing the encrypted content alone. For example, by changing the encryption IV, it's possible to modify the results of the decryption after the encrypted data has been verified via a MAC check.
EncryptedContentInfo.ContentEncryptionalGorithmidIdentifier必须与加密内容一起受到保护；否则，攻击者可以通过操纵加密算法参数间接操纵加密数据，而仅通过篡改加密内容无法检测到这些参数。例如，通过更改加密IV，可以在通过MAC检查验证加密数据后修改解密结果。
The authEnc pseudo-algorithm has two "key sizes" rather than the one-size-fits-all that the PRF impedance-matching would provide. This is done to address real-world experience in the use of AES keys, where users demanded AES-256 alongside AES-128 because of some perception that the former was "twice as good" as the latter. Providing an option for keys that go to 11 avoids potential user acceptance problems when someone notices that the authEnc pseudo-key has "only" 128 bits when they expect their AES keys to be 256 bits long.
authEnc伪算法有两个“密钥大小”，而不是PRF阻抗匹配所提供的“一刀切”。这样做是为了解决使用AES密钥的真实体验，用户需要AES-256和AES-128，因为有人认为前者的性能是后者的“两倍”。为转到11的密钥提供一个选项，可以避免当有人注意到authEnc伪密钥“只有”128位时出现潜在的用户接受问题，而他们预期AES密钥的长度为256位。
Using a fixed-length key rather than making it a user-selectable parameter is done for the same reason as AES's quantised key lengths: there's no benefit to allowing, say, 137-bit keys over basic 128- and 256-bit lengths; it adds unnecessary complexity; if the lengths are user-defined, then there'll always be someone who wants keys that go up to 12. Providing a choice of two commonly used lengths gives users the option of choosing a "better" key size should they feel the need, while not overloading the system with unneeded flexibility.
使用固定长度的密钥而不是使其成为用户可选择的参数，其原因与AES的量化密钥长度相同：例如，允许137位密钥超过基本的128位和256位长度没有任何好处；它增加了不必要的复杂性；如果长度是用户定义的，那么总会有人希望键的长度达到12。通过提供两种常用长度的选择，用户可以根据需要选择“更好”的密钥大小，同时不会因不必要的灵活性而使系统过载。
The use of the PRF AlgorithmIdentifier presents some problems, because it's usually not specified in a manner that allows it to be easily used as a straight KDF. For example, PBKDF2 has the following parameters:
PRF算法识别器的使用带来了一些问题，因为它的指定方式通常不允许它轻松地用作直接KDF。例如，PBKDF2具有以下参数：
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
prf AlgorithmIdentifier {{PBKDF2-PRFs}}
DEFAULT algid-hmacWithSHA1
}
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
prf AlgorithmIdentifier {{PBKDF2-PRFs}}
DEFAULT algid-hmacWithSHA1
}
of which only the prf AlgorithmIdentifier is used here. In order to avoid having to define new AlgorithmIdentifiers for each possible PRF, this specification sets any parameters not required for KDF functionality to no-op values. In the case of PBKDF2, this means that the salt has length zero and the iteration count is set to one, with only the prf AlgorithmIdentifier playing a part in the processing. Although it's not possible to know what form other PRFs-as-KDFs will take, a general note for their application within this specification is that any non-PRF parameters should similarly be set to no-op values.
这里只使用prf算法标识符。为了避免为每个可能的PRF定义新的算法标识符，本规范将KDF功能不需要的任何参数设置为no op值。在PBKDF2的情况下，这意味着salt的长度为零，迭代计数设置为1，只有prf算法标识符在处理中起作用。虽然不可能知道其他PRF（如KDF）将采用何种形式，但在本规范中对其应用的一般注意事项是，任何非PRF参数都应类似地设置为no op值。
Specifying a MAC key size gets a bit tricky; most MAC algorithms have some de facto standard key size, and for HMAC algorithms, this is usually the same as the hash output size. For example, for HMAC-MD5, it's 128 bits; for HMAC-SHA1, it's 160 bits; and for HMAC-SHA256, it's 256 bits. Other MAC algorithms also have de facto standard key sizes. For example, for AES-based MACs, it's the AES key size -- 128 bits for AES-128 and 256 bits for AES-256. This situation makes
指定MAC密钥大小有点棘手；大多数MAC算法都有一些事实上的标准密钥大小，对于HMAC算法，这通常与哈希输出大小相同。例如，对于HMAC-MD5，它是128位；对于HMAC-SHA1，它是160位；对于HMAC-SHA256，它是256位。其他MAC算法也有事实上的标准密钥大小。例如，对于基于AES的MAC，它是AES密钥大小——AES-128为128位，AES-256为256位。这种情况使得
it difficult to specify the key size in a normative fashion, since it's dependent on the algorithm type that's being used. If there is any ambiguity over which key size should be used, then it's RECOMMENDED that either the size be specified explicitly in the macAlgorithm AlgorithmIdentifier or that an RFC or similar standards document be created that makes the key sizes explicit.
很难以规范的方式指定密钥大小，因为它取决于所使用的算法类型。如果对应使用的密钥大小存在任何歧义，则建议在macAlgorithm算法标识符中明确指定密钥大小，或者创建RFC或类似标准文档，以明确密钥大小。
As with other uses of PRFs for crypto impedance-matching in protocols, like IPsec, SSL/TLS, and SSH, the amount of input to the PRF generally doesn't match the amount of output. The general philosophical implications of this are covered in various analyses of the properties and uses of PRFs. If you're worried about this, then you can try and approximately match the authEnc "key size" to the key size of the encryption algorithm being used, although even there, a perfect match for algorithms like Blowfish (448 bits) or RC5 (832 bits) is going to be difficult.
与在协议（如IPsec、SSL/TLS和SSH）中使用PRF进行加密阻抗匹配的其他用途一样，PRF的输入量通常与输出量不匹配。PRF的性质和用途的各种分析涵盖了这一点的一般哲学含义。如果您担心这一点，那么您可以尝试将authEnc“密钥大小”与所使用的加密算法的密钥大小大致匹配，尽管即使在那里，要与Blowfish（448位）或RC5（832位）等算法完美匹配也会很困难。
The term "master secret" comes from its use in SSL/TLS, which uses a similar PRF-based mechanism to convert its master_secret value into encryption and MAC keys (as do SSH and IPsec). The master_secret value isn't a key in the conventional sense, but merely a secret value that's then used to derive two (or, in the cases of SSL/TLS, SSH, and IPsec, several) keys and related cryptovariables.
术语“主密钥”来源于它在SSL/TLS中的使用，它使用类似的基于PRF的机制将其主密钥值转换为加密和MAC密钥（SSH和IPsec也是如此）。master_secret值不是传统意义上的密钥，而只是一个密钥值，然后用于派生两个（或者，在SSL/TLS、SSH和IPsec的情况下，是多个）密钥和相关加密变量。
Apart from the extra step added to key management, all of the processing is already specified as part of the definition of the standard CMS content-types Encrypted/EnvelopedData and AuthenticatedData. This significantly simplifies both the specification and the implementation task, as no new content-processing mechanisms are introduced.
除了添加到密钥管理的额外步骤外，所有处理都已指定为标准CMS内容类型加密/信封数据和认证数据定义的一部分。这大大简化了规范和实现任务，因为没有引入新的内容处理机制。
The following test vectors may be used to verify an implementation of MAC-authenticated encryption. This represents a text string encrypted and authenticated using the ever-popular password "password" via CMS PasswordRecipientInfo. The encryption algorithm used for the first value is triple DES, whose short block size (compared to AES) makes it easier to corrupt arbitrary bytes for testing purposes within the self-healing Cipher Block Chaining (CBC) mode, which will result in correct decryption but a failed MAC check. The encryption algorithm used for the second value is AES.
以下测试向量可用于验证MAC认证加密的实现。这表示通过CMS PasswordRecipientInfo使用一直流行的密码“password”进行加密和验证的文本字符串。用于第一个值的加密算法是triple-DES，其较短的块大小（与AES相比）使得在自愈密码块链接（CBC）模式下，出于测试目的更容易损坏任意字节，这将导致正确的解密，但失败的MAC检查。用于第二个值的加密算法是AES。
For the triple DES-encrypted data, corrupting a byte at positions 192-208 can be used to check that payload-data corruption is detected, and corrupting a byte at positions 168-174 can be used to
对于三重DES加密数据，在位置192-208处损坏字节可用于检查是否检测到有效负载数据损坏，并且在位置168-174处损坏字节可用于
check that metadata corruption is detected. The corruption in these byte ranges doesn't affect normal processing and so wouldn't normally be detected.
检查是否检测到元数据损坏。这些字节范围中的损坏不会影响正常处理，因此通常不会被检测到。
The test data has the following characteristics:
试验数据具有以下特征：
version is set to 0.
版本设置为0。
originatorInfo isn't needed and is omitted.
不需要originatorInfo，因此省略了它。
recipientInfo uses passwordRecipientInfo to allow easy testing with a fixed text string.
recipientInfo使用passwordRecipientInfo允许使用固定文本字符串轻松测试。
authEncryptedContentInfo uses the authEnc128 pseudo-algorithm with a key of 128 bits used to derive triple DES/AES and HMAC-SHA1 keys.
authEncryptedContentInfo使用具有128位密钥的authEnc128伪算法来派生三重DES/AES和HMAC-SHA1密钥。
authAttrs aren't used and are omitted.
authattr未使用，因此被省略。
mac is the 20-byte HMAC-SHA1 MAC value.
mac是20字节的HMAC-SHA1 mac值。
unauthAttrs aren't used and are omitted.
未经授权的TR未被使用且被省略。
0 227: SEQUENCE {
3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData
(1 2 840 113549 1 9 16 1 23)
16 211: [0] {
19 208: SEQUENCE {
22 1: INTEGER 0
25 97: SET {
27 95: [3] {
29 1: INTEGER 0
32 27: [0] {
34 9: OBJECT IDENTIFIER pkcs5PBKDF2
(1 2 840 113549 1 5 12)
45 14: SEQUENCE {
47 8: OCTET STRING B7 EB 23 A7 6B D2 05 16
57 2: INTEGER 5000
: }
: }
61 35: SEQUENCE {
63 11: OBJECT IDENTIFIER pwriKEK
(1 2 840 113549 1 9 16 3 9)
0 227: SEQUENCE {
3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData
(1 2 840 113549 1 9 16 1 23)
16 211: [0] {
19 208: SEQUENCE {
22 1: INTEGER 0
25 97: SET {
27 95: [3] {
29 1: INTEGER 0
32 27: [0] {
34 9: OBJECT IDENTIFIER pkcs5PBKDF2
(1 2 840 113549 1 5 12)
45 14: SEQUENCE {
47 8: OCTET STRING B7 EB 23 A7 6B D2 05 16
57 2: INTEGER 5000
: }
: }
61 35: SEQUENCE {
63 11: OBJECT IDENTIFIER pwriKEK
(1 2 840 113549 1 9 16 3 9)
76 20: SEQUENCE {
78 8: OBJECT IDENTIFIER des-EDE3-CBC
(1 2 840 113549 3 7)
88 8: OCTET STRING 66 91 02 45 6B 73 BB 99
: }
: }
98 24: OCTET STRING
: 30 A3 7A B5 D8 F2 87 50 EC 41 04 AE 89 99 26 F0
: 2E AE 4F E3 F3 52 2B A3
: }
: }
124 82: SEQUENCE {
126 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
137 51: SEQUENCE {
139 11: OBJECT IDENTIFIER authEnc128
(1 2 840 113549 1 9 16 3 15)
152 36: SEQUENCE {
154 20: SEQUENCE {
156 8: OBJECT IDENTIFIER des-EDE3-CBC
(1 2 840 113549 3 7)
166 8: OCTET STRING D2 D0 81 71 4D 3D 9F 11
: }
176 12: SEQUENCE {
178 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2)
188 0: NULL
: }
: }
: }
190 16: [0] 3A C6 06 61 41 5D 00 7D 11 35 CD 69 E1 56 CA 10
: }
208 20: OCTET STRING
: 33 65 E8 F0 F3 07 06 86 1D A8 47 2C 6D 3A 1D 94
: 21 40 64 7E
: }
: }
: }
76 20: SEQUENCE {
78 8: OBJECT IDENTIFIER des-EDE3-CBC
(1 2 840 113549 3 7)
88 8: OCTET STRING 66 91 02 45 6B 73 BB 99
: }
: }
98 24: OCTET STRING
: 30 A3 7A B5 D8 F2 87 50 EC 41 04 AE 89 99 26 F0
: 2E AE 4F E3 F3 52 2B A3
: }
: }
124 82: SEQUENCE {
126 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
137 51: SEQUENCE {
139 11: OBJECT IDENTIFIER authEnc128
(1 2 840 113549 1 9 16 3 15)
152 36: SEQUENCE {
154 20: SEQUENCE {
156 8: OBJECT IDENTIFIER des-EDE3-CBC
(1 2 840 113549 3 7)
166 8: OCTET STRING D2 D0 81 71 4D 3D 9F 11
: }
176 12: SEQUENCE {
178 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2)
188 0: NULL
: }
: }
: }
190 16: [0] 3A C6 06 61 41 5D 00 7D 11 35 CD 69 E1 56 CA 10
: }
208 20: OCTET STRING
: 33 65 E8 F0 F3 07 06 86 1D A8 47 2C 6D 3A 1D 94
: 21 40 64 7E
: }
: }
: }
-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----
-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----
0 253: SEQUENCE {
3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData
(1 2 840 113549 1 9 16 1 23)
16 237: [0] {
19 234: SEQUENCE {
22 1: INTEGER 0
25 114: SET {
27 112: [3] {
29 1: INTEGER 0
32 27: [0] {
34 9: OBJECT IDENTIFIER pkcs5PBKDF2
(1 2 840 113549 1 5 12)
45 14: SEQUENCE {
47 8: OCTET STRING E7 B7 87 DF 82 1D 12 CC
57 2: INTEGER 5000
: }
: }
61 44: SEQUENCE {
63 11: OBJECT IDENTIFIER pwriKEK
(1 2 840 113549 1 9 16 3 9)
76 29: SEQUENCE {
78 9: OBJECT IDENTIFIER aes128-CBC
(2 16 840 1 101 3 4 1 2)
89 16: OCTET STRING
: 11 D9 5C 52 0A 3A BF 22 B2 30 70 EF F4 7D 6E F6
: }
: }
107 32: OCTET STRING
: 18 39 22 27 C3 C2 2C 2A A6 9F 2A B0 77 24 75 AA
: D8 58 9C CD BB 4C AE D3 0D C2 CB 1D 83 94 6C 37
: }
: }
141 91: SEQUENCE {
143 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
154 60: SEQUENCE {
156 11: OBJECT IDENTIFIER authEnc128
(1 2 840 113549 1 9 16 3 15)
169 45: SEQUENCE {
171 29: SEQUENCE {
173 9: OBJECT IDENTIFIER aes128-CBC
(2 16 840 1 101 3 4 1 2)
184 16: OCTET STRING
: B7 25 02 76 84 3C 58 1B A5 30 E2 40 27 EE C3 06
: }
0 253: SEQUENCE {
3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData
(1 2 840 113549 1 9 16 1 23)
16 237: [0] {
19 234: SEQUENCE {
22 1: INTEGER 0
25 114: SET {
27 112: [3] {
29 1: INTEGER 0
32 27: [0] {
34 9: OBJECT IDENTIFIER pkcs5PBKDF2
(1 2 840 113549 1 5 12)
45 14: SEQUENCE {
47 8: OCTET STRING E7 B7 87 DF 82 1D 12 CC
57 2: INTEGER 5000
: }
: }
61 44: SEQUENCE {
63 11: OBJECT IDENTIFIER pwriKEK
(1 2 840 113549 1 9 16 3 9)
76 29: SEQUENCE {
78 9: OBJECT IDENTIFIER aes128-CBC
(2 16 840 1 101 3 4 1 2)
89 16: OCTET STRING
: 11 D9 5C 52 0A 3A BF 22 B2 30 70 EF F4 7D 6E F6
: }
: }
107 32: OCTET STRING
: 18 39 22 27 C3 C2 2C 2A A6 9F 2A B0 77 24 75 AA
: D8 58 9C CD BB 4C AE D3 0D C2 CB 1D 83 94 6C 37
: }
: }
141 91: SEQUENCE {
143 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
154 60: SEQUENCE {
156 11: OBJECT IDENTIFIER authEnc128
(1 2 840 113549 1 9 16 3 15)
169 45: SEQUENCE {
171 29: SEQUENCE {
173 9: OBJECT IDENTIFIER aes128-CBC
(2 16 840 1 101 3 4 1 2)
184 16: OCTET STRING
: B7 25 02 76 84 3C 58 1B A5 30 E2 40 27 EE C3 06
: }
202 12: SEQUENCE {
204 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2)
214 0: NULL
: }
: }
: }
216 16: [0] 98 36 0F 0C 79 62 36 B5 2D 2D 9E 1C 62 85 1E 10
: }
234 20: OCTET STRING
: 88 A4 C1 B2 BA 78 1B CA F9 14 B0 E5 FC D1 8D F8
: 02 E2 B2 9E
: }
: }
: }
202 12: SEQUENCE {
204 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2)
214 0: NULL
: }
: }
: }
216 16: [0] 98 36 0F 0C 79 62 36 B5 2D 2D 9E 1C 62 85 1E 10
: }
234 20: OCTET STRING
: 88 A4 C1 B2 BA 78 1B CA F9 14 B0 E5 FC D1 8D F8
: 02 E2 B2 9E
: }
: }
: }
-----BEGIN PKCS7-----
MIH9BgsqhkiG9w0BCRABF6CB7TCB6gIBADFyo3ACAQCgGwYJKoZIhvcNAQUMMA4E
COe3h9+CHRLMAgITiDAsBgsqhkiG9w0BCRADCTAdBglghkgBZQMEAQIEEBHZXFIK
Or8isjBw7/R9bvYEIBg5IifDwiwqpp8qsHckdarYWJzNu0yu0w3Cyx2DlGw3MFsG
CSqGSIb3DQEHATA8BgsqhkiG9w0BCRADDzAtMB0GCWCGSAFlAwQBAgQQtyUCdoQ8
WBulMOJAJ+7DBjAMBggrBgEFBQgBAgUAgBCYNg8MeWI2tS0tnhxihR4QBBSIpMGy
ungbyvkUsOX80Y34AuKyng==
-----END PKCS7-----
-----BEGIN PKCS7-----
MIH9BgsqhkiG9w0BCRABF6CB7TCB6gIBADFyo3ACAQCgGwYJKoZIhvcNAQUMMA4E
COe3h9+CHRLMAgITiDAsBgsqhkiG9w0BCRADCTAdBglghkgBZQMEAQIEEBHZXFIK
Or8isjBw7/R9bvYEIBg5IifDwiwqpp8qsHckdarYWJzNu0yu0w3Cyx2DlGw3MFsG
CSqGSIb3DQEHATA8BgsqhkiG9w0BCRADDzAtMB0GCWCGSAFlAwQBAgQQtyUCdoQ8
WBulMOJAJ+7DBjAMBggrBgEFBQgBAgUAgBCYNg8MeWI2tS0tnhxihR4QBBSIpMGy
ungbyvkUsOX80Y34AuKyng==
-----END PKCS7-----
An S/MIME client SHOULD announce the set of cryptographic functions that it supports by using the SMIMECapabilities attribute [SMIME]. If the client wishes to indicate support for MAC-authenticated encryption, the capabilities attribute MUST contain the authEnc128 and/or authEnc256 OID specified above with algorithm parameters ABSENT. The other algorithms used in the authEnc algorithm, such as the MAC and encryption algorithm, are selected based on the presence of these algorithms in the SMIMECapabilities attribute or by mutual agreement.
S/MIME客户端应该通过使用SMIMECapabilities属性[SMIME]来宣布它支持的加密函数集。如果客户端希望指示支持MAC身份验证加密，则“能力”属性必须包含上面指定的authEnc128和/或authEnc256 OID，且不包含算法参数。authEnc算法中使用的其他算法，如MAC和加密算法，是根据这些算法在SMIMECapability属性中的存在情况或通过相互协商选择的。
Unlike other CMS authenticated-data mechanisms, such as SignedData and AuthenticatedData, AuthEnv's primary transformation isn't authentication but encryption; so AuthEnvData may decrypt successfully (in other words, the primary data transformation present in the mechanism will succeed), but the secondary function of authentication using the MAC value that follows the encrypted data could still fail. This can lead to a situation in which an implementation might output decrypted data before it reaches and verifies the MAC value. In other words, decryption is performed inline and the result is available immediately, while the
与其他CMS认证数据机制（如SignedData和AuthenticatedData）不同，AuthEnv的主要转换不是认证而是加密；因此，AuthEnvData可能会成功解密（换句话说，机制中的主要数据转换将成功），但使用加密数据后面的MAC值进行身份验证的次要功能仍可能失败。这可能导致一种情况，即实现可能在达到并验证MAC值之前输出解密数据。换句话说，解密是内联执行的，结果立即可用，而
authentication result isn't available until all of the content has been processed. If the implementation prematurely provides data to the user and later comes back to inform them that the earlier data was, in retrospect, tainted, this may cause users to act prematurely on the tainted data.
在处理所有内容之前，身份验证结果不可用。如果实施过早地向用户提供数据，然后回来通知他们以前的数据（事后回顾）已受污染，这可能会导致用户过早地对受污染的数据采取行动。
This situation could occur in a streaming implementation where data has to be made available as soon as possible (so that the initial plaintext is emitted before the final ciphertext and MAC value are read), or one where the quantity of data involved rules out buffering the recovered plaintext until the MAC value can be read and verified. In addition, an implementation that tries to be overly helpful may treat missing non-payload trailing data as non-fatal, allowing an attacker to truncate the data somewhere before the MAC value and thereby defeat the data authentication. This is complicated even further by the fact that an implementation may not be able to determine, when it encounters truncated data, whether the remainder (including the MAC value) will arrive presently (a non-failure) or whether it's been truncated by an attacker and should therefore be treated as a MAC failure. (Note that this same issue affects other types of data authentication like signed and MACed data as well, since an over-optimistic implementation may return data to the user before checking for a verification failure is possible.)
这种情况可能发生在必须尽快提供数据（以便在读取最终密文和MAC值之前发出初始明文）的流式实现中，或者在涉及的数据量排除缓冲恢复的明文直到可以读取和验证MAC值的情况下。此外，试图提供过度帮助的实现可能会将丢失的非有效负载跟踪数据视为非致命数据，从而允许攻击者截断MAC值之前的某个位置的数据，从而破坏数据身份验证。更为复杂的是，当实现遇到截断数据时，可能无法确定剩余数据（包括MAC值）是否将立即到达（非故障），或者是否已被攻击者截断，因此应将其视为MAC故障。（请注意，这个问题也会影响其他类型的数据身份验证，如签名和MACE数据，因为过于乐观的实现可能会在检查验证失败之前将数据返回给用户。）
The exact solution to these issues is somewhat implementation-specific, with some suggested mitigations being as follows: implementations should buffer the entire message if possible and verify the MAC before performing any decryption. If this isn't possible due to streaming or message-size constraints, then implementations should consider breaking long messages into a sequence of smaller ones, each of which can be processed atomically as above. If even this isn't possible, then implementations should make obvious to the caller or user that an authentication failure has occurred and that the previously returned or output data shouldn't be used. Finally, any data-formatting problem, such as obviously truncated data or missing trailing data, should be treated as a MAC verification failure even if the rest of the data was processed correctly.
这些问题的确切解决方案在某种程度上是特定于实现的，建议的缓解措施如下：实现应尽可能缓冲整个消息，并在执行任何解密之前验证MAC。如果这是不可能的，因为流或消息大小的限制，那么实现应该考虑打破长消息成一个较小的序列，其中每一个都可以如上所述原子处理。如果这甚至不可能，那么实现应该向调用方或用户表明身份验证失败已经发生，并且不应该使用以前返回的或输出的数据。最后，任何数据格式问题，例如明显截断的数据或缺少尾随数据，都应视为MAC验证失败，即使其余数据已正确处理。
This document contains two algorithm identifiers defined by the S/MIME Working Group Registrar in an arc delegated by RSA to the S/MIME Working Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0).
本文档包含由S/MIME工作组注册员在RSA委托给S/MIME工作组的arc中定义的两个算法标识符：iso（1）成员机构（2）us（840）rsadsi（113549）pkcs（1）pkcs-9（9）smime（16）模块（0）。
The author would like to thank Jim Schaad and the members of the S/MIME mailing list for their feedback on this document, and David Ireland for help with the test vectors.
作者要感谢Jim Schaad和S/MIME邮件列表的成员对本文档的反馈，以及David Ireland对测试向量的帮助。
[AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[AuthEnv]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，2007年11月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2", RFC 2898, September 2000.
[PBKDF2]Kaliski，B.，“PKCS#5：基于密码的加密规范第2版”，RFC 28982000年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，2010年1月。
[EncryptThenAuth] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Springer-Verlag LNCS 2139, August 2001.
[EncryptThenAuth]Krawczyk，H.，“保护通信的加密和认证顺序（或：SSL有多安全？），《斯普林格·维拉格LNCS 2139》，2001年8月。
[Garfinkel] Garfinkel, S., "Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable", May 2005.
[Garfinkel]Garfinkel，S.，“同时安全和可用的计算机系统的设计原则和模式”，2005年5月。
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[HKDF]Krawczyk，H.和P.Erenen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，2010年5月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OpenPGP]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[SSH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Author's Address
作者地址
Peter Gutmann University of Auckland Department of Computer Science New Zealand
古特曼奥克兰大学新西兰计算机系
EMail: pgut001@cs.auckland.ac.nz
EMail: pgut001@cs.auckland.ac.nz