Internet Engineering Task Force (IETF) L. Zieglar
Request for Comments: 6403 NSA
Category: Informational S. Turner
ISSN: 2070-1721 IECA
M. Peck
November 2011
Internet Engineering Task Force (IETF) L. Zieglar
Request for Comments: 6403 NSA
Category: Informational S. Turner
ISSN: 2070-1721 IECA
M. Peck
November 2011
Suite B Profile of Certificate Management over CMS
CMS上证书管理的套件B配置文件
Abstract
摘要
The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274.
美国政府发布了“NSA套件B加密”指南，该指南定义了国家安全应用的加密算法政策。本文档指定了CMS证书管理（CMC）协议的配置文件，用于管理Suite B X.509公钥证书。此配置文件是RFC 5272、5273和5274的改进。
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/rfc6403.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6403.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document specifies a profile for using the Certificate Management over CMS (CMC) protocol, defined in [RFC5272], [RFC5273], and [RFC5274], and updated by [RFC6402], to manage X.509 public key certificates compliant with the United States National Security Agency's Suite B Cryptography as defined in the Suite B Certificate and Certificate Revocation List (CRL) Profile [RFC5759]. This document specifically focuses on defining CMC interactions for both initial enrollment and rekey of Suite B public key certificates between a client and a Certification Authority (CA). One or more Registration Authorities (RAs) may act as intermediaries between the client and the CA. This profile may be further tailored by specific communities to meet their needs. Specific communities will also define Certificate Policies that implementations need to comply with.
本文件规定了使用CMS证书管理（CMC）协议的配置文件，该协议在[RFC5272]、[RFC5273]和[RFC5274]中定义，并由[RFC6402]更新，按照套件B证书和证书撤销列表（CRL）配置文件[RFC5759]中的定义，管理符合美国国家安全局套件B加密的X.509公钥证书。本文档特别侧重于为客户端和证书颁发机构（CA）之间的套件B公钥证书的初始注册和重新密钥定义CMC交互。一个或多个注册机构（RAs）可作为客户和CA之间的中介机构。此配置文件可由特定社区进一步定制，以满足其需求。特定社区还将定义实现需要遵守的证书策略。
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]中所述进行解释。
The terminology in [RFC5272] Section 2.1 applies to this profile.
[RFC5272]第2.1节中的术语适用于本概要文件。
All key pairs are on either the curve P-256 or the curve P-384. FIPS 186-3 [DSS], Appendix B.4, provides useful guidance for elliptic curve key pair generation that SHOULD be followed by systems that conform to this document.
所有密钥对都位于曲线P-256或曲线P-384上。FIPS 186-3[DSS]，附录B.4，为符合本文件的系统应遵循的椭圆曲线密钥对生成提供了有用的指导。
This document assumes that the required trust anchors have been securely provisioned to the client and, when applicable, to any RAs.
本文件假设所需的信任锚已安全地提供给客户，并在适用时提供给任何RAs。
All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402] apply, except where overridden by this profile.
[RFC5272]、[RFC5273]、[RFC5274]和[RFC6402]中的所有要求均适用，但本概要文件覆盖的情况除外。
This profile was developed with the scenarios described in Appendix A in mind. However, use of this profile is not limited to just those scenarios.
本概要文件是根据附录A中所述的情景编制的。但是，此配置文件的使用不限于这些场景。
The term "client" in this profile typically refers to an end-entity. However, it may instead refer to a third party acting on the end-entity's behalf. The client may or may not be the entity that
本概要文件中的术语“客户”通常指终端实体。但是，它可以指代表最终实体行事的第三方。客户可能是，也可能不是
actually generates the key pair, but it does perform the CMC protocol interactions with the RA and/or CA. For example, the client may be a token management system that communicates with a cryptographic token through an out-of-band secure protocol.
实际上生成密钥对，但它确实执行与RA和/或CA的CMC协议交互。例如，客户端可能是通过带外安全协议与加密令牌通信的令牌管理系统。
This profile uses the term "rekey" in the same manner as does CMC (defined in Section 2 of [RFC5272]). The profile makes no specific statements about the ability to do "renewal" operations; however, the statements applicable to rekey should be applied to renewal as well.
本概要文件使用术语“重新密钥”的方式与CMC相同（定义见[RFC5272]第2节）。该概要文件未对执行“更新”操作的能力做出具体说明；但是，适用于重新注册的声明也应适用于续签。
This profile may be used to manage RA and/or CA certificates. In that case, the RA and/or CA whose certificate is being managed is considered to be the end-entity.
此配置文件可用于管理RA和/或CA证书。在这种情况下，其证书被管理的RA和/或CA被视为最终实体。
This profile does not support key establishment certification requests from cryptographic modules that cannot generate a one-time signature with a key establishment key for proof-of-possession purposes. In that case, a separate profile would be needed to define the use of another proof-of-possession technique.
此配置文件不支持来自加密模块的密钥建立认证请求，这些模块无法使用密钥建立密钥生成一次性签名以证明其拥有。在这种情况下，需要一个单独的配置文件来定义另一种占有证明技术的使用。
This section specifies the conventions employed when a client requests a certificate from a Public Key Infrastructure (PKI).
本节指定客户端从公钥基础结构（PKI）请求证书时使用的约定。
The Full PKI Request MUST be used; it MUST be encapsulated in a SignedData; and the SignedData MUST be constructed as defined in [RFC6318]. The PKIData content type complies with [RFC5272] with the following additional requirements:
必须使用完整的PKI请求；它必须封装在签名数据中；并且必须按照[RFC6318]中的定义构造签名数据。PKIData内容类型符合[RFC5272]和以下附加要求：
o controlSequence SHOULD be present, and it SHOULD include the following CMC controls: Transaction ID and Sender Nonce. Other CMC controls MAY be included. If the request is being authenticated using a shared-secret, then the following requirements in this paragraph apply: Identity Proof Version 2 control, as defined in [RFC5272], MUST be included; hashAlgId MUST be id-sha256 or id-sha384 for P-256 certification requests, and MUST be id-sha384 for P-384 certification requests (both algorithm OIDs are defined in [RFC5754]); macAlgId MUST be HMAC-SHA256 when the hashAlgId is id-sha256, and MUST be HMAC-SHA384 when the hashAlgId is id-sha384 (both HMAC algorithms are defined in [RFC4231]). If the subject included in the certification request is NULL or otherwise does not uniquely identify the end-entity, then the POP Link Random control MUST be included, and the POP Link Witness Version 2 control MUST be included in the inner PKCS #10 or Certificate Request Message Format (CRMF) request as described in Sections 4.1 and 4.2.
o controlSequence应该存在，并且应该包括以下CMC控件：事务ID和发送方Nonce。可能包括其他CMC控制装置。如果使用共享机密对请求进行身份验证，则本段中的以下要求适用：必须包括[RFC5272]中定义的身份验证版本2控制；对于P-256认证请求，哈希id必须为id-sha256或id-sha384；对于P-384认证请求，哈希id必须为id-sha384（两个算法id在[RFC5754]中定义）；当hashAlgId为id-SHA256时，macAlgId必须为HMAC-SHA256，当hashAlgId为id-SHA384时，macAlgId必须为HMAC-SHA384（两种HMAC算法均在[RFC4231]中定义）。如果认证请求中包含的主题为空或没有唯一标识终端实体，则必须包含POP-Link随机控件，并且POP-Link见证版本2控件必须包含在内部PKCS#10或第4.1节和第4.2节所述的证书请求消息格式（CRMF）请求中。
o reqSequence MUST be present. It MUST include at least one tcr (see Section 4.1) or crm (see Section 4.2) TaggedRequest. Support for the orm choice is OPTIONAL.
o 必须存在reqSequence。它必须包括至少一个tcr（见第4.1节）或crm（见第4.2节）标记。对orm选项的支持是可选的。
If the Full PKI Request contains a P-256 public key certification request, then the SignedData encapsulating the Full PKI Request MUST be generated using either SHA-256 and ECDSA on P-256 or using SHA-384 and ECDSA on P-384. If the Full PKI Request contains a P-384 public key certification request, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384.
如果完整PKI请求包含P-256公钥认证请求，则必须使用P-256上的SHA-256和ECDSA或P-384上的SHA-384和ECDSA生成封装完整PKI请求的签名数据。如果完整PKI请求包含P-384公钥认证请求，则必须在P-384上使用SHA-384和ECDSA生成签名数据。
A Full PKI Request MUST be signed using the private key that corresponds to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment.
完整的PKI请求必须使用与现有签名证书的公钥相对应的私钥进行签名，除非尚未存在适当的签名证书，例如在初始注册期间。
If an appropriate signature certificate does not yet exist, and if a Full PKI Request includes one or more certification requests and is authenticated using a shared-secret (because no appropriate certificate exists yet to authenticate the request), the Full PKI Request MUST be signed using the private key corresponding to the public key of one of the requested certificates. When necessary (i.e., because there is no existing signature certificate and there is no signature certification request included), a Full PKI Request MAY be signed using a key pair intended for use in a key establishment certificate. However, servers are not required to allow this behavior.
如果适当的签名证书尚不存在，并且如果完整的PKI请求包括一个或多个认证请求，并且使用共享密钥进行了身份验证（因为尚不存在适当的证书对请求进行身份验证），必须使用与所请求证书之一的公钥对应的私钥对完整PKI请求进行签名。必要时（即，因为没有现有的签名证书，也没有包括签名证书请求），可以使用密钥建立证书中使用的密钥对来签署完整的PKI请求。但是，服务器不需要允许这种行为。
The reqSequence tcr choice conveys PKCS #10 [RFC2986] syntax. The CertificateRequest MUST comply with [RFC5272], Section 3.2.1.2.1, with the following additional requirements:
reqSequence tcr选项传递PKCS#10[RFC2986]语法。认证请求必须符合[RFC5272]第3.2.1.2.1节的要求，并符合以下附加要求：
o certificationRequestInfo:
o certificationRequestInfo：
* subjectPublicKeyInfo MUST be set as defined in Section 4.4 of [RFC5759];
* 必须按照[RFC5759]第4.4节的规定设置subjectPublicKeyInfo；
* attributes:
* 属性：
- The ExtensionReq attribute MUST be included with its contents as follows:
- ExtensionReq属性必须包含在其内容中，如下所示：
o The Key Usage extension MUST be included, and it MUST be set as defined in [RFC5759].
o 必须包括密钥使用扩展，并且必须按照[RFC5759]中的定义进行设置。
o For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the Subject field of the certificate being used to generate the signature is NULL.
o 对于重设密钥请求，如果用于生成签名的证书的“主题”字段为空，则必须包括SubjectAltName扩展名，并将其设置为与用于对封装请求的已签名数据（即，不是正在重设密钥的证书）进行签名的证书的SubjectAltName相等。
o Other extension requests MAY be included as desired.
o 可根据需要包括其他扩展请求。
- The ChangeSubjectName attribute, as defined in [RFC6402], MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's Subject or SubjectAltName does not match the desired Subject or SubjectAltName of this certification request.
- [RFC6402]中定义的ChangeSubjectName属性，如果封装此标记的证书请求的完整PKI请求由当前存在证书的密钥签名，并且现有证书的Subject或SubjectAltName与此证书请求的所需Subject或SubjectAltName不匹配，则必须包含。
- The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the Subject in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha256 or id-sha384 for P-256 certification requests and MUST be id-sha384 for P-384 certification requests, as defined in [RFC5754]; macAlgorithm MUST be HMAC-SHA256 when the keyGenAlgorithm is id-sha256 and MUST be HMAC-SHA384 when the keyGenAlgorithm is id-sha384, as defined in [RFC4231].
- 如果正在使用共享机密对请求进行身份验证，并且认证请求中的主题为NULL，或者没有唯一标识最终实体，则必须包含POP Link WITHENT Version 2属性。在POP-Link见证版本2属性中，对于P-256认证请求，keyGenAlgorithm必须为id-sha256或id-sha384；对于P-384认证请求，keyGenAlgorithm必须为id-sha384，如[RFC5754]中所定义；当keyGenAlgorithm为id-SHA256时，macAlgorithm必须为HMAC-SHA256；当keyGenAlgorithm为id-SHA384时，macAlgorithm必须为HMAC-SHA384，如[RFC4231]中所定义。
* signatureAlgorithm MUST be ecdsa-with-sha256 for P-256 certification requests and MUST be ecdsa-with-sha384 for P-384 certification requests;
* 签名算法对于P-256认证请求必须是ecdsa-with-sha256，对于P-384认证请求必须是ecdsa-with-sha384；
* signature MUST be generated using the private key corresponding to the public key in the CertificationRequestInfo, for both signature and key establishment certification requests. The signature provides proof-of-possession of the private key to the Certification Authority.
* 签名必须使用与CertificationRequestInfo中的公钥对应的私钥生成，用于签名和密钥建立认证请求。签名向证书颁发机构提供私钥拥有证明。
The reqSequence crm choice conveys Certificate Request Message Format (CRMF) [RFC4211] syntax. The CertReqMsg MUST comply with [RFC5272], Section 3.2.1.2.2, with the following additional requirements:
reqSequence crm选项传递证书请求消息格式（CRMF）[RFC4211]语法。CertReqMsg必须符合[RFC5272]第3.2.1.2.2节，以及以下附加要求：
o popo MUST be included using the signature (POPOSigningKey) proof-of-possession choice and set as defined in [RFC4211], Section 4.1, for both signature and key establishment certification requests.
o 必须使用签名（POPOSigningKey）占有选择证明将popo包括在内，并按照[RFC4211]第4.1节的规定设置，用于签名和密钥建立认证请求。
The POPOSigningKey poposkInput field MUST be omitted. The POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha256 for P-256 certification requests and MUST be ecdsa-with-sha384 for P-384 certification requests. The signature MUST be generated using the private key corresponding to the public key in the CertTemplate.
必须省略POPOSigningKey POPOPOSKINPUT字段。对于P-256认证请求，POPOSigningKey算法标识符必须为ecdsa-with-sha256；对于P-384认证请求，POPOSigningKey算法标识符必须为ecdsa-with-sha384。签名必须使用CertTemplate中与公钥对应的私钥生成。
The CertTemplate MUST comply with [RFC5272], Section 3.2.1.2.2, with the following additional requirements:
CertTemplate必须符合[RFC5272]第3.2.1.2.2节，以及以下附加要求：
o version MAY be included and, if included, it MUST be set to 2 as defined in Section 4.3 of [RFC5759];
o 可以包括版本，如果包括，则必须按照[RFC5759]第4.3节的规定将其设置为2；
o publicKey MUST be set as defined in Section 4.4 of [RFC5759];
o 公钥必须按照[RFC5759]第4.4节的规定设置；
o extensions:
o 扩展：
* The Key Usage extension MUST be included, and it MUST be set as defined in [RFC5759].
* 必须包括密钥使用扩展，并且必须按照[RFC5759]中的定义进行设置。
* For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the Subject field of the certificate being used to generate the signature is NULL.
* 对于重设密钥请求，如果用于生成签名的证书的“主题”字段为空，则必须包括SubjectAltName扩展名，并将其设置为与用于对封装请求的已签名数据（即，不是正在重设密钥的证书）进行签名的证书的SubjectAltName相等。
* Other extension requests MAY be included as desired.
* 可根据需要包括其他扩展请求。
o controls:
o 控制：
* The ChangeSubjectName attribute, as defined in [RFC6402], MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's Subject or SubjectAltName does not match the desired Subject or SubjectAltName of this certification request.
* [RFC6402]中定义的ChangeSubjectName属性，如果封装此标记的证书请求的完整PKI请求由当前存在证书的密钥签名，并且现有证书的Subject或SubjectAltName与此证书请求的所需Subject或SubjectAltName不匹配，则必须包含。
* The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret, and the Subject in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha256 or id-sha384 for P-256 certification requests and MUST be id-sha384 for P-384 certification requests; macAlgorithm MUST be HMAC-SHA256 when keyGenAlgorithm is id-sha256 and MUST be HMAC-SHA384 when keyGenAlgorithm is id-sha384.
* 如果正在使用共享密钥对请求进行身份验证，并且认证请求中的主题为空或没有唯一标识最终实体，则必须包含POP Link WITHENT Version 2属性。在POP Link WITH Version 2属性中，对于P-256认证请求，KEYGENALGORTHM必须为id-sha256或id-sha384；对于P-384认证请求，KEYGENALGORTH必须为id-sha384；当keyGenAlgorithm为id-SHA256时，macAlgorithm必须为HMAC-SHA256，当keyGenAlgorithm为id-SHA384时，macAlgorithm必须为HMAC-SHA384。
This section addresses the optional case where one or more RAs act as intermediaries between the client and CA as described in Section 7 of [RFC5272]. In this section, the term "client" refers to the entity from which the RA received the PKI Request. This section is only applicable to RAs.
本节介绍了可选情况，其中一个或多个RA充当客户机和CA之间的中介，如[RFC5272]第7节所述。在本节中，术语“客户机”指RA接收PKI请求的实体。本节仅适用于RAs。
RAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the RA MUST reject those requests. The RA SHOULD return a CMCFailInfo with the value of badAlg [RFC5272].
符合本文件要求的RAs必须确保在请求中仅使用本概要文件中描述的许可签名、哈希和MAC算法；如果没有，RA必须拒绝这些请求。RA应返回值为badAlg[RFC5272]的CMCFailInfo。
When processing end-entity-generated SignedData objects, RAs MUST NOT perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing [RFC6010].
处理最终实体生成的SignedData对象时，RAs不得执行加密消息语法（CMS）内容约束（CCC）证书扩展处理[RFC6010]。
Other RA processing is as in [RFC5272].
其他RA处理如[RFC5272]所示。
If the RA encapsulates the client-generated PKI Request in a new RA-signed PKI Request, it MUST create a Full PKI Request encapsulated in a SignedData, and the SignedData MUST be constructed as defined in [RFC6318]. The PKIData content type complies with [RFC5272] with the following additional requirements:
如果RA将客户端生成的PKI请求封装在新的RA签名PKI请求中，则必须创建封装在签名数据中的完整PKI请求，并且必须按照[RFC6318]中的定义构造签名数据。PKIData内容类型符合[RFC5272]和以下附加要求：
o controlSequence MUST be present. It MUST include the following CMC controls: Transaction ID, Sender Nonce, and Batch Requests. Other appropriate CMC controls MAY be included.
o 控制序列必须存在。它必须包括以下CMC控件：事务ID、发送方Nonce和批处理请求。可能包括其他适当的CMC控制。
o cmsSequence MUST be present. It contains the original, unmodified request(s) received from the client.
o CMS序列必须存在。它包含从客户端收到的原始、未修改的请求。
RA certificates are authorized to sign Full PKI Requests with an Extended Key Usage (EKU) and/or with the CCC certificate extension [RFC6010]. Certificates may also be authorized through local configuration. Authorized certificates SHOULD include the id-kp-cmcRA EKU from [RFC6402]. Authorized certificates MAY also include the CCC certificate extension [RFC6010], or the authorized certificate MAY just include the CCC certificate extension. If the RA is authorized via the CCC extension, then the CCC extension MUST include the object identifier for the PKIData content type. CCC SHOULD be included if constraints are to be placed on the content types generated.
RA证书被授权使用扩展密钥使用（EKU）和/或CCC证书扩展[RFC6010]签署完整的PKI请求。证书也可以通过本地配置进行授权。授权证书应包括来自[RFC6402]的id kp cmcRA EKU。授权证书还可能包括CCC证书扩展[RFC6010]，或者授权证书可能仅包括CCC证书扩展。如果RA是通过CCC扩展授权的，则CCC扩展必须包括PKIData内容类型的对象标识符。如果对生成的内容类型施加限制，则应包括CCC。
If the RA-signed PKI Request contains a certification request for a P-256 public key, then the SignedData MUST be generated using either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384. If the request contains a certification request for a P-384 public key, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the RA-signed PKI Request contains requests for certificates on the P-256 and P-384 curve, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the SignedData MUST be signed by either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384, the algorithm used in the response MUST match the algorithm used in the request.
如果RA签名的PKI请求包含P-256公钥的认证请求，则必须使用P-256上的SHA-256和ECDSA或P-384上的SHA-384和ECDSA生成签名数据。如果请求包含P-384公钥的认证请求，则必须使用SHA-384和P-384上的ECDSA生成签名数据。如果RA签名的PKI请求包含对P-256和P-384曲线上的证书的请求，则必须在P-384上使用SHA-384和ECDSA生成签名数据。如果完整PKI响应是对仅包含Get证书或Get CRL控制的PKI请求的成功响应，则签名数据必须由P-256上的SHA-256和ECDSA或P-384上的SHA-384和ECDSA签名，响应中使用的算法必须与请求中使用的算法匹配。
RA certificates authorized with the CCC certificate extension [RFC6010] MUST include the object identifier for the PKIResponse content type to authorize them to generate responses.
使用CCC证书扩展[RFC6010]授权的RA证书必须包含PKIResponse内容类型的对象标识符，以授权它们生成响应。
This section specifies the requirements for CAs that receive PKI Requests and that generate PKI Responses.
本节规定了接收PKI请求和生成PKI响应的CA的要求。
CAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the CA MUST reject those requests. The CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed and a CMCFailInfo with the value of badAlg [RFC5272].
符合本文件要求的CA必须确保在请求中仅使用本概要文件中描述的许可签名、哈希和MAC算法；如果没有，CA必须拒绝这些请求。CA应返回CMCStatus为failed的CMCStatusInfoV2控件和值为badAlg[RFC5272]的CMCFailInfo。
For requests involving an RA, the CA MUST verify the RA's authorization. The following certificate fields MUST NOT be modifiable using the Modify Certification Request control: publicKey and the key usage extension. The request MUST be rejected if an attempt to modify those certification request fields is present. The CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed and a CMCFailInfo with a value of badRequest.
对于涉及RA的请求，CA必须验证RA的授权。不能使用“修改证书请求”控件修改以下证书字段：公钥和密钥使用扩展。如果试图修改这些认证请求字段，则必须拒绝该请求。CA应返回CMCStatus为failed的CMCStatusInfoV2控件和值为badRequest的CMCFailInfo。
When processing end-entity-generated SignedData objects, CAs MUST NOT perform CCC certificate extension processing [RFC6010].
在处理最终实体生成的SignedData对象时，CA不得执行CCC证书扩展处理[RFC6010]。
If the client-generated PKI Request includes a ChangeSubjectName attribute either in the CertRequest controls field for a CRMF request or in the tcr attributes field for a PKCS#10 request, then the CA
如果客户端生成的PKI请求在CRMF请求的CertRequest Control字段或PKCS#10请求的tcr attributes字段中包含ChangeSubjectName属性，则CA
MUST ensure that name change is authorized. The mechanism for ensuring that the name change is authorized is out of scope. If the CA performs this check, and the name change is not authorized, then the CA MUST reject the PKI Request. The CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed.
必须确保名称更改得到授权。确保名称更改获得授权的机制超出范围。如果CA执行此检查，并且名称更改未经授权，则CA必须拒绝PKI请求。CA应返回CMCStatus为failed的CMCStatus Infov2控件。
Other processing of PKIRequests is as in [RFC5272].
PKI请求的其他处理如[RFC5272]所示。
If a Full PKI Response is returned, it MUST be encapsulated in a SignedData, and the SignedData MUST be constructed as defined in [RFC6318].
如果返回完整的PKI响应，则必须将其封装在SignedData中，并且必须按照[RFC6318]中的定义构造SignedData。
If the PKI Response is in response to an RA-encapsulated PKI Request, then the above PKI Response is encapsulated in another CA-generated PKI Response. That PKI Response MUST be encapsulated in a SignedData and the SignedData MUST be constructed as defined in [RFC6318]. The above PKI Response is placed in the encapsulating PKI Response cmsSequence field. The other fields are as above with the addition of the batch response control in controlSequence. The following illustrates a successful CA response to an RA-encapsulated PKI Request, both of which include Transaction IDs and Nonces:
如果PKI响应响应RA封装的PKI请求，则上述PKI响应将封装在另一个CA生成的PKI响应中。该PKI响应必须封装在SignedData中，并且SignedData必须按照[RFC6318]中的定义构造。上述PKI响应放在封装PKI响应cmsSequence字段中。其他字段如上所述，在controlSequence中添加了批响应控件。下面说明了CA对RA封装的PKI请求的成功响应，这两个请求都包括事务ID和nonce：
SignedData (applied by the CA) PKIData controlSequence (Transaction ID, Sender Nonce, Recipient Nonce, Batch Response) cmsSequence SignedData (applied by CA and includes returned certificates) PKIData controlSequence (Transaction ID, Sender Nonce, Recipient Nonce)
SignedData（由CA应用）PKIData controlSequence（事务ID、发送方Nonce、接收方Nonce、批响应）cmsSequence SignedData（由CA应用并包括返回的证书）PKIData controlSequence（事务ID、发送方Nonce、接收方Nonce）
The same private key used to sign certificates MUST NOT be used to sign Full PKI Response messages. Instead, a separate certificate authorized to sign CMC responses MUST be used. Certificates are authorized to sign Full PKI Responses with an EKU and/or with the CCC certificate extension [RFC6010]. Certificates may also be authorized through local configuration. Authorized certificates SHOULD include the id-kp-cmcCA EKU from [RFC6402]. Authorized certificates MAY also include the CCC certificate extension [RFC6010], or the authorized certificate MAY just include the CCC certificate extension. If the CA is authorized via the CCC extension, then the CCC extension MUST include the object identifier for the PKIResponse content type. CCC SHOULD be included if constraints are to be placed on the content types generated.
用于签署证书的同一私钥不得用于签署完整的PKI响应消息。相反，必须使用授权签署CMC响应的单独证书。证书有权使用EKU和/或CCC证书扩展[RFC6010]签署完整的PKI响应。证书也可以通过本地配置进行授权。授权证书应包括来自[RFC6402]的id kp cmcCA EKU。授权证书还可能包括CCC证书扩展[RFC6010]，或者授权证书可能仅包括CCC证书扩展。如果CA是通过CCC扩展授权的，则CCC扩展必须包括PKI响应内容类型的对象标识符。如果对生成的内容类型施加限制，则应包括CCC。
The signature on the SignedData MUST be generated using either ECDSA P-256 on SHA-256 or ECDSA P-384 on SHA-384. If the Full PKI Response is a successful response to a P-256 public key certification request, then the SignedData MUST be generated using either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to a P-384 public key certification request, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to certification requests on both the P-256 and P-356 curves, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is an unsuccessful response to a PKI Request, then the SignedData MUST be signed by either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384, the algorithm used in the response MUST match the algorithm used in the request. If the Full PKI Response is an unsuccessful response to certification requests on both the P-256 and P-356 curves, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the SignedData MUST be signed by either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384, the algorithm used in the response MUST match the algorithm used in the request.
签名数据上的签名必须使用SHA-256上的ECDSA P-256或SHA-384上的ECDSA P-384生成。如果完整PKI响应是对P-256公钥认证请求的成功响应，则必须使用P-256上的SHA-256和ECDSA或P-384上的SHA-384和ECDSA生成签名数据。如果完整的PKI响应是对P-384公钥认证请求的成功响应，则必须在P-384上使用SHA-384和ECDSA生成签名数据。如果完整的PKI响应是对P-256和P-356曲线上的认证请求的成功响应，则必须在P-384上使用SHA-384和ECDSA生成签名数据。如果完整PKI响应是对PKI请求的不成功响应，则签名数据必须由P-256上的SHA-256和ECDSA或P-384上的SHA-384和ECDSA签名，响应中使用的算法必须与请求中使用的算法匹配。如果完整的PKI响应是对P-256和P-356曲线上的认证请求的不成功响应，则必须在P-384上使用SHA-384和ECDSA生成签名数据。如果完整PKI响应是对仅包含Get证书或Get CRL控制的PKI请求的成功响应，则签名数据必须由P-256上的SHA-256和ECDSA或P-384上的SHA-384和ECDSA签名，响应中使用的算法必须与请求中使用的算法匹配。
If the PKI Response is in response to an RA-encapsulated PKI Request, the signature algorithm for each SignedData is selected independently.
如果PKI响应响应RA封装的PKI请求，则会独立选择每个签名数据的签名算法。
Clients conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in responses; if they are not, the client MUST reject those responses.
符合本文件要求的客户必须确保响应中仅使用本概要文件中描述的许可签名、哈希和MAC算法；如果不是，客户必须拒绝这些响应。
Clients MUST authenticate all Full PKI Responses. This includes verifying that the PKI Response is signed by an authorized CA or RA whose certificate validates back to a trust anchor. The authorized CA certificate MUST include the id-kp-cmcCA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type. Or, the CA is determined to be authorized to sign responses through an implementation-specific mechanism. The PKI Response can be signed by an RA if it is an error message, if it is a response to a Get Certificate or Get CRL request, or if the PKI Response contains an inner PKI Response signed by a CA. In the last case, each layer of PKI Response MUST still contain an authorized, valid signature signed by an entity with a valid certificate that verifies back to an acceptable trust anchor. The authorized RA certificate MUST include the id-kp-cmcRA EKU and/or include a CCC
客户端必须验证所有完整的PKI响应。这包括验证PKI响应是否由授权CA或RA签名，其证书将验证回信任锚。授权CA证书必须包含id kp cmcCA EKU和/或包含包含PKI响应内容类型的对象标识符的CCC扩展。或者，确定CA有权通过特定于实现的机制签署响应。如果是错误消息，如果是对Get证书或Get CRL请求的响应，或者如果PKI响应包含由CA签名的内部PKI响应，则可以由RA对PKI响应进行签名。在最后一种情况下，PKI响应的每一层必须仍然包含授权，由具有有效证书的实体签名的有效签名，该证书可验证回可接受的信任锚。授权RA证书必须包括id kp cmcRA EKU和/或CCC
extension that includes the object identifier for the PKIResponse content type. Or, the RA is determined to be authorized to sign responses through an implementation-specific mechanism.
包含PKI响应内容类型的对象标识符的扩展。或者，确定RA有权通过特定于实现的机制签署响应。
When a newly issued certificate is included in the PKI Response, the client MUST verify that the newly issued certificate's public key matches the public key that the client requested. The client MUST also ensure that the certificate's signature is valid and that the signature validates back to an acceptable trust anchor.
当新颁发的证书包含在PKI响应中时，客户端必须验证新颁发的证书的公钥是否与客户端请求的公钥匹配。客户机还必须确保证书的签名有效，并且签名验证回可接受的信任锚。
Clients MUST reject PKI Responses that do not pass these tests. Local policy will determine whether the client returns a Full PKI Response with an Extended CMC Status Info control with CMCStatus set to failed to a user console, error log, or the server.
客户端必须拒绝未通过这些测试的PKI响应。本地策略将确定客户端是否向用户控制台、错误日志或服务器返回完整的PKI响应，并将CMCStatus设置为失败的扩展CMC状态信息控件。
If the Full PKI Response contains an Extended Status Info with a CMCStatus set to failed, then local policy will determine whether the client resends a duplicate certification request back to the server or an error state is returned to a console or error log.
如果完整PKI响应包含CMCStatus设置为failed的扩展状态信息，则本地策略将确定客户端是否将重复的认证请求重新发送回服务器，或者是否将错误状态返回到控制台或错误日志。
When the Identity Proof V2 and POP Link Witness V2 controls are used, the shared-secret MUST be randomly generated and securely distributed. The shared-secret MUST provide at least 128 bits of strength for P-256 certification requests and at least 192 bits of strength for P-384 certification requests.
当使用身份验证V2和POP-Link-Witness V2控件时，必须随机生成并安全分发共享密钥。共享秘密必须为P-256认证请求提供至少128位的强度，为P-384认证请求提供至少192位的强度。
Protocol security considerations are found in [RFC2986], [RFC4211], [RFC6318], [RFC5272], [RFC5273], [RFC5274], [RFC5759], and [RFC6402]. When CCC is used to authorize RA and CA certificates, then the security considerations in [RFC6010] also apply. Algorithm security considerations are found in [RFC6318].
协议安全注意事项见[RFC2986]、[RFC4211]、[RFC6318]、[RFC5272]、[RFC5273]、[RFC5274]、[RFC5759]和[RFC6402]。当CCC用于授权RA和CA证书时，[RFC6010]中的安全注意事项也适用。算法安全注意事项见[RFC6318]。
Compliant with NIST Special Publication 800-57 [SP80057], this profile defines proof-of-possession of a key establishment private key by performing a digital signature. Except for one-time proof-of-possession, a single key pair MUST NOT be used for both signature and key establishment.
符合NIST特别出版物800-57[SP80057]，此配置文件通过执行数字签名定义了密钥建立私钥的拥有证明。除一次性占有证明外，签名和密钥建立均不得使用单个密钥对。
This specification requires implementations to generate key pairs and other random values. The use of inadequate pseudo-random number generators (PRNGs) can result in little or no security. The generation of quality random numbers is difficult. NIST Special Publication 800-90 [SP80090], FIPS 186-3 [DSS], and [RFC4086] offer random number generation guidance.
该规范要求实现生成密钥对和其他随机值。使用不充分的伪随机数生成器（PRNG）可能导致很少或没有安全性。生成高质量的随机数是困难的。NIST特别出版物800-90[SP80090]、FIPS 186-3[DSS]和[RFC4086]提供了随机数生成指南。
When RAs are used, the list of authorized RAs must be securely distributed out-of-band to CAs.
使用RAs时，必须将授权RAs列表安全地分发到CAs的带外。
Presence of the POP Link Witness Version 2 and POP Link Random attributes protects against substitution attacks.
POP-Link见证版本2和POP-Link随机属性的存在可防止替换攻击。
The Certificate Policy for a particular environment will specify whether expired certificates can be used to sign certification requests.
特定环境的证书策略将指定是否可以使用过期的证书对证书请求进行签名。
Michael Peck wishes to acknowledge that he was employed at the National Security Agency during much of the work on this document.
Michael Peck希望承认，在编写本文件的大部分工作中，他受雇于国家安全局。
[DSS] National Institute of Standards and Technology (NIST), FIPS 186-3: Digital Signature Standard (DSS), June 2009.
[DSS]国家标准与技术研究所（NIST），FIPS 186-3：数字签名标准（DSS），2009年6月。
[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月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211]Schaad，J.“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 42112005年9月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231]Nystrom，M.“HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的标识符和测试向量”，RFC 42312005年12月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[RFC5273]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）：传输协议”，RFC 5273，2008年6月。
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[RFC5274]Schaad，J.和M.Myers，“CMS上的证书管理消息（CMC）：合规性要求”，RFC 5274，2008年6月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754]Turner，S.，“将SHA2算法与加密消息语法结合使用”，RFC 5754，2010年1月。
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[RFC5759]Solinas，J.和L.Zieglar，“套件B证书和证书撤销列表（CRL）配置文件”，RFC 5759，2010年1月。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, September 2010.
[RFC6010]Housley，R.，Ashmore，S.，和C.Wallace，“加密消息语法（CMS）内容约束扩展”，RFC6010，2010年9月。
[RFC6318] Housley, R. and J. Solinas, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", RFC 6318, June 2011.
[RFC6318]Housley，R.和J.Solinas，“安全/多用途互联网邮件扩展（S/MIME）中的套件B”，RFC 6318，2011年6月。
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, November 2011.
[RFC6402]Schaad，J.，“CMS（CMC）更新的证书管理”，RFC6402，2011年11月。
[SP80057] National Institute of Standards and Technology (NIST), Special Publication 800-57 Part 1: Recommendation for Key Management, March 2007.
[SP80057]国家标准与技术研究所（NIST），专门出版物800-57第1部分：关键管理建议，2007年3月。
[SP80090] National Institute of Standards and Technology (NIST), Special Publication 800-90: Recommendation for Random Number Generation Using Deterministic Random Number Bits Generators (Revised), March 2007.
[SP80090]国家标准与技术研究所（NIST），专门出版物800-90：使用确定性随机数位发生器生成随机数的建议（修订版），2007年3月。
This section illustrates several potential certificate enrollment and rekey scenarios supported by this profile. This section does not intend to place any limits or restrictions on the use of CMC.
本节说明了此配置文件支持的几种可能的证书注册和重新密钥方案。本节不打算对CMC的使用进行任何限制。
This section describes three scenarios for authenticating initial enrollment requests:
本节介绍验证初始注册请求的三种方案：
1. Previously installed signature certificate (e.g., Manufacturer Installed Certificate);
1. 先前安装的签名证书（例如，制造商安装的证书）；
2. Shared-secret distributed securely out-of-band;
2. 安全地在带外分发共享秘密；
3. RA authentication.
3. RA认证。
In this scenario, the end-entity has had a signature certificate installed by the cryptographic module manufacturer. As the end-entity already has a signature certificate, it can be used to authenticate a request for a new certificate. The end-entity signs the Full PKI Request with the private key that corresponds to the subject public key of a previously installed signature certificate. The CA will recognize the authorization of the previously installed certificate and issue an appropriate certificate to the end-entity.
在这种情况下，终端实体已由加密模块制造商安装了签名证书。由于终端实体已经拥有签名证书，因此可以使用它对新证书的请求进行身份验证。终端实体使用与先前安装的签名证书的主题公钥相对应的私钥对完整的PKI请求进行签名。CA将识别以前安装的证书的授权，并向最终实体颁发适当的证书。
In this scenario, the CA distributes a shared-secret out-of-band to the end-entity that the end-entity uses to authenticate its certification request. The end-entity signs the Full PKI Request with the private key for which the certification is being requested. The end-entity includes the Identity Proof Version 2 control to authenticate the request using the shared-secret. The CA uses either the Identification control or the Subject in the end-entity's enclosed PKCS #10 or CRMF certification request message to identify the request. The end-entity performs either the POP Link Witness Version 2 mechanism as described in [RFC5272], Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name (DN) linking mechanism as described in [RFC5272], Section 6.3.2. The Subject in the enclosed PKCS #10 or CRMF certification request does not necessarily match the issued certificate, as it may be used just to help identify the request (and corresponding shared-secret) to the CA.
在这种情况下，CA将带外共享秘密分发给最终实体，该最终实体使用该共享秘密对其认证请求进行身份验证。最终实体使用请求认证的私钥对完整的PKI请求进行签名。终端实体包括身份验证版本2控件，用于使用共享密钥对请求进行身份验证。CA使用最终实体随附的PKCS#10或CRMF认证请求消息中的标识控制或主题来标识请求。终端实体执行[RFC5272]第6.3.1.1节所述的POP链接见证版本2机制，或[RFC5272]第6.3.2节所述的共享主题/主题专有名称（DN）链接机制。随附的PKCS#10或CRMF认证请求中的主题不一定与颁发的证书匹配，因为它可能仅用于帮助CA识别请求（以及相应的共享机密）。
In this scenario, the end-entity does not automatically authenticate its enrollment request to the CA, either because the end-entity has nothing to authenticate the request with or because organizational policy requires RA involvement. The end-entity creates a Full PKI Request and sends it to an RA. The RA verifies the authenticity of the request, then, if approved, encapsulates and signs the request as described in Section 5.2, forwarding the new request on to the CA. The Subject in the PKCS #10 or CRMF certification request is not required to match the issued certificate, it may be used just to help identify the request to the RA and/or CA.
在这种情况下，终端实体不会自动向CA验证其注册请求，这可能是因为终端实体没有任何可用于验证请求的内容，也可能是因为组织策略需要RA参与。最终实体创建完整的PKI请求并将其发送给RA。RA验证请求的真实性，然后，如果获得批准，按照第5.2节所述封装并签署请求，将新请求转发给CA。PKCS#10或CRMF认证请求中的主题不需要与颁发的证书匹配，它可能仅用于帮助识别向RA和/或CA提出的请求。
There are two scenarios to support the rekey of certificates that are already enrolled. One addresses the rekey of signature certificates and the other addresses the rekey of key establishment certificates. Typically, organizational policy will require certificates to be currently valid to be rekeyed, and it may require initial enrollment to be repeated when rekey is not possible. However, some organizational policies might allow a grace period during which an expired certificate could be used to rekey.
有两种方案支持对已注册的证书重新设置密钥。一个解决签名证书的重新密钥问题，另一个解决密钥建立证书的重新密钥问题。通常，组织策略将要求证书当前有效才能重新设置密钥，并且可能要求在无法重新设置密钥时重复初始注册。但是，某些组织策略可能允许宽限期，在此期间可以使用过期的证书重新设置密钥。
When a signature certificate is rekeyed, the PKCS #10 or CRMF certification request message enclosed in the Full PKI Request will include the same Subject as the current signature certificate. The Full PKI Request will be signed by the current private key corresponding to the current signature certificate.
当重新键入签名证书时，完整PKI请求中包含的PKCS#10或CRMF认证请求消息将包含与当前签名证书相同的主题。完整的PKI请求将由与当前签名证书对应的当前私钥签名。
When a key establishment certificate is rekeyed, the Full PKI Request will generally be signed by the current private key corresponding to the current signature certificate. If there is no current signature certificate, one of the initial enrollment options in Appendix A.1 may be used.
当密钥建立证书被重新设置密钥时，完整的PKI请求通常将由与当前签名证书相对应的当前私钥签名。如果没有当前签名证书，可以使用附录A.1中的初始注册选项之一。
Authors' Addresses
作者地址
Lydia Zieglar National Information Assurance Research Laboratory National Security Agency
莉迪亚·齐格勒国家信息保障研究实验室国家安全局
EMail: llziegl@tycho.ncsc.mil
EMail: llziegl@tycho.ncsc.mil
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Michael Peck
佩克
EMail: mpeck@alumni.virginia.edu
EMail: mpeck@alumni.virginia.edu