Network Working Group M. Blinov
Request for Comments: 4212 Guardeonic Solutions
Category: Informational C. Adams
University of Ottawa
October 2005
Network Working Group M. Blinov
Request for Comments: 4212 Guardeonic Solutions
Category: Informational C. Adams
University of Ottawa
October 2005
Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols
使用X.509（PKIX）证书管理协议的公钥基础结构的替代证书格式
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
IESG Note
IESG注释
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
本文件不适用于任何级别的互联网标准。IETF不承认对本文件适用于任何目的的任何了解，特别注意到IETF没有对安全性、拥塞控制或与已部署协议的不当交互等事项进行审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。
Abstract
摘要
The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC).
Internet工程任务组（IETF）的使用X.509（PKIX）的公钥基础设施工作组定义了许多证书管理协议。这些协议主要关注X.509v3公钥证书。但是，有时也需要以其他格式管理证书。本文档指定如何使用多个不同协议使用的证书请求消息格式（CRMF）语法请求此类证书。它还解释了如何将替代证书格式合并到诸如PKIX证书管理协议（PKIX-CMP）和CMS上的证书管理消息（CMC）等流行协议中。
Full certificate life-cycle management in a Public-Key Infrastructure (PKI) requires protocol support in order to achieve automated processing and end user transparency. Such protocols require standardization in order to allow more than one vendor to supply various pieces -- End Entity (EE), Certification Authority (CA), Registration Authority (RA) -- in the PKI deployment of a single organization, or to allow multiple, independently-deployed PKIs to be interconnected usefully.
公钥基础设施（PKI）中的完整证书生命周期管理需要协议支持，以实现自动化处理和最终用户透明度。这样的协议需要标准化，以便允许多个供应商在单个组织的PKI部署中提供各种部件——终端实体（EE）、证书颁发机构（CA）、注册机构（RA），或者允许多个独立部署的PKI有效地互连。
The IETF PKIX (Public-Key Infrastructure using X.509) Working Group currently has several certificate management protocols and certificate request syntax specifications on the standards track. Although these specifications are primarily focused on X.509v3 public-key certificates, some of them can be easily extended to handle certificates in alternative formats as well.
IETF PKIX（使用X.509的公钥基础设施）工作组目前在标准轨道上有几个证书管理协议和证书请求语法规范。尽管这些规范主要关注于X.509v3公钥证书，但其中一些规范也可以轻松扩展以处理其他格式的证书。
This document focuses on a popular certificate request syntax called CRMF (Certificate Request Message Format) [CRMF]. Although the original specification of CRMF is X.509-specific, extensions have already been proposed to allow for alternative certificate templates [CMP]. However, those extensions have only defined a framework; they did not define the exact format to be used for various certificate types.
本文档重点介绍一种流行的证书请求语法，称为CRMF（证书请求消息格式）[CRMF]。尽管CRMF的原始规范特定于X.509，但已经提出了扩展，以允许使用替代证书模板[CMP]。然而，这些扩展只定义了一个框架；他们没有定义用于各种证书类型的确切格式。
This document builds on top of the framework mentioned above and defines how CRMF can be used to request certificates of the following types:
本文档构建在上述框架之上，并定义了如何使用CRMF请求以下类型的证书：
- X.509 attribute certificates [ATTCERT]
- X.509属性证书[ATTCERT]
- OpenPGP certificates [OPENPGP]
- OpenPGP证书[OpenPGP]
The CRMF syntax is used by such popular protocols as PKIX-CMP (PKIX Certificate Management Protocol) [CMP] and CMC (Certificate Management Messages over CMS) [CMC]. This means that CRMF extensions proposed in this document enable these protocols to request certificates of the above types. However, it is not enough to be able to request a certificate. The protocol should be prepared to handle certificates of a particular type and, for example, return them to the user.
CRMF语法由诸如PKIX-CMP（PKIX证书管理协议）[CMP]和CMC（CMS上的证书管理消息）[CMC]等流行协议使用。这意味着本文中提出的CRMF扩展使这些协议能够请求上述类型的证书。但是，仅能够请求证书是不够的。协议应该准备好处理特定类型的证书，例如，将它们返回给用户。
This document proposes extensions to the PKIX-CMP and CMC protocols that are required to manage certificates in alternative formats.
本文档提出了对PKIX-CMP和CMC协议的扩展，这些协议是以替代格式管理证书所必需的。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
One of the features of the CRMF format is its use of the CertTemplate construct, which allows a requester (EE, or RA acting on behalf of an EE) to specify as much or as little as they wish regarding the content of the requested certificate. It is explicitly noted that the CA has final authority over the actual certificate content; that is, the CA may alter certificate fields or may add, delete, or alter extensions according to its operating policy (if the resulting certificate is unacceptable to the EE or RA, then that certificate may be rejected and/or revoked prior to any publication/use).
CRMF格式的一个特点是使用了CertTemplate构造，它允许请求者（EE或代表EE的RA）根据自己的意愿指定与所请求证书内容相关的尽可能多或尽可能少的内容。明确指出，CA对实际证书内容具有最终权限；也就是说，CA可以根据其操作策略更改证书字段或添加、删除或更改扩展（如果生成的证书不被EE或RA接受，则该证书可能在发布/使用之前被拒绝和/或撤销）。
A similar flexibility in the request must be available for
alternative certificate types as well. For this purpose, an
AltCertTemplate extension was introduced in [CMP] as follows (where
id-regCtrl = {1 3 6 1 5 5 7 5 1}, as defined in [CRMF]).
A similar flexibility in the request must be available for
alternative certificate types as well. For this purpose, an
AltCertTemplate extension was introduced in [CMP] as follows (where
id-regCtrl = {1 3 6 1 5 5 7 5 1}, as defined in [CRMF]).
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
-- If certTemplate is an empty SEQUENCE (i.e., all fields
-- omitted), then controls MAY contain the
-- id-regCtrl-altCertTemplate control, specifying a template
-- for a certificate other than an X.509v3 public-key
-- certificate. Conversely, if certTemplate is not empty
-- (i.e., at least one field is present), then controls
-- MUST NOT contain id-regCtrl-altCertTemplate. The new
-- control is defined as follows:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
-- If certTemplate is an empty SEQUENCE (i.e., all fields
-- omitted), then controls MAY contain the
-- id-regCtrl-altCertTemplate control, specifying a template
-- for a certificate other than an X.509v3 public-key
-- certificate. Conversely, if certTemplate is not empty
-- (i.e., at least one field is present), then controls
-- MUST NOT contain id-regCtrl-altCertTemplate. The new
-- control is defined as follows:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
In this section, an AltCertTemplate is specified for each of the alternative certificate types defined in Section 1.
在本节中，为第1节中定义的每种替代证书类型指定了AltCertTemplate。
A CertTemplate for an X.509 attribute certificate can be used by simply defining an object identifier (OID) and corresponding value for use in the id-regCtrl-altCertTemplate control. These are specified as follows.
X.509属性证书的CertTemplate可以通过简单地定义对象标识符（OID）和在id regCtrl altCertTemplate控件中使用的相应值来使用。具体规定如下。
OID:
OID：
id-acTemplate OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 1}
id-acTemplate OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 1}
Value:
价值：
AttCertTemplate ::= SEQUENCE {
version AttCertVersion OPTIONAL,
holder Holder OPTIONAL,
issuer AttCertIssuer OPTIONAL,
signature AlgorithmIdentifier OPTIONAL,
serialNumber CertificateSerialNumber OPTIONAL,
attrCertValidityPeriod OptionalAttCertValidity OPTIONAL,
attributes SEQUENCE OF Attribute OPTIONAL,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
OptionalAttCertValidity ::= SEQUENCE {
notBeforeTime GeneralizedTime OPTIONAL,
notAfterTime GeneralizedTime OPTIONAL
} -- at least one must be present
AttCertTemplate ::= SEQUENCE {
version AttCertVersion OPTIONAL,
holder Holder OPTIONAL,
issuer AttCertIssuer OPTIONAL,
signature AlgorithmIdentifier OPTIONAL,
serialNumber CertificateSerialNumber OPTIONAL,
attrCertValidityPeriod OptionalAttCertValidity OPTIONAL,
attributes SEQUENCE OF Attribute OPTIONAL,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
OptionalAttCertValidity ::= SEQUENCE {
notBeforeTime GeneralizedTime OPTIONAL,
notAfterTime GeneralizedTime OPTIONAL
} -- at least one must be present
Similar to certificate templates defined above, a CertTemplate for an OpenPGP certificate can be used by defining an object identifier (OID) and corresponding value for use in the id-regCtrl-altCertTemplate control. These are specified as follows:
与上面定义的证书模板类似，OpenPGP证书的CertTemplate可以通过定义对象标识符（OID）和在id regCtrl altCertTemplate控件中使用的相应值来使用。具体规定如下：
OID:
OID：
id-openPGPCertTemplateExt OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 2}
id-openPGPCertTemplateExt OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 2}
Value:
价值：
OpenPGPCertTemplateExtended ::= SEQUENCE {
nativeTemplate OpenPGPCertTemplate,
controls Controls OPTIONAL }
OpenPGPCertTemplateExtended ::= SEQUENCE {
nativeTemplate OpenPGPCertTemplate,
controls Controls OPTIONAL }
OpenPGPCertTemplate ::= OCTET STRING
-- contains the OpenPGP CertTemplate data structure defined
-- below (binary format without Radix-64 conversions)
-- encoded as an ASN.1 OCTET STRING
OpenPGPCertTemplate ::= OCTET STRING
-- contains the OpenPGP CertTemplate data structure defined
-- below (binary format without Radix-64 conversions)
-- encoded as an ASN.1 OCTET STRING
Similar to the X.509 CertTemplate, the OpenPGP CertTemplate is an OpenPGP certificate (OpenPGP Transferable Public Key) [OPENPGP] with all fields optional. The essential elements of an OpenPGP CertTemplate are:
与X.509 CertTemplate类似，OpenPGP CertTemplate是一个OpenPGP证书（OpenPGP可转移公钥）[OpenPGP]，所有字段都是可选的。OpenPGP CertTemplate的基本元素包括：
- Zero or one Public Key packet.
- 零或一个公钥数据包。
- Zero or more Direct Key Self Signature packets.
- 零个或多个直接密钥自签名数据包。
- Zero or more Certification Signature packets (only if no User ID packets are present).
- 零个或多个认证签名数据包（仅当不存在用户ID数据包时）。
- Zero or more User ID packets.
- 零个或多个用户ID数据包。
- After each User ID packet, zero or more Certification Signature packets.
- 在每个用户ID数据包之后，零个或多个认证签名数据包。
- Zero or more Subkey packets.
- 零个或多个子密钥数据包。
- After each Subkey packet, zero or one Subkey Binding Signature packet.
- 在每个子密钥包之后，零或一个子密钥绑定签名包。
Each packet in the OpenPGP CertTemplate MUST be a syntactically correct OpenPGP packet. This will enable conformant implementations to use existing PGP libraries for building and parsing OpenPGP CertTemplates.
OpenPGP CertTemplate中的每个数据包必须是语法正确的OpenPGP数据包。这将使一致性实现能够使用现有的PGP库来构建和解析OpenPGP模板。
The following implications of this rule should be explicitly noted:
应明确指出该规则的以下含义：
- Fields for which the OpenPGP specification defines a set of permitted values (e.g., the signature type or the public key algorithm fields of the Signature packet) MUST have a value from the defined set. Even if the requester does not have any particular preferences for, for example, the signature algorithm, it MUST choose one value that is the most desirable.
- OpenPGP规范为其定义了一组允许值的字段（例如，签名包的签名类型或公钥算法字段）必须具有定义集中的值。即使请求者没有任何特定的偏好，例如签名算法，它也必须选择一个最理想的值。
Rationale: An alternative solution could be to define extra "any" values, but this would be a modification of the OpenPGP syntax, which is not considered appropriate in this document.
理由：另一种解决方案可能是定义额外的“任意”值，但这将是对OpenPGP语法的修改，在本文档中不适用。
- All subpackets of the Signature packet defined by the OpenPGP specification as mandatory (e.g., the creation time and the issuer's key id subpackets) MUST be present even though they do not make much sense in the context of a certificate request.
- OpenPGP规范定义为强制性的签名包的所有子包（例如，创建时间和颁发者的密钥id子包）必须存在，即使它们在证书请求的上下文中没有多大意义。
- The number of MPIs at the end of the Key Material and the Signature packets MUST match the number defined by the OpenPGP specification for the given algorithm (the algorithm is controlled by the value of the "algorithm" field). For example, there should be 2 MPIs for DSA signatures. Note that the OpenPGP specification does not define validation rules for the content of those MPIs.
- 密钥材料和签名包末尾的MPI数量必须与OpenPGP规范为给定算法定义的数量相匹配（算法由“算法”字段的值控制）。例如，DSA签名应该有2个MPI。请注意，OpenPGP规范没有为这些MPI的内容定义验证规则。
Though it is not considered appropriate here to define extra "any" values for fields of enumerated types, such values can still be defined for some other fields where the OpenPGP specification is not that strict.
虽然在这里不适合为枚举类型的字段定义额外的“any”值，但是在OpenPGP规范没有那么严格的情况下，仍然可以为其他一些字段定义这些值。
The following extra values are defined in the context of the OpenPGP CertTemplate. Note that these definitions do not modify the syntax of OpenPGP packets, and existing PGP libraries can still be used to generate and parse them.
以下额外值是在OpenPGP CertTemplate的上下文中定义的。请注意，这些定义不会修改OpenPGP数据包的语法，现有的PGP库仍然可以用来生成和解析它们。
- For fields representing time (e.g., signature creation time): the value of zero means "any time".
- 对于表示时间的字段（例如，签名创建时间）：零的值表示“任何时间”。
- For fields holding key IDs: the value of 0xFFFFFFFFFFFFFFFF means "any key id".
- 对于包含键id的字段：0xFFFFFFFFFFFFFFFF的值表示“任意键id”。
- For signature fields: the "any signature" value is encoded as a sequence of MPIs such that:
- 对于签名字段：“任意签名”值编码为MPI序列，以便：
* the number of MPIs matches the number of MPIs defined by the OpenPGP specification for the given algorithm, and
* MPI的数量与OpenPGP规范为给定算法定义的MPI数量相匹配，并且
* the value of each MPI is 0xFF.
* 每个MPI的值为0xFF。
A Signature packet with the "any" value in the signature fields is called a Signature Template.
签名字段中具有“any”值的签名包称为签名模板。
Example: The "any signature" value for a DSA signature would look like [00 08 FF 00 08 FF]
示例：DSA签名的“任意签名”值类似于[00 08 FF 00 08 FF]
- For key material fields: the "any key" value is encoded as a sequence of MPIs such that:
- 对于关键材料字段：“任意关键”值编码为MPI序列，以便：
* the number of MPIs matches the number of MPIs defined by the OpenPGP specification for the given algorithm, and
* MPI的数量与OpenPGP规范为给定算法定义的MPI数量相匹配，并且
* the value of at least one of the MPIs is a bit string with all its bits set to 1.
* 至少一个MPI的值是一个位字符串，其所有位都设置为1。
A Key Material packet with the "any" value in the key material fields is called a Key Template. (See Key Template section for further details.)
在关键材料字段中具有“any”值的关键材料包称为关键模板。（有关更多详细信息，请参见“关键模板”部分。）
Example: The "any key" value for a DSA public key may look like [00 08 FF 00 10 FF FF 00 10 85 34 00 08 FF]
示例：DSA公钥的“任意键”值可能类似于[00 08 FF 00 10 FF 00 10 85 34 00 08 FF]
The following rules apply to the sequence of packets within the OpenPGP CertTemplate:
以下规则适用于OpenPGP CertTemplate中的数据包序列：
- If the Public Key packet is omitted from the OpenPGP CertTemplate, then this CertTemplate does not constrain the value of the public key (i.e., it refers to "any" public key).
- 如果OpenPGP CertTemplate中省略了公钥数据包，则此CertTemplate不会约束公钥的值（即，它指的是“任何”公钥）。
- The order of Signature packets following a User ID packet and the order of User ID packets within the CertTemplate are not important.
- 用户ID数据包之后的签名数据包的顺序以及CertTemplate中用户ID数据包的顺序并不重要。
- If an OpenPGP CertTemplate does not contain any User ID packets, then it refers to "any" user IDs that are relevant to a given request.
- 如果OpenPGP CertTemplate不包含任何用户ID数据包，则它引用与给定请求相关的“任何”用户ID。
Since an OpenPGP certificate can have several certification signatures, the OpenPGP CertTemplate uses Signature Templates to define where certification signatures should occur. The values of the fields of the Signature Templates define the parameters of the new certification signatures. The following rules apply:
由于OpenPGP证书可以有多个认证签名，因此OpenPGP CertTemplate使用签名模板定义认证签名应该出现的位置。签名模板字段的值定义了新证书签名的参数。以下规则适用：
- A Signature Template that is present in the list of signatures following a User ID packet requests that the CA certify this User ID and the public key and replace the Signature Template with the new certification signature. The Signature Template does not mandate the exact place of the certification signature within the list. The certification signature may be inserted at any position within the list of signatures (following the certified User ID packet).
- 在用户ID数据包之后的签名列表中存在的签名模板请求CA认证此用户ID和公钥，并用新的认证签名替换签名模板。签名模板不要求在列表中指定认证签名的确切位置。认证签名可以插入签名列表中的任何位置（在认证用户ID包之后）。
- A Signature Template may be present in the OpenPGP CertTemplate without any preceding User ID packet. In this case, it is assumed that the CA knows the ID(s) of the user by some other means. A Signature Template without a preceding User ID requests that the CA insert all known User IDs of the user into the OpenPGP certificate and certify each of them. The Signature Template defines the parameters of these certification signatures.
- 签名模板可能存在于OpenPGP CertTemplate中，而不存在任何前面的用户ID数据包。在这种情况下，假设CA通过某种其他方式知道用户的ID。没有前面的用户ID的签名模板请求CA将该用户的所有已知用户ID插入OpenPGP证书，并对每个ID进行认证。签名模板定义了这些认证签名的参数。
- If an OpenPGP CertTemplate contains no Signature Templates, then the CA is requested to certify all User IDs that are present in the OpenPGP CertTemplate. Such a CertTemplate does not define parameters of the certification signatures explicitly, but the CA SHOULD use parameters of the certification self-signatures (if present in the CertTemplate) as a guide (e.g., key flags fields).
- 如果OpenPGP CertTemplate不包含签名模板，则要求CA认证OpenPGP CertTemplate中存在的所有用户ID。此类CertTemplate未明确定义认证签名的参数，但CA应使用认证自签名的参数（如果存在于CertTemplate中）作为指南（例如，密钥标志字段）。
- If neither Signature Templates nor User IDs are present in the OpenPGP CertTemplate, then the CA is expected to know the ID(s) of the user by some other means. In this case, the CertTemplate requests that the CA insert these User IDs into the OpenPGP certificate and certify each of them. The parameters of the certification signatures are left to the CA.
- 如果OpenPGP CertTemplate中既没有签名模板也没有用户ID，则CA应通过其他方式了解用户的ID。在这种情况下，CertTemplate请求CA将这些用户ID插入OpenPGP证书，并对每个用户ID进行认证。证书签名的参数留给CA。
If several certification signatures have to be produced according to an OpenPGP CertTemplate, and any of them cannot be granted (even with modifications) for whatever reason, then the whole request with this OpenPGP CertTemplate MUST be rejected.
如果必须根据OpenPGP CertTemplate生成多个认证签名，并且由于任何原因无法授予其中任何一个签名（即使经过修改），则必须拒绝使用此OpenPGP CertTemplate的整个请求。
The client SHOULD provide enough information in its request that the CA could produce a complete OpenPGP certificate. For example, the client SHOULD include in the template all relevant subkeys with their binding signatures so that the CA can include them in the resultant OpenPGP certificate as well. Rationale: In some environments, the CA/RA is responsible for publishing certificates.
客户机应在其请求中提供足够的信息，以便CA能够生成完整的OpenPGP证书。例如，客户端应该在模板中包含所有相关子密钥及其绑定签名，以便CA也可以将它们包含在生成的OpenPGP证书中。理由：在某些环境中，CA/RA负责发布证书。
The OpenPGP CertTemplate can also be used to request certification of centrally-generated keys. This is accomplished by using Key Templates.
OpenPGP CertTemplate还可用于请求集中生成密钥的认证。这是通过使用关键模板实现的。
If the Public Key packet of an OpenPGP CertTemplate is a Key Template, then this OpenPGP CertTemplate requests that the CA/RA generate the key pair prior to certifying it. Fields of the Key Template define parameters of the new key pair as follows (see examples in the Appendix):
如果OpenPGP CertTemplate的公钥数据包是密钥模板，则此OpenPGP CertTemplate请求CA/RA在验证密钥对之前生成密钥对。密钥模板的字段定义新密钥对的参数如下（参见附录中的示例）：
- The "public key algorithm" field specifies the algorithm to be used for the key generation.
- “公钥算法”字段指定用于密钥生成的算法。
- MPI fields with the value of 0xFF ([00 08 FF]) specify that no constraint is placed on the corresponding part of the key.
- 值为0xFF（[00 08 FF]）的MPI字段指定不在键的相应部分放置约束。
- MPI fields that contain any other bit strings in which all bits are set to 1, specify that the corresponding part of the key should be of the same length as the length of the MPI (e.g., the length of the public modulus n of the RSA key).
- 包含所有位都设置为1的任何其他位字符串的MPI字段指定密钥的相应部分的长度应与MPI的长度相同（例如，RSA密钥的公共模n的长度）。
- MPI fields that contain any other values specify that the corresponding part of the key should be of the given value (key generation parameters).
- 包含任何其他值的MPI字段指定密钥的相应部分应为给定值（密钥生成参数）。
In order to return a complete OpenPGP certificate, in addition to certifying the new key and the User ID, the CA (or RA) SHOULD also create a self-signature (i.e., sign the new public key and the User ID with the new private key) and include it after the User ID packet. This SHOULD be done for all User IDs certified by the CA.
为了返回完整的OpenPGP证书，除了认证新密钥和用户ID外，CA（或RA）还应创建自签名（即，使用新私钥对新公钥和用户ID进行签名），并将其包含在用户ID包之后。这应该针对CA认证的所有用户ID进行。
If a Subkey packet of an OpenPGP CertTemplate is a Key Template, then this OpenPGP CertTemplate requests that the CA/RA generate a subkey. Fields of the Key Template define parameters of the new subkey. The new subkey obviously does not have to be certified. However, the CA/RA SHOULD produce the binding signature and include it after the subkey, if the CA/RA knows the user's primary private key (e.g., it was centrally generated as well). Note that if the CA/RA does not know the user's primary private key, then the resultant OpenPGP certificate returned from the CA/RA to the client will be incomplete (i.e., there will be no binding signature for the subkey). It will be the responsibility of the client to produce and add the binding signature and to publish the final OpenPGP certificate.
如果OpenPGP CertTemplate的子密钥包是密钥模板，则此OpenPGP CertTemplate请求CA/RA生成子密钥。密钥模板的字段定义新子密钥的参数。新的子密钥显然不必经过认证。但是，如果CA/RA知道用户的主私钥（例如，它也是集中生成的），CA/RA应该生成绑定签名并将其包含在子密钥之后。请注意，如果CA/RA不知道用户的主私钥，则从CA/RA返回给客户端的结果OpenPGP证书将不完整（即，子密钥将没有绑定签名）。客户端负责生成和添加绑定签名，并发布最终的OpenPGP证书。
If an OpenPGP CertTemplate contains neither PublicKey/Subkey packets nor Key Template packets, then it requests that the CA generate keys/subkeys according to the CA's policies.
如果OpenPGP CertTemplate既不包含公钥/子密钥数据包，也不包含密钥模板数据包，则它会请求CA根据CA的策略生成密钥/子密钥。
The OpenPGPCertTemplateExtended structure enables additional extensions and controls to be added to the basic OpenPGP CertTemplate.
OpenPGPCertTemplateExtended结构允许向基本OpenPGP CertTemplate添加其他扩展和控件。
A conformant implementation is REQUIRED to support OpenPGP CertTemplates that are valid OpenPGP certificates, i.e., that have the following structure (see examples in the Appendix):
需要一致的实现来支持有效的OpenPGP证书的OpenPGP证书模板，即具有以下结构（参见附录中的示例）：
- One Public Key packet (not a Key Template).
- 一个公钥数据包（不是密钥模板）。
- Zero or more Direct Key Self Signature packets (without Signature Templates).
- 零个或多个直接密钥自签名数据包（无签名模板）。
- One or more User ID packets.
- 一个或多个用户ID数据包。
- After each User ID packet, zero or more Certification Signature packets (without Signature Templates).
- 在每个用户ID数据包之后，零个或多个认证签名数据包（无签名模板）。
- Zero or more Subkey packets (without Key Templates).
- 零个或多个子密钥包（无密钥模板）。
- After each Subkey packet, one Subkey Binding Signature packet (not a Signature Template).
- 在每个子密钥包之后，一个子密钥绑定签名包（不是签名模板）。
A conformant implementation is REQUIRED to recognise Key Templates and Signature Templates and is REQUIRED to either support them or reject requests containing them if it does not.
一致性实现需要识别密钥模板和签名模板，并且需要支持它们或拒绝包含它们的请求（如果不支持）。
A CRMF request includes a Proof-of-Possession (POP) field that contains proof that an End Entity has possession of the private key corresponding to the public key for which a certificate is requested.
CRMF请求包括占有证明（POP）字段，该字段包含终端实体拥有与请求证书的公钥对应的私钥的证明。
The following rule applies to this field (with modifications from [CMP]):
以下规则适用于此字段（经[CMP]修改）：
* NOTE: If CertReqMsg certReq certTemplate (or the * altCertTemplate control) contains the subject and * publicKey values, then poposkInput MUST be omitted * and the signature MUST be computed on the DER-encoded * value of CertReqMsg certReq (or the DER-encoded value * of AltCertTemplate).
* 注意：如果CertReqMsg certReq certTemplate（或*altCertTemplate控件）包含subject和*publicKey值，则必须省略poposkInput*并且必须根据CertReqMsg certReq的DER编码*值（或altCertTemplate的DER编码值*）计算签名。
An OpenPGP CertTemplate is considered to satisfy the conditions of this note if it has a Public Key packet (not a Key Template) and at least one User ID packet.
如果OpenPGP CertTemplate具有公钥数据包（不是密钥模板）和至少一个用户ID数据包，则认为它满足本说明的条件。
This section explains how alternative certificate formats may be incorporated into such popular protocols as PKIX-CMP and CMC.
本节介绍如何将替代证书格式合并到PKIX-CMP和CMC等流行协议中。
In PKIX-CMP, the ASN.1 [ASN1] construct, and corresponding comment for a certificate is given as follows.
在PKIX-CMP中，ASN.1[ASN1]构造和证书的相应注释如下所示。
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, WAP WTLS certificates, or
-- other kinds of certificates) within this certificate
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, WAP WTLS certificates, or
-- other kinds of certificates) within this certificate
-- management protocol, should a need ever arise to support
-- such generality.
-- management protocol, should a need ever arise to support
-- such generality.
Building on this framework, this document expands the above CHOICE construct as follows.
在这个框架的基础上，本文扩展了上述选择结构，如下所示。
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate,
x509v2AttCert [0] AttributeCertificate,
-- defined in [ATTCERT]
openPGPCert [2] OpenPGPCert
}
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate,
x509v2AttCert [0] AttributeCertificate,
-- defined in [ATTCERT]
openPGPCert [2] OpenPGPCert
}
OpenPGPCert ::= OCTET STRING
-- contains the OpenPGP certificate (OpenPGP Transferable
-- Public Key) data structure from the OpenPGP specification
-- [OPENPGP] (binary format without Radix-64 conversions),
-- encoded as an ASN.1 OCTET STRING
OpenPGPCert ::= OCTET STRING
-- contains the OpenPGP certificate (OpenPGP Transferable
-- Public Key) data structure from the OpenPGP specification
-- [OPENPGP] (binary format without Radix-64 conversions),
-- encoded as an ASN.1 OCTET STRING
Expanding the CHOICE construct as above allows X.509 attribute certificates and OpenPGP certificates to be used within the PKIX-CMP management messages. In the future, this construct may be expanded further (in subsequent revisions of this document) to accommodate other certificate types, if this is found to be necessary.
如上所述扩展CHOICE构造允许在PKIX-CMP管理消息中使用X.509属性证书和OpenPGP证书。将来，如果发现有必要，可以进一步扩展此结构（在本文档的后续版本中），以适应其他证书类型。
The CMC protocol uses the CMS (Cryptographic Message Syntax) syntax [CMS], which defines the certificate type as
CMC协议使用CMS（加密消息语法）语法[CMS]，该语法将证书类型定义为
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
Similar to PKIX-CMP, this CHOICE can be extended to include additional types of certificates as follows.
与PKIX-CMP类似，此选项可以扩展为包括其他类型的证书，如下所示。
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
openPGPCert [3] IMPLICIT OpenPGPCert }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
openPGPCert [3] IMPLICIT OpenPGPCert }
This allows both X.509 attribute certificates and OpenPGP certificates to be used within the CMC management messages. In the future, this construct may be expanded further (in subsequent revisions of this document) to accommodate other certificate types, if this is found to be necessary.
这允许在CMC管理消息中使用X.509属性证书和OpenPGP证书。将来，如果发现有必要，可以进一步扩展此结构（在本文档的后续版本中），以适应其他证书类型。
The CMC specification defines certain constraints on the subject and publicKey fields of the CRMF's CertTemplate structure. The same constraints should apply to the AltCertTemplate structure if alternative certificate types are used. For example, the CMC specification mandates that
CMC规范对CRMF的CertTemplate结构的subject和publicKey字段定义了某些约束。如果使用其他证书类型，则相同的约束应适用于AltCertTemplate结构。例如，CMC规范要求：
When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate.
在完整注册请求消息中使用CRMF消息正文时，每条CRMF消息必须在CertTemplate中同时包含subject和publicKey字段。
If alternative certificate types are used, this should be extended as
如果使用替代证书类型，则应将其扩展为
When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate (or in the altCertTemplate control).
在完整注册请求消息中使用CRMF消息正文时，每条CRMF消息必须在CertTemplate（或altCertTemplate控件）中包含subject和publicKey字段。
This document defines extensions to the CRMF format, so security considerations from the CRMF specification [CRMF] apply here as well. In particular, the security of alternative certificate templates relies upon the security mechanisms of the protocol or process used to communicate with CAs.
本文档定义了CRMF格式的扩展，因此CRMF规范[CRMF]中的安全注意事项也适用于此。特别是，备用证书模板的安全性依赖于用于与CA通信的协议或进程的安全机制。
Exact security requirements depend on a particular PKI deployment, but integrity protection and message origin authentication are typically required for certification requests. The CMP and CMC certificate management protocols mentioned in this document provide both integrity protection and message origin authentication for request messages (which includes certificate templates as well).
确切的安全要求取决于特定的PKI部署，但认证请求通常需要完整性保护和消息源身份验证。本文档中提到的CMP和CMC证书管理协议为请求消息（还包括证书模板）提供完整性保护和消息源身份验证。
Confidentiality may also be required where alternative certificate templates contain subscriber-sensitive information. The CMC protocol allows the content of request messages to be encrypted. CMP does not include confidentiality mechanisms for certification requests, but if confidentiality is needed, it can be achieved with a lower-layer security protocol (e.g., TLS or IPsec).
如果替代证书模板包含订阅者敏感信息，则可能需要保密。CMC协议允许对请求消息的内容进行加密。CMP不包括认证请求的保密机制，但如果需要保密，可以使用较低层的安全协议（例如TLS或IPsec）实现。
In order to make a decision as to whether a request should be accepted, a CA should normally be able to compare the (authenticated) name of the sender of the request with the request subject name.
为了决定是否应该接受请求，CA通常应该能够将请求的发送者的（经过身份验证的）名称与请求主体的名称进行比较。
For example, an End Entity may be allowed to request additional certificates for himself/herself. In this case, the CA will accept a request if the Sender is equal to the Subject (of course, other conditions will have to be checked as well before the certificate is granted).
例如，可以允许终端实体为自己请求额外的证书。在这种情况下，如果发送方与主体相等，CA将接受请求（当然，在授予证书之前还必须检查其他条件）。
If a PGP certificate is requested using the extensions proposed here, the Sender field of the request will be encoded as an ASN.1 GeneralName (in both CMP and CMC), while the Subject will be represented as a PGP UserID. Since the PGP UserID is effectively an unrestricted octet string, it is not always trivial to compare these two types. It is possible that an attacker may try to submit requests with specially crafted UserIDs (e.g., that include obscure characters) in order to trick the CA comparison algorithm and obtain a PGP certificate with a UserID that belongs to someone else.
如果使用此处建议的扩展请求PGP证书，则请求的发件人字段将编码为ASN.1 GeneralName（在CMP和CMC中），而主题将表示为PGP用户ID。由于PGP用户ID实际上是一个不受限制的八位字节字符串，因此比较这两种类型并不总是一件小事。攻击者可能会尝试使用精心编制的用户标识（例如，包含晦涩字符）提交请求，以欺骗CA比较算法并使用属于其他人的用户标识获取PGP证书。
In these circumstances, it is safer for the CA, when building the PGP certificate's UserID, to completely rebuild the UserID based on the content of the authenticated Sender name rather than take the UserID from the request. To achieve this, additional information about the End Entity may be required at the CA (e.g., the EE's email address).
在这些情况下，CA在构建PGP证书的用户ID时，更安全的做法是基于经过身份验证的发送方名称的内容完全重建用户ID，而不是从请求中获取用户ID。为了实现这一点，CA可能需要关于最终实体的附加信息（例如，EE的电子邮件地址）。
Software components that implement the proposed extensions (e.g., CMP or CMC servers) will necessarily increase in complexity. If a "standard" server is expected to be able to parse ASN.1 streams, the "extended" server is required to be able to parse PGP streams as well. A PGP parser code may introduce new security vulnerabilities that can be exploited by an attacker to mount a DoS attack or gain access to the server.
实现拟议扩展的软件组件（如CMP或CMC服务器）的复杂性必然会增加。如果“标准”服务器预期能够解析ASN.1流，“扩展”服务器也需要能够解析PGP流。PGP解析器代码可能会引入新的安全漏洞，攻击者可利用这些漏洞发动DoS攻击或访问服务器。
In order to reduce the consequences of a successful attack, it is recommended that the CMP or CMC servers be run on a separate machine from the main CA server. These protocol servers should not have access to the main CA key and should not have write access to the CA store.
为了减少成功攻击的后果，建议CMP或CMC服务器在主CA服务器之外的单独计算机上运行。这些协议服务器不应有权访问主CA密钥，也不应有权写入CA存储。
This Appendix presents examples of OpenPGP CertTemplates that are used for requesting OpenPGP certificates from a CA.
本附录提供了用于从CA请求OpenPGP证书的OpenPGP证书模板示例。
A1. Simple Certificate Request
A1。简单证书请求
Alice requests an OpenPGP certificate for her public key accompanied by a subkey.
Alice为其公钥请求OpenPGP证书，并附带一个子密钥。
The content of the OpenPGP CertTemplate in the request is as follows. This CertTemplate conforms to the OpenPGP CertTemplate Required Profile.
请求中OpenPGP CertTemplate的内容如下所示。此CertTemplate符合OpenPGP CertTemplate所需配置文件。
0000: 99 01 A2 === Pub Key packet === 0003: 04 3C 58 27 A2 11 ver 4, created 30 Jan 2002, DSA 0009: 00 E3 FB 9D .. 2B EF DSA prime p 008B: 00 A0 FF 7E .. BA 71 DSA group order q 00A1: 03 FF 68 BC .. 56 71 DSA group generator g 0123: 03 FE 38 1F .. F2 63 DSA public key value y 01A5: B4 19 === User ID packet === 01A7: 41 6C .. 6D 3E "Alice <alice@example.com>" 01C0: 89 00 49 === Signature packet (self-signature) === 01C3: 04 10 11 02 ver 4, gen cert, DSA, SHA1 01C7: 00 09 05 02 3C 58 27 A2 02 1B 03 created 30 Jan 2002, key usage: sign data and certify other keys 01D2: 00 0A 09 10 43 5C .. 06 77 issuer key id 01DE: 5A C2 left 16 bits of signed hash value 01E0: 00 A0 EB 00 .. 1B 75 DSA value r 01F6: 00 A0 F4 E4 .. A8 3D DSA value s 020C: B9 02 0D === Public Subkey packet === 020F: 04 3C 58 27 A2 10 ver 4, created 30 Jan 2002, Elgamal (encrypt-only) algorithm 0215: 08 00 F6 42 .. 0B 3B Elgamal prime p 0317: 00 02 02 Elgamal group generator g 031A: 07 FE 37 BA .. DF 21 Elgamal public key value y 041C: 89 00 49 === Signature packet (subkey binding) === 041F: 04 18 11 02 ver 4, subkey binding, DSA, SHA1 0423: 00 09 05 02 3C 58 27 A2 02 1B 0C created 30 Jan 2002, key usage: encrypt communications and storage 042E: 00 0A 09 10 43 5C .. 06 77 issuer key id 043A: C7 DE left 16 bits of signed hash value 043C: 00 9E 21 33 .. 39 1B DSA value r 0452: 00 9F 64 D7 .. 63 08 DSA value s 0468:
0000:99 01 A2===发布密钥包===0003:04 3C 58 27 A2 11第4版，创建于2002年1月30日，DSA 0009:00 E3 FB 9D。。2B EF DSA基本p 008B:00 A0 FF 7E。。BA 71 DSA集团订单q 00A1:03 FF 68 BC。。56 71 DSA组生成器g 0123:03 FE 38 1F。。F2 63 DSA公钥值y 01A5:B4 19===用户ID数据包===01A7:41 6C。。6D 3E“爱丽丝<alice@example.com>“01C0:89 00 49===签名包（自签名）==01C3:04 10 11 02第4版，gen cert，DSA，SHA1 01C7:00 09 05 02 3C 58 27 A2 02 1B 03于2002年1月30日创建，密钥用法：对数据签名并验证其他密钥01D2:00 0A 09 10 43 5C。。06 77颁发者密钥id 01DE:5A C2留下16位有符号散列值01E0:00 A0 EB 00。。1B 75 DSA值r 01F6:00 A0 F4 E4。。A8 3D DSA值s 020C:B9 02 0D===公钥数据包===020F:04 3C 58 27 A2 10第4版，创建于2002年1月30日，Elgamal（仅加密）算法0215:08 00 F6 42。。0B 3B Elgamal prime p 0317:00 02 02 Elgamal group发电机g 031A:07 FE 37 BA。。DF 21 Elgamal公钥值y 041C:89 00 49==签名包（子密钥绑定）==041F:04 18 11 02第4版，子密钥绑定，DSA，SHA1 0423:00 09 05 02 3C 58 27 A2 02 1B 0C创建于2002年1月30日，密钥使用：加密通信和存储042E:00 0A 09 10 43 5C。。06 77颁发者密钥id 043A:C7取消了有符号散列值043C:00 9E 21 33的16位。。39 1B DSA值r 0452:00 9F 64 D7。。63 08 DSA值s 0468：
CA certifies Alice's User ID and the public key and creates the following OpenPGP certificate:
CA认证Alice的用户ID和公钥，并创建以下OpenPGP证书：
0000: 99 01 A2 === Pub Key packet === 0003: <the same as in the request> 01A5: B4 19 === User ID packet === 01A7: <the same as in the request> 01C0: 89 00 49 === Signature packet (self-signature) === 01C3: <the same as in the request> 020C: 89 00 49 === Signature packet (certification) === 020F: 04 13 11 02 ver 4, positive cert, DSA, SHA1 0213: 00 09 05 02 3C 58 28 1A 02 1B 03 created 30 Jan 2002, key usage: sign data and certify other keys 021E: 00 0A 09 10 F0 0D .. 1F CA issuer key id 022A: 06 DF left 16 bits of signed hash value 022C: 00 9F 57 2D .. 26 E3 DSA value r 0242: 00 A0 B3 02 .. CE 65 DSA value s 0258: B9 02 0D === Public Subkey packet === 025B: <the same as in the request> 0468: 89 00 49 === Signature packet (subkey binding) === 046B: <the same as in the request> 04B4:
0000:99 01 A2===发布密钥包===0003:<与请求中的相同>01A5:B4 19===用户ID包===01A7:<与请求中的相同>01C0:89 00 49==签名包（自签名）==01C3:<与请求中的相同>020C:89 00 49==签名包（认证）==020F:04 13 11 02第4版，正证书，DSA，SHA1 0213:00 09 05 02 3C 58 28 1A 02 1B 03创建于2002年1月30日，密钥用法：签署数据并验证其他密钥021E:00 0A 09 10 F0 0D。。1F CA颁发者密钥id 022A:06 DF有符号哈希值022C:00 9F 57 2D的左16位。。26 E3 DSA值r 0242:00 A0 B3 02。。CE 65 DSA值s 0258:B9 02 0D===公共子密钥包===025B:<与请求中的相同>0468:89 00 49==签名包（子密钥绑定）==046B:<与请求中的相同>04B4:
A2. Certificate Request with Central Key Generation
A2。使用中心密钥生成的证书请求
Alice requests that the CA generate an RSA key pair that will be used for signing, an RSA key pair that will be used for encryption, and requests that the CA certify these keys. The RSA keys are requested to be 2048 bits long with the public exponent 65537.
Alice请求CA生成一个用于签名的RSA密钥对，一个用于加密的RSA密钥对，并请求CA认证这些密钥。要求RSA密钥的长度为2048位，公共指数为65537。
The content of the OpenPGP CertTemplate in the request is as follows:
请求中OpenPGP CertTemplate的内容如下：
0000: 99 01 0D === Pub Key packet (Template) ===
0003: 04 FF FF FF FF 01 ver 4, any creation date, RSA
0009: 08 00 FF FF .. FF FF RSA public modulus n - given length
010B: 00 11 01 00 01 RSA public exponent e
0110: B4 19 === User ID packet ===
0112: 41 6C .. 6D 3E "Alice <alice@example.com>"
012B: 89 00 23 === Signature packet (Template) ===
012E: 04 10 11 02 ver 4, gen cert, DSA, SHA1
0132: 00 09 05 02 FF FF FF FF 02 1B 03
any creation date, key usage:
sign data and certify other keys
013D: 00 0A 09 10 FF FF .. FF FF issuer key id - any
0149: 05 3A left 16 bits of signed hash value
014B: 00 08 FF DSA value r - any
014E: 00 08 FF DSA value s - any
0000: 99 01 0D === Pub Key packet (Template) ===
0003: 04 FF FF FF FF 01 ver 4, any creation date, RSA
0009: 08 00 FF FF .. FF FF RSA public modulus n - given length
010B: 00 11 01 00 01 RSA public exponent e
0110: B4 19 === User ID packet ===
0112: 41 6C .. 6D 3E "Alice <alice@example.com>"
012B: 89 00 23 === Signature packet (Template) ===
012E: 04 10 11 02 ver 4, gen cert, DSA, SHA1
0132: 00 09 05 02 FF FF FF FF 02 1B 03
any creation date, key usage:
sign data and certify other keys
013D: 00 0A 09 10 FF FF .. FF FF issuer key id - any
0149: 05 3A left 16 bits of signed hash value
014B: 00 08 FF DSA value r - any
014E: 00 08 FF DSA value s - any
0151: 99 01 0D === Public Subkey packet (Template) ===
0154: 04 FF FF FF FF 01 ver 4, any creation date, RSA
015A: 08 00 FF FF .. FF FF RSA public modulus n - given length
025C: 00 11 01 00 01 RSA public exponent e
0261: 89 00 20 === Signature packet (Template) ===
0264: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
0268: 00 09 05 02 FF FF FF FF 02 1B 0C
any creation date, key usage:
encrypt communications and storage
0151: 99 01 0D === Public Subkey packet (Template) ===
0154: 04 FF FF FF FF 01 ver 4, any creation date, RSA
015A: 08 00 FF FF .. FF FF RSA public modulus n - given length
025C: 00 11 01 00 01 RSA public exponent e
0261: 89 00 20 === Signature packet (Template) ===
0264: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
0268: 00 09 05 02 FF FF FF FF 02 1B 0C
any creation date, key usage:
encrypt communications and storage
0273: 00 0A 09 10 FF FF .. FF FF issuer key id - any 027F: 12 E6 left 16 bits of signed hash value 0281: 00 08 FF RSA signature value - any 0284:
0273:00 0A 09 10 FF。。FF FF颁发者密钥id-任意027F:12 E6左16位签名哈希值0281:00 08 FF RSA签名值-任意0284:
CA generates keys, certifies Alice's User ID and the public key, and creates the following OpenPGP certificate:
CA生成密钥，认证Alice的用户ID和公钥，并创建以下OpenPGP证书：
0000: 99 01 0D === Pub Key packet ===
0003: 04 3C 5A A5 BB 01 ver 4, created 01 Feb 2002, RSA
0009: 08 00 C7 21 .. 5B EB RSA public modulus n
010B: 00 11 01 00 01 RSA public exponent e
0110: B4 19 === User ID packet ===
0112: 41 6C .. 6D 3E "Alice <alice@example.com>"
012B: 89 01 1F === Signature packet (self-signature) ===
012E: 04 10 01 02 ver 4, gen cert, RSA, SHA1
0132: 00 09 05 02 3C 5A A5 BB 02 1B 03
created 01 Feb 2002, key usage:
sign data and certify other keys
014D: 00 0A 09 10 8E AF .. 1A 18 issuer key id
0149: 3B 21 left 16 bits of signed hash value
014B: 07 FE 2F 1D .. C0 81 RSA signature value
024D: 89 00 49 === Signature packet (certification) ===
0250: 04 13 11 02 ver 4, positive cert, DSA, SHA1
0254: 00 09 05 02 3C 5A A5 DC 02 1B 03
created 01 Feb 2002, key usage:
sign data and certify other keys
025F: 00 0A 09 10 F0 0D .. 1F CA issuer key id
026B: BA C2 left 16 bits of signed hash value
026D: 00 9F 5E 58 .. 30 B3 DSA value r
0283: 00 A0 D1 D7 .. 5A AF DSA value s
0299: 99 01 0D === Public Subkey packet ===
029C: 04 3C 5A A5 C5 01 ver 4, created 01 Feb 2002, RSA
02A2: 08 00 C3 03 .. 8C 53 RSA public modulus n
03A4: 00 11 01 00 01 RSA public exponent e
03A9: 89 01 1F === Signature packet (subkey binding) ===
03AC: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
0000: 99 01 0D === Pub Key packet ===
0003: 04 3C 5A A5 BB 01 ver 4, created 01 Feb 2002, RSA
0009: 08 00 C7 21 .. 5B EB RSA public modulus n
010B: 00 11 01 00 01 RSA public exponent e
0110: B4 19 === User ID packet ===
0112: 41 6C .. 6D 3E "Alice <alice@example.com>"
012B: 89 01 1F === Signature packet (self-signature) ===
012E: 04 10 01 02 ver 4, gen cert, RSA, SHA1
0132: 00 09 05 02 3C 5A A5 BB 02 1B 03
created 01 Feb 2002, key usage:
sign data and certify other keys
014D: 00 0A 09 10 8E AF .. 1A 18 issuer key id
0149: 3B 21 left 16 bits of signed hash value
014B: 07 FE 2F 1D .. C0 81 RSA signature value
024D: 89 00 49 === Signature packet (certification) ===
0250: 04 13 11 02 ver 4, positive cert, DSA, SHA1
0254: 00 09 05 02 3C 5A A5 DC 02 1B 03
created 01 Feb 2002, key usage:
sign data and certify other keys
025F: 00 0A 09 10 F0 0D .. 1F CA issuer key id
026B: BA C2 left 16 bits of signed hash value
026D: 00 9F 5E 58 .. 30 B3 DSA value r
0283: 00 A0 D1 D7 .. 5A AF DSA value s
0299: 99 01 0D === Public Subkey packet ===
029C: 04 3C 5A A5 C5 01 ver 4, created 01 Feb 2002, RSA
02A2: 08 00 C3 03 .. 8C 53 RSA public modulus n
03A4: 00 11 01 00 01 RSA public exponent e
03A9: 89 01 1F === Signature packet (subkey binding) ===
03AC: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
03B0: 00 09 05 02 3C 5A A5 C5 05 1B 0C created 01 Feb 2002, key usage: encrypt communications and storage 03BB: 00 0A 09 10 8E AF .. 1A 18 issuer key id 03C7: C8 44 left 16 bits of signed hash value 03C9: 07 FB 04 D7 .. 75 BE RSA signature value 04CB:
03B0:00 09 05 02 3C 5A A5 C5 05 1B 0C创建于2002年2月1日，密钥用法：加密通信和存储03BB:00 0A 09 10 8E AF。。1A 18颁发者密钥id 03C7:C8 44留下16位有符号散列值03C9:07 FB 04 D7。。75 BE RSA签名值04CB:
Normative References
规范性引用文件
[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1]CCITT建议X.208：抽象语法符号1规范（ASN.1），1988年。
[ATTCERT] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ATTCERT]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[CMC] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[CMC]Myers，M.，Liu，X.，Schaad，J.，和J.Weinstein，“CMS上的证书管理消息”，RFC 2797，2000年4月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CMP] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure: Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[CMP]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施：证书管理协议（CMP）”，RFC 42102005年9月。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure: Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[CRMF]Schaad，J.，“Internet X.509公钥基础设施：证书请求消息格式（CRMF）”，RFC 4211，2005年9月。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[OPENPGP]Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OPENPGP消息格式”，RFC 24401998年11月。
[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月。
Authors' Addresses
作者地址
Mikhail Blinov Guardeonic Solutions Fitzwilliam Court, Leeson Close Dublin 2, Ireland
Mikhail Blinov Guardeonic Solutions Fitzwilliam Court，Leeson Close都柏林2号，爱尔兰
EMail: mikblinov@online.ie
EMail: mikblinov@online.ie
Carlisle Adams School of Information Technology and Engineering (SITE) University of Ottawa 800 King Edward Avenue P.O. Box 450, Stn A Ottawa, Ontario, Canada K1N 6N5
卡莱尔亚当斯信息技术与工程学院（地点）渥太华大学800国王爱德华大道邮政信箱450，STN A渥太华，安大略，加拿大K1N 6N5
EMail: cadams@site.uottawa.ca
EMail: cadams@site.uottawa.ca
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。