Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 6664 Soaring Hawk Consulting
Category: Informational July 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 6664 Soaring Hawk Consulting
Category: Informational July 2012
ISSN: 2070-1721
S/MIME Capabilities for Public Key Definitions
公钥定义的S/MIME功能
Abstract
摘要
This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used.
本文档为PKIX工作组定义的当前公钥集的ASN.1编码定义了一组安全/多用途Internet邮件扩展（S/MIME）功能类型。这有助于请求者指定响应中使用的公钥和签名算法的信息。“在线证书状态协议算法敏捷性”（RFC 6277）详细说明了使用该算法的示例。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6664.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6664.
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. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4
2. RSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Generic RSA Public Keys . . . . . . . . . . . . . . . . . 4
2.2. RSASSA-PSS Signature Public Keys . . . . . . . . . . . . . 5
2.3. RSAES-OAEP Key Transport Public Keys . . . . . . . . . . . 6
3. Diffie-Hellman Keys . . . . . . . . . . . . . . . . . . . . . 7
3.1. DSA Signature Public Key . . . . . . . . . . . . . . . . . 7
3.2. DH Key Agreement Keys . . . . . . . . . . . . . . . . . . 8
4. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1. Generic Elliptic Curve Keys . . . . . . . . . . . . . . . 9
4.2. Elliptic Curve DH Keys . . . . . . . . . . . . . . . . . . 10
4.3. Elliptic Curve MQV Keys . . . . . . . . . . . . . . . . . 10
5. RSASSA-PSS Signature Algorithm Capability . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 15
Appendix B. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 18
Appendix C. Future Work . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4
2. RSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Generic RSA Public Keys . . . . . . . . . . . . . . . . . 4
2.2. RSASSA-PSS Signature Public Keys . . . . . . . . . . . . . 5
2.3. RSAES-OAEP Key Transport Public Keys . . . . . . . . . . . 6
3. Diffie-Hellman Keys . . . . . . . . . . . . . . . . . . . . . 7
3.1. DSA Signature Public Key . . . . . . . . . . . . . . . . . 7
3.2. DH Key Agreement Keys . . . . . . . . . . . . . . . . . . 8
4. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1. Generic Elliptic Curve Keys . . . . . . . . . . . . . . . 9
4.2. Elliptic Curve DH Keys . . . . . . . . . . . . . . . . . . 10
4.3. Elliptic Curve MQV Keys . . . . . . . . . . . . . . . . . 10
5. RSASSA-PSS Signature Algorithm Capability . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 15
Appendix B. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 18
Appendix C. Future Work . . . . . . . . . . . . . . . . . . . . . 19
In the process of dealing with the Online Certificate Status Protocol (OCSP) agility issues in [RFC6277], it was noted that we really wanted to describe information to be used in selecting a public key, but we did not have any way of doing so. This document fills that hole by defining a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for a small set of public key representations.
在[RFC6277]中处理在线证书状态协议（OCSP）敏捷性问题的过程中，注意到我们确实希望描述选择公钥时使用的信息，但我们没有任何方法。本文档通过为一小部分公钥表示定义一组安全/多用途Internet邮件扩展（S/MIME）功能类型来填补这一漏洞。
S/MIME capabilities were originally defined in [SMIMEv3-MSG] as a way for the sender of an S/MIME message to tell the recipient of the message the set of encryption algorithms that were supported by the sender's system. In the beginning, the focus was primarily on communicating the set of encryption algorithms that were supported by the sender. Over time, it was expanded to allow for an S/MIME client to state that it supported new features such as the compression data type and binary encoded contents. The structure was defined so that parameters can be passed in as part of the capability to allow for subsets of algorithms to be used. This was used for the RC2 encryption algorithm, although only two values out of the set of values were ever used. The goal of restricting the set of values is to allow a client to use a simple binary comparison in order to check
S/MIME功能最初在[SMIMEv3 MSG]中定义为S/MIME消息的发送方告知消息接收方发送方系统支持的加密算法集的一种方式。一开始，重点主要是通信发送方支持的一组加密算法。随着时间的推移，它被扩展为允许S/MIME客户端声明它支持新功能，例如压缩数据类型和二进制编码内容。该结构的定义使得参数可以作为允许使用算法子集的功能的一部分传入。这被用于RC2加密算法，尽管在值集中只使用了两个值。限制值集的目的是允许客户端使用简单的二进制比较来检查
for equality. The client should never need to decode the capability and do an element-by-element comparison. Historically, this has not been a problem as the vast majority of S/MIME capabilities consist of just the algorithm identifier for the algorithm.
为了平等。客户机不应该需要解码功能并进行元素对元素的比较。从历史上看，这并不是一个问题，因为绝大多数S/MIME功能只包含算法的算法标识符。
Many people are under the impression that only a single data structure can be assigned to an object identifier, but this is not the case. As an example, the OID rsaEncryption is used in multiple locations for different data. It represents a public key, a key transport algorithm (in S/MIME), and was originally used in the Public-Key Cryptography Standards (PKCS) #7 specification as a signature value identifier (this has since been changed by the S/MIME specifications). One of the implications is that when mapping an object identifier to a data type structure, the location in the ASN.1 structure needs to be taken into consideration as well.
许多人的印象是，只能将单个数据结构分配给对象标识符，但事实并非如此。例如，OID加密用于不同数据的多个位置。它表示公钥，一种密钥传输算法（在S/MIME中），最初在公钥加密标准（PKCS）#7规范中用作签名值标识符（后来被S/MIME规范更改）。其中一个含义是，在将对象标识符映射到数据类型结构时，还需要考虑ASN.1结构中的位置。
The main body of the text is written using snippets of ASN.1 that are extracted from the ASN.1 2008 module in Appendix A. ASN.1 2008 is used in this document because it directly represents the metadata that is not representable in the 1988 version of ASN.1 but instead is part of the text. In keeping with the current policy of the PKIX working group, the 1988 module along with the text is the normative module. In the event of a conflict between the content of the two modules, the 1988 module is authoritative.
正文使用ASN.1片段编写，这些片段从附录A中的ASN.1 2008模块中提取。本文档中使用ASN.1 2008，因为它直接表示1988版ASN.1中不可表示的元数据，而是文本的一部分。根据PKIX工作组的现行政策，1988模块连同文本一起是规范模块。如果两个模块的内容发生冲突，1988模块具有权威性。
When reading this document, it is assumed that you will have a degree of familiarity with the basic object module that is presented in Section 3 of RFC 5912 [RFC5912]. We use the SMIME-CAPS object in this document; it associates two fields together in a single object.
阅读本文档时，假设您对RFC 5912[RFC5912]第3节中介绍的基本对象模块有一定程度的熟悉。我们在本文档中使用SMIME-CAPS对象；它将两个字段关联到一个对象中。
SMIME-CAPS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id }
SMIME-CAPS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id }
These fields are:
这些字段是：
&id contains an object identifier. When placed in an object set, this element is tagged so that no two elements can be placed in the set that have the same value in the &id field. Note that this is not a restriction saying that only a single object can exist with a single object identifier.
&id包含一个对象标识符。将此元素放置在对象集中时，会对其进行标记，以便在集中不能放置两个在&id字段中具有相同值的元素。请注意，这并不是说只有一个对象可以存在一个对象标识符的限制。
&Type optionally contains an ASN.1 type identifier. If the field &Type is not defined, then the optional parameters field of the AlgorithmIdentifier type would be omitted.
&类型（可选）包含ASN.1类型标识符。如果未定义字段和类型，则将省略AlgorithmIdentifier类型的可选参数字段。
The class also has a specialized syntax for how to define an object in this class. The all uppercase words TYPE IDENTIFIER and BY are syntactic sugar to make it easier to read. The square brackets define optional pieces of the syntax.
该类还有一个专门的语法，用于定义该类中的对象。所有大写单词TYPE IDENTIFIER和BY都是语法上的糖衣，使其更易于阅读。方括号定义了语法的可选部分。
The ASN.1 syntax permits any field in an object to be referenced in another location. This means that if an object called foo has a field named &value, the value can be directly referenced as foo.& value. This means that any updates to values or types are automatically propagated, and we do not need to replicate the data.
ASN.1语法允许在另一个位置引用对象中的任何字段。这意味着，如果名为foo的对象有一个名为&value的字段，则该值可以直接引用为foo&value。这意味着对值或类型的任何更新都会自动传播，我们不需要复制数据。
When capitalized, 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]中的说明进行解释。
There are currently three different public key object identifiers for RSA public keys. These are RSA, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), and RSA Signature Scheme with Appendix - Probabilistic Signature Scheme (RSASSA-PSS).
RSA公钥目前有三种不同的公钥对象标识符。这些是RSA、RSA加密方案-最优非对称加密填充（RSAES-OAEP）和带有附录的RSA签名方案-概率签名方案（RSASSA-PSS）。
Almost all RSA keys that are contained in certificates today use the generic RSA public key format and identifier. This allows for the public key to be used both for key transport and for signature validation (assuming it is compatible with the bits in the key usage extension). The only reason for using one of the more specific public key identifiers is if the user wants to restrict the usage of the RSA public key to a specific algorithm.
如今，证书中包含的几乎所有RSA密钥都使用通用RSA公钥格式和标识符。这允许公钥用于密钥传输和签名验证（假设它与密钥使用扩展中的位兼容）。使用更具体的公钥标识符之一的唯一原因是，如果用户希望将RSA公钥的使用限制为特定算法。
For the generic RSA public key, the S/MIME capability that is advertised is a request for a specific key size to be used. This would normally be used for dealing with a request on the key to be used for a signature that the client would then verify. In general, the user would provide a specific key when a key transport algorithm is being considered.
对于通用RSA公钥，公布的S/MIME功能是对要使用的特定密钥大小的请求。这通常用于处理对用于签名的密钥的请求，然后客户端将验证签名。通常，当考虑密钥传输算法时，用户将提供特定密钥。
The ASN.1 that is used for the generic RSA public key is defined as below:
用于通用RSA公钥的ASN.1定义如下：
scap-pk-rsa SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsa.&id
}
scap-pk-rsa SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsa.&id
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-rsa is a new SMIME-CAPS object. This object associates the existing object identifier (rsaEncryption) used for the public key in certificates (defined in [RFC3279] and [RFC5912]) with a new type defined in this document.
scap pk rsa是一个新的SMIME-CAPS对象。此对象将用于证书中公钥的现有对象标识符（RSA加密）（在[RFC3279]和[RFC5912]中定义）与本文档中定义的新类型相关联。
RSAKeyCapabilities carries the set of desired capabilities for an RSA key. The fields of this type are:
RSAKeyCapabilities包含RSA密钥所需的一组功能。此类型的字段包括：
minKeySize contains the minimum length of the RSA modulus to be used. This field SHOULD NOT contain a value less than 1024.
minKeySize包含要使用的RSA模的最小长度。此字段不应包含小于1024的值。
maxKeySize contains the maximum length of the RSA modules that should be used. If this field is absent, then no maximum length is requested/expected. This value is normally selected so as not to cause the current code to run unacceptably long when processing signatures.
maxKeySize包含应使用的RSA模块的最大长度。如果此字段不存在，则不会请求/预期最大长度。通常选择此值是为了在处理签名时不会导致当前代码运行过长。
RSAKeySize provides a set of suggested values to be used. The values 1024, 2048, 3072, 7680, and 15360 are from the NIST guide on signature sizes [NIST-SIZES] while the others are common powers of two that are used. The list is not closed, and other values can be used.
RSAKeySize提供了一组建议使用的值。值1024、2048、3072、7680和15360来自NIST签名大小指南[NIST-sizes]，而其他值是所使用的两个的共同幂。列表未关闭，可以使用其他值。
While one will use the generic RSA public key identifier in a certificate most of the time, the RSASSA-PSS identifier can be used if the owner of the key desires to restrict the usage of the key to just this algorithm. This algorithm does have the ability to place a
虽然大多数情况下证书中都会使用通用RSA公钥标识符，但如果密钥所有者希望将密钥的使用仅限于此算法，则可以使用RSASSA-PSS标识符。此算法确实能够放置
set of algorithm parameters in the public key info structure, but they have not been included in this location as the same information should be carried in the signature S/MIME capabilities instead.
公钥信息结构中的一组算法参数，但未包含在此位置，因为签名S/MIME功能中应包含相同的信息。
The ASN.1 that is used for the RSASSA-PSS public key is defined below:
用于RSASSA-PSS公钥的ASN.1定义如下：
scap-pk-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaSSA-PSS.&id
}
scap-pk-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaSSA-PSS.&id
}
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-rsaSSA-PSS is a new SMIME-CAPS object. This object associates the existing object identifier (id-RSASSA-PSS) used for the public key certificates (defined in [RFC4055] and [RFC5912]) with type RSAKeyCapabilities.
scap pk rsaSSA PSS是一个新的SMIME-CAPS对象。此对象将用于公钥证书（在[RFC4055]和[RFC5912]中定义）的现有对象标识符（id RSASSA PSS）与类型RSAKeyCapabilities相关联。
While one will use the generic RSA public key identifier in a certificate most of the time, the RSAES-OAEP identifier can be used if the owner of the key desires to restrict the usage of the key to just this algorithm. This algorithm does have the ability to place a set of algorithm parameters in the public key info structure, but they have not been included in this location as the same information should be carried in the key transport S/MIME capabilities instead.
虽然大多数情况下证书中都会使用通用RSA公钥标识符，但如果密钥所有者希望将密钥的使用仅限于此算法，则可以使用RSAES-OAEP标识符。该算法确实能够在公钥信息结构中放置一组算法参数，但它们并未包含在此位置，因为相同的信息应在密钥传输S/MIME功能中携带。
The ASN.1 that is used for the RSAES-OAEP public key is defined below:
用于RSAES-OAEP公钥的ASN.1定义如下：
scap-pk-rsaES-OAEP SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaES-OAEP.&id
}
scap-pk-rsaES-OAEP SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaES-OAEP.&id
}
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-rsaES-OAEP is a new SMIME-CAPS object. This object associates the existing object identifier (id-RSAES-OAEP) used for the public key certificates (defined in [RFC4055] and [RFC5912]) with type RSAKeyCapabilities.
scap pk rsaES OAEP是一个新的SMIME-CAPS对象。此对象将用于公钥证书（在[RFC4055]和[RFC5912]中定义）的现有对象标识符（id RSAES OAEP）与类型RSAKeyCapabilities相关联。
There are currently two Diffie-Hellman (DH) public key object identifiers. These are DH key agreement and Digital Signature Standard (DSA).
目前有两个Diffie-Hellman（DH）公钥对象标识符。这些是DH密钥协议和数字签名标准（DSA）。
This public key type is used for the validation of DSA signatures.
此公钥类型用于验证DSA签名。
The ASN.1 that is used for DSA keys is defined below:
用于DSA密钥的ASN.1定义如下：
scap-pk-dsa SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dsa.&id
}
scap-pk-dsa SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dsa.&id
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-dsa is a new SMIME-CAPS object. This object associates the existing object identifier (id-dsa) used for the public key in certificates (defined in [RFC3279] and [RFC5912]) with a new type defined here, DSAKeyCapabilities.
scap pk dsa是一个新的SMIME-CAPS对象。此对象将用于证书中公钥的现有对象标识符（id dsa）（在[RFC3279]和[RFC5912]中定义）与此处定义的新类型DSAKeyCapabilities相关联。
DSAKeyCapabilities carries the desired set of capabilities for the DSA key. The fields of this type are:
DSAKeyCapabilities为DSA密钥提供所需的一组功能。此类型的字段包括：
keySizes is used when only a key size is needed to be specified and not a specific group. It is expected that this would be the most commonly used of the two options. In key sizes, the fields are used as follows:
当只需要指定密钥大小而不需要指定特定组时，使用keySizes。预计这将是两种选择中最常用的。在键大小中，字段的使用方式如下：
minKeySize contains the minimum length of the DSA modulus to be used.
minKeySize包含要使用的DSA模数的最小长度。
maxKeySize contains the maximum length of the DSA modules that should be used. If this field is absent, then no maximum length is requested/expected.
maxKeySize包含应使用的DSA模块的最大长度。如果此字段不存在，则不会请求/预期最大长度。
maxSizeP contains the maximum length of the value p that should be used. If this field is absent, then no maximum length is imposed.
maxSizeP包含应使用的值p的最大长度。如果该字段不存在，则不会施加最大长度。
maxSizeQ contains the maximum length of the value q that should be used. If this field is absent, then no maximum length is imposed.
maxSizeQ包含应使用的值q的最大长度。如果该字段不存在，则不会施加最大长度。
maxSizeG contains the maximum length of the value g that should be used. If this field is absent, then no maximum length is imposed.
maxSizeG包含应使用的值g的最大长度。如果该字段不存在，则不会施加最大长度。
keyParams contains the exact set of DSA for the key used to sign the message. This field is provided for completeness and to match the fields for Elliptic Curve; however, it is expected that usage of this field will be extremely rare.
keyParams包含用于签名消息的密钥的确切DSA集。提供此字段是为了完整性和匹配椭圆曲线的字段；然而，预计这一领域的使用将极为罕见。
This public key type is used with the DH key agreement algorithm.
此公钥类型与DH密钥协商算法一起使用。
The ASN.1 that is used for DH keys is defined below:
用于DH密钥的ASN.1定义如下：
scap-pk-dh SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dh.&id
}
scap-pk-dh SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dh.&id
}
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-dh is a new SMIME-CAPS object. This object associates the existing object identifier (dhpublicnumber) used for the public key algorithm in the certificates (defined in [RFC3279] and [RFC5912]) with a new type defined above, DSAKeyCapabilities.
scap pk dh是一个新的SMIME-CAPS对象。此对象将证书（在[RFC3279]和[RFC5912]中定义）中用于公钥算法的现有对象标识符（dhpublicnumber）与上面定义的新类型DSAKeyCapabilities相关联。
There are currently three Elliptic Curve Cryptography (ECC) public key object identifiers. These are EC, EC-DH, and Elliptic Curve Menezes-Qu-Vanstone (EC-MQV).
目前有三种椭圆曲线密码（ECC）公钥对象标识符。这些是EC、EC-DH和椭圆曲线Menezes Qu Vanstone（EC-MQV）。
Almost all ECC keys that are contained in certificates today use the generic ECC public key format and identifier. This allows for the public key to be used both for key agreement and for signature validation (assuming the appropriate bits are in the certificate). The only reason for using one of the more specific public key identifier is if the user wants to restrict the usage of the ECC public key to a specific algorithm.
如今，证书中包含的几乎所有ECC密钥都使用通用ECC公钥格式和标识符。这允许公钥用于密钥协商和签名验证（假设证书中有适当的位）。使用更具体的公钥标识符之一的唯一原因是，如果用户希望将ECC公钥的使用限制为特定算法。
For the generic ECC public key, the S/MIME capability that is advertised is a request for a specific group to be used.
对于通用ECC公钥，公布的S/MIME功能是对要使用的特定组的请求。
The ASN.1 that is used for the generic ECC public key is defined below:
用于通用ECC公钥的ASN.1定义如下：
scap-pk-ec SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ec.&id
}
scap-pk-ec SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ec.&id
}
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-ec is a new SMIME-CAPS object. This object associates the existing object identifier (id-ecPublicKey) used for the public key algorithm in the certificates (defined in [RFC5480] and [RFC5912]) with the new type EC-SMimeCaps.
scap pk ec是一个新的SMIME-CAPS对象。此对象将证书（在[RFC5480]和[RFC5912]中定义）中用于公钥算法的现有对象标识符（id ecPublicKey）与新类型EC SMimeCaps相关联。
EC-SMimeCaps carries a sequence of at least one ECParameters structure. This allows for multiple curves to be requested in a single capability request. A maximum/minimum style of specifying sizes is not provided as much greater care is required in selecting a specific curve than is needed to create the parameters for a DSA/DH key. As specified in [RFC5480], for PKIX-compliant certificates, only the namedCurve choice of ECParameters is expected to be used.
EC SMimeCaps承载至少一个ECParameters结构的序列。这允许在单个能力请求中请求多条曲线。没有提供指定大小的最大/最小样式，因为在选择特定曲线时需要比为DSA/DH关键点创建参数时更加小心。如[RFC5480]中所述，对于符合PKIX的证书，预期仅使用ECParameters的namedCurve选项。
This public key type is used with the Elliptic Curve Diffie-Hellman key agreement algorithm.
这种公钥类型与椭圆曲线Diffie-Hellman密钥协商算法一起使用。
The ASN.1 that is used for EC-DH keys is defined below:
用于EC-DH密钥的ASN.1定义如下：
scap-pk-ecDH SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecDH.&id
}
scap-pk-ecDH SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecDH.&id
}
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-ecDH is a new SMIME-CAPS object. This object associates the existing object identifier (id-ecDH) used for the public key algorithm in the certificate (defined in [RFC5480] and [RFC5912]) with the same type structure used for public keys.
scap pk ecDH是一个新的SMIME-CAPS对象。此对象将证书（在[RFC5480]和[RFC5912]中定义）中用于公钥算法的现有对象标识符（id ecDH）与用于公钥的相同类型结构相关联。
This public key type is used with the Elliptic Curve MQV key agreement algorithm.
此公钥类型与椭圆曲线MQV密钥协商算法一起使用。
The ASN.1 that is used for EC-MQV keys is defined below:
用于EC-MQV密钥的ASN.1定义如下：
scap-pk-ecMQV SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecMQV.&id
}
scap-pk-ecMQV SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecMQV.&id
}
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-pk-ecMQV is a new SMIME-CAPS object. This object associates the existing object identifier (id-ecMQV) used for the public key algorithm in the certificate (defined in [RFC5480] and [RFC5912]) with the same type structure used for public keys.
scap pk ecMQV是一个新的SMIME-CAPS对象。此对象将证书（在[RFC5480]和[RFC5912]中定义）中用于公钥算法的现有对象标识符（id ecMQV）与用于公钥的相同类型结构相关联。
This document defines a new SMIMECapability for the RSASSA-PSS signature algorithm. One already exists in [RFC4055] where the parameters field is not used.
本文档为RSASSA-PSS签名算法定义了一种新的SMIMECapability。[RFC4055]中已存在一个参数字段，其中未使用参数字段。
When the S/MIME group defined an S/MIME capability for the RSASSA-PSS signature algorithm, it was done in the context of how S/MIME defines and uses S/MIME capabilities. When placed in an S/MIME message [SMIME-MSG] or in a certificate [RFC4262], it is always placed in a
当S/MIME组为RSASSA-PSS签名算法定义S/MIME功能时，它是在S/MIME如何定义和使用S/MIME功能的上下文中完成的。当放置在S/MIME消息[SMIME-MSG]或证书[RFC4262]中时，它总是放置在
sequence of capabilities. This means that one could place the identifier for RSASSA-PSS in the sequence along with the identifier for MD5, SHA-1, and SHA-256. The assumption was then made that one could compute the matrix of all answers, and the publisher would support all elements in the matrix. This has the possibility that the publisher could accidentally publish a point in the matrix that is not supported.
能力的顺序。这意味着可以将RSASSA-PSS的标识符与MD5、SHA-1和SHA-256的标识符一起按顺序放置。然后假设可以计算所有答案的矩阵，出版商将支持矩阵中的所有元素。这可能会导致发布者意外发布矩阵中不受支持的点。
In this situation, there is only a single item that is published. This means that we need to publish all of the associated information along with the identifier for the signature algorithm in a single entity. For this reason, we now define a new parameter type to be used as the SMIMECapability type, which contains a hash identifier and a mask identifier. The ASN.1 used for this is as follows:
在这种情况下，只发布一个项目。这意味着我们需要在单个实体中发布所有相关信息以及签名算法的标识符。因此，我们现在定义一个新的参数类型作为SMIMECapability类型，它包含一个哈希标识符和一个掩码标识符。用于此目的的ASN.1如下所示：
scap-sa-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RsaSsa-Pss-sig-caps
IDENTIFIED BY sa-rsaSSA-PSS.&id
}
scap-sa-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RsaSsa-Pss-sig-caps
IDENTIFIED BY sa-rsaSSA-PSS.&id
}
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg SMIMECapability{{ MaskAlgorithmSet }},
maskAlg SMIMECapability{{ ... }} OPTIONAL,
trailerField INTEGER DEFAULT 1
}
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg SMIMECapability{{ MaskAlgorithmSet }},
maskAlg SMIMECapability{{ ... }} OPTIONAL,
trailerField INTEGER DEFAULT 1
}
scap-mf-mgf1 SMIME-CAPS ::= {
TYPE SMIMECapability{{ ... }}
IDENTIFIED BY id-mgf1
}
scap-mf-mgf1 SMIME-CAPS ::= {
TYPE SMIMECapability{{ ... }}
IDENTIFIED BY id-mgf1
}
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...}
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...}
In the above ASN.1, we have defined the following:
在上述ASN.1中，我们定义了以下内容：
scap-sa-rsaSSA-PSS is a new SMIME-CAPS object. This object associates the existing object identifier (id-RSASSA-PSS) used for the signature algorithm (defined in [RFC4055] and [RFC5912]) with the new type RsaSsa-Pss-sig-caps.
scap sa rsaSSA PSS是一个新的SMIME-CAPS对象。此对象将用于签名算法（在[RFC4055]和[RFC5912]中定义）的现有对象标识符（id RSASSA PSS）与新型RSASSA PSS sig caps相关联。
RsaSsa-Pss-sig-caps carries the desired set of capabilities for the RSASSA-PSS signature algorithm. The fields of this type are:
RsaSsa Pss sig caps具有RsaSsa-Pss签名算法所需的一组功能。此类型的字段包括：
hashAlg contains the S/MIME capability for the hash algorithm we are declaring we support with the RSASSA-PSS signature algorithm.
hashAlg包含我们声明支持RSASSA-PSS签名算法的哈希算法的S/MIME功能。
maskAlg contains the S/MIME capability for the mask algorithm we are declaring we support with the RSASSA-PSS signature algorithm.
maskAlg包含我们声明支持RSASSA-PSS签名算法的掩码算法的S/MIME功能。
trailerField specifies which trailer field algorithm is being supported. This MUST be the value 1.
trailerField指定支持哪种拖车字段算法。这必须是值1。
NOTE: In at least one iteration of the design, we used a sequence of hash identifiers and a sequence of masking functions and again made the assumption that the entire matrix would be supported. This has been removed at this point since the original intent of S/MIME capabilities is that one should be able to do a binary comparison of the DER encoding of the field and determine a specific capability was published. We could return to using the sequence if we wanted to lose the ability to do a binary compare but needed to shorten the encodings. This does not currently appear to be an issue at this point.
注意：在设计的至少一次迭代中，我们使用了一系列散列标识符和一系列掩蔽函数，并再次假设整个矩阵将得到支持。由于S/MIME功能的初衷是能够对字段的DER编码进行二进制比较，并确定是否发布了特定的功能，因此现在已经删除了这一点。如果我们想失去进行二进制比较的能力，但需要缩短编码，我们可以重新使用序列。目前这似乎不是一个问题。
This document provides new fields that can be placed in an S/MIME capabilities sequence. There are number of considerations that need to be taken into account when doing this.
本文档提供了可以按S/MIME功能顺序放置的新字段。在执行此操作时，需要考虑许多因素。
As mentioned above, we have defined data structures to be associated with object identifiers in cases where an association already exists. When either encoding or decoding structures, care needs to be taken that the association used is one appropriate for the location in the surrounding ASN.1 structure. This means that one needs to make sure that only public keys are placed in public key locations, signatures are placed in signature locations, and S/MIME capabilities are placed in SMIMECapability locations. Failure to do so will create decode errors at best and can cause incorrect behavior at worst.
如上所述，我们已经定义了在关联已经存在的情况下与对象标识符关联的数据结构。在编码或解码结构时，需要注意所使用的关联是否适合周围ASN.1结构中的位置。这意味着需要确保只有公钥被放置在公钥位置，签名被放置在签名位置，S/MIME功能被放置在SMIMECapability位置。如果不这样做，最多会产生解码错误，最坏情况下会导致错误行为。
The more specific the information that is provided in an S/MIME Capabilities field, the better the end results are going to be. Specifying a signature algorithm means that there are no questions for the receiver that the signature algorithm is supported. Signature algorithms can be implied by specifying both public key algorithms and hash algorithms together. If the list includes RSA v1.5, EC-DSA, SHA-1, and SHA-256, the implication is that all four values in the cross section are supported by the sender. If the sender does not support EC-DSA with SHA-1, this would lead to a situation where the recipient uses a signature algorithm that the sender does not support. Omitting SHA-1 from the list may lead to the problem where both entities support RSA v1.5 with SHA-1 as their only common algorithm, but this is no longer discoverable by the recipient.
S/MIME功能字段中提供的信息越具体，最终结果就越好。指定签名算法意味着接收方不存在支持签名算法的问题。签名算法可以通过同时指定公钥算法和哈希算法来隐含。如果列表包括RSA v1.5、EC-DSA、SHA-1和SHA-256，则意味着发送程序支持横截面中的所有四个值。如果发件人不支持带有SHA-1的EC-DSA，这将导致收件人使用发件人不支持的签名算法的情况。从列表中省略SHA-1可能会导致以下问题：两个实体都支持RSA v1.5，SHA-1是它们唯一的通用算法，但接收者不再能够发现这一点。
As a general rule, providing more information about the algorithms that are supported is preferable. The more choices that are provided the recipient, the greater the likelihood that a common algorithm with good security can be used by both parties. However, one should avoid being exhaustive in providing the list of algorithms to the recipient. The greater the number of algorithms that are passed, the more difficult it is for a recipient to make intelligent decisions about which algorithm to use. This is a more significant problem when there are more than two entities involved in the "negotiation" of a common algorithm to be used (such as sending an encrypted S/MIME message where a common content encryption algorithm is needed). The larger the set of algorithms and the more recipients involved, the more memory and processing time will be needed in order to complete the decision-making process.
一般来说，最好提供更多关于所支持算法的信息。接收方提供的选择越多，双方使用具有良好安全性的通用算法的可能性就越大。然而，在向接收者提供算法列表时应避免穷尽。传递的算法数量越多，接收者就越难明智地决定使用哪种算法。当有两个以上的实体参与要使用的通用算法的“协商”时，这是一个更重要的问题（例如，在需要通用内容加密算法的情况下发送加密的S/MIME消息）。算法集越大，涉及的接收者越多，完成决策过程所需的内存和处理时间就越多。
The S/MIME capabilities are defined so that the order of algorithms in the sequence is meant to encode a preference order by the sender of the sequence. Many entities will ignore the order preference when making a decision either by using their own preferred order or using a random decision from a matrix.
S/MIME功能的定义使得序列中的算法顺序意味着由序列的发送方对优先顺序进行编码。许多实体在使用自己的偏好顺序或使用矩阵中的随机决策进行决策时，会忽略顺序偏好。
[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月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055]Schaad，J.，Kaliski，B.，和R.Housley，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[NIST-SIZES] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management -- Part 1: General", NIST Special Publication 800-57, March 2007.
[NIST-SIZES]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“密钥管理建议——第1部分：概述”，NIST特别出版物800-57，2007年3月。
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, December 2005.
[RFC4262]Santesson，S.，“用于安全/多用途Internet邮件扩展（S/MIME）功能的X.509证书扩展”，RFC 42622005年12月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
[RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011.
[RFC6277]Santesson，S.和P.Hallam Baker，“在线证书状态协议算法敏捷性”，RFC 6277，2011年6月。
[SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME-MSG]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[SMIMEv3-MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[SMIMEv3 MSG]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
This appendix contains a module compatible with the work done to update the PKIX ASN.1 modules to recent versions of the ASN.1 specifications [RFC5912]. This appendix is to be considered informational per the current direction of the PKIX working group.
本附录包含一个模块，该模块与将PKIX ASN.1模块更新为最新版本的ASN.1规范[RFC5912]的工作兼容。根据PKIX工作组的当前指示，本附录将被视为信息性附录。
PUBLIC-KEY-SMIME-CAPABILITIES
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pubKeySMIMECaps-08(78) }
DEFINITIONS ::=
BEGIN
IMPORTS
SMIME-CAPS, PUBLIC-KEY, SMIMECapability
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
PUBLIC-KEY-SMIME-CAPABILITIES
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pubKeySMIMECaps-08(78) }
DEFINITIONS ::=
BEGIN
IMPORTS
SMIME-CAPS, PUBLIC-KEY, SMIMECapability
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
pk-rsa, pk-dsa, pk-dh, pk-ec, pk-ecDH, pk-ecMQV, ECParameters
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
pk-rsa, pk-dsa, pk-dh, pk-ec, pk-ecDH, pk-ecMQV, ECParameters
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
pk-rsaSSA-PSS, pk-rsaES-OAEP, sa-rsaSSA-PSS,
HashAlgorithms, id-mgf1
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54)}
;
pk-rsaSSA-PSS, pk-rsaES-OAEP, sa-rsaSSA-PSS,
HashAlgorithms, id-mgf1
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54)}
;
--
-- Define a set containing all of the S/MIME capabilities defined
-- by this document.
--
--
-- Define a set containing all of the S/MIME capabilities defined
-- by this document.
--
SMimeCaps SMIME-CAPS ::= {
PubKeys-SMimeCaps |
scap-sa-rsaSSA-PSS
}
SMimeCaps SMIME-CAPS ::= {
PubKeys-SMimeCaps |
scap-sa-rsaSSA-PSS
}
PubKeys-SMimeCaps SMIME-CAPS ::= {
scap-pk-rsa | scap-pk-rsaSSA-PSS |
scap-pk-dsa |
scap-pk-ec | scap-pk-ecDH | scap-pk-ecMQV
PubKeys-SMimeCaps SMIME-CAPS ::= {
scap-pk-rsa | scap-pk-rsaSSA-PSS |
scap-pk-dsa |
scap-pk-ec | scap-pk-ecDH | scap-pk-ecMQV
}
}
-- -- We defined RSA keys from the modules in RFC 3279 and RFC 4055. --
----我们根据RFC 3279和RFC 4055中的模块定义了RSA密钥--
scap-pk-rsa SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsa.&id
}
scap-pk-rsa SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsa.&id
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
scap-pk-rsaES-OAEP SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaES-OAEP.&id
}
scap-pk-rsaES-OAEP SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaES-OAEP.&id
}
scap-pk-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaSSA-PSS.&id
}
scap-pk-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaSSA-PSS.&id
}
scap-sa-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RsaSsa-Pss-sig-caps
IDENTIFIED BY sa-rsaSSA-PSS.&id
}
scap-sa-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RsaSsa-Pss-sig-caps
IDENTIFIED BY sa-rsaSSA-PSS.&id
}
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg SMIMECapability{{ MaskAlgorithmSet }},
maskAlg SMIMECapability{{ ... }} OPTIONAL,
trailerField INTEGER DEFAULT 1
}
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg SMIMECapability{{ MaskAlgorithmSet }},
maskAlg SMIMECapability{{ ... }} OPTIONAL,
trailerField INTEGER DEFAULT 1
}
scap-mf-mgf1 SMIME-CAPS ::= {
TYPE SMIMECapability{{ ... }}
IDENTIFIED BY id-mgf1
}
scap-mf-mgf1 SMIME-CAPS ::= {
TYPE SMIMECapability{{ ... }}
IDENTIFIED BY id-mgf1
}
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...}
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...}
-- -- We define DH/DSA keys from the module in RFC 3279. --
----我们从RFC 3279中的模块定义DH/DSA密钥--
scap-pk-dsa SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dsa.&id
}
scap-pk-dsa SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dsa.&id
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
scap-pk-dh SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dh.&id
}
scap-pk-dh SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dh.&id
}
-- -- We define Elliptic Curve keys from the module in RFC 3279. --
----我们从RFC 3279中的模块定义椭圆曲线密钥--
scap-pk-ec SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ec.&id
}
scap-pk-ec SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ec.&id
}
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
scap-pk-ecDH SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecDH.&id
}
scap-pk-ecDH SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecDH.&id
}
scap-pk-ecMQV SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecMQV.&id
}
scap-pk-ecMQV SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecMQV.&id
}
END
终止
This appendix contains the normative ASN.1 module for this document.
本附录包含本文件的标准ASN.1模块。
PUBLIC-KEY-SMIME-CAPABILITIES-88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pubKeySMIMECaps-88(77) }
DEFINITIONS ::=
BEGIN
IMPORTS
PUBLIC-KEY-SMIME-CAPABILITIES-88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pubKeySMIMECaps-88(77) }
DEFINITIONS ::=
BEGIN
IMPORTS
ECParameters
FROM PKIX1Algorithms2008
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
45 }
ECParameters
FROM PKIX1Algorithms2008
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
45 }
id-mgf1
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
id-mgf1
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
;
;
-- -- We define RSA keys from the modules in RFC 3279 and RFC 4055. --
----我们从RFC 3279和RFC 4055中的模块定义RSA密钥--
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
RsaSsa-Pss-sig-caps ::= SEQUENCE {
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg AlgorithmIdentifier, maskAlg AlgorithmIdentifier OPTIONAL, trailerField INTEGER DEFAULT 1 }
hashAlg算法标识符，maskAlg算法标识符可选，trailerField整数默认值1}
-- -- We define DH/DSA keys from the module in RFC 3279. --
----我们从RFC 3279中的模块定义DH/DSA密钥--
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
-- -- We define Elliptic Curve keys from the module in RFC 3279. --
----我们从RFC 3279中的模块定义椭圆曲线密钥--
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
END
终止
A future revision of [RFC5912] should be done at some point to expand the definition of the PUBLIC-KEY class and allow for an SMIMECapability to be included in the class definition. This would encourage people to think about this as an issue when defining new public key structures in the future.
[RFC5912]的未来版本应该在某个时候进行，以扩展公钥类的定义，并允许在类定义中包含SMIMECapability。这将鼓励人们在将来定义新的公钥结构时考虑这一问题。
Author's Address
作者地址
Jim Schaad Soaring Hawk Consulting
吉姆·沙德·霍克咨询公司
EMail: ietf@augustcellars.com
EMail: ietf@augustcellars.com