rfc8756xml2.original.xml   rfc8756.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY rfc2986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2986.xml">
<!ENTITY rfc4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4055.xml">
<!ENTITY rfc4056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4056.xml">
<!ENTITY rfc4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4086.xml">
<!ENTITY rfc4211 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4211.xml">
<!ENTITY rfc4231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4231.xml">
<!ENTITY rfc5272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5272.xml">
<!ENTITY rfc5273 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5273.xml">
<!ENTITY rfc5274 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5274.xml">
<!ENTITY rfc5754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5754.xml">
<!ENTITY rfc6010 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6010.xml">
<!ENTITY rfc6402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6402.xml">
<!ENTITY rfc8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8017.xml">
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category="info" ipr="trust200902" docName="draft-jenkins-cnsa-cmc-profile-0 5" > <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent"
<?rfc comments="no" ?> category="info" ipr="trust200902" number="8756" obsoletes="" updates=""
<?rfc inline="no" ?> xml:lang="en" docName="draft-jenkins-cnsa-cmc-profile-05" tocInclude="true"
<?rfc editing="no" ?> tocDepth="2" symRefs="true" sortRefs="true" version="3">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front> <!-- xml2rfc v2v3 conversion 2.39.0 -->
<front>
<title abbrev="CNSA Suite CMC Profile">Commercial National Security Algorith m (CNSA) Suite Profile of Certificate Management over CMS</title> <title abbrev="CNSA Suite CMC Profile">Commercial National Security Algorith m (CNSA) Suite Profile of Certificate Management over CMS</title>
<seriesInfo name="RFC" value="8756"/>
<author fullname="Michael Jenkins" initials="M." surname="Jenkins"> <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
<organization abbrev="NSA">National Security Agency</organization> <organization abbrev="NSA">National Security Agency</organization>
<address><email>mjjenki@nsa.gov</email></address> <address>
<email>mjjenki@nsa.gov</email>
</address>
</author> </author>
<author fullname="Lydia Zieglar" initials="L." surname="Zieglar"> <author fullname="Lydia Zieglar" initials="L." surname="Zieglar">
<organization abbrev="NSA">National Security Agency</organization> <organization abbrev="NSA">National Security Agency</organization>
<address><email>llziegl@tycho.ncsc.mil</email></address> <address>
<email>llziegl@tycho.ncsc.mil</email>
</address>
</author> </author>
<date year="2020" month="March"/>
<date year="2019"/>
<area>Security</area> <area>Security</area>
<workgroup>Network Working Group</workgroup> <workgroup>Network Working Group</workgroup>
<keyword>NSA</keyword>
<keyword>NSA</keyword> <keyword>CNSA</keyword>
<keyword>CNSA</keyword> <keyword>NSS</keyword>
<keyword>NSS</keyword> <keyword>certificate</keyword>
<keyword>certificate</keyword> <keyword>enrollment</keyword>
<keyword>enrollment</keyword> <abstract>
<t>This document specifies a profile of the Certificate Management over CM
<abstract> S (CMC) protocol for managing X.509 public key certificates in applications that
use the Commercial National Security Algorithm (CNSA) Suite published by the Un
<t>This document specifies a profile of the Certificate Management over CMS (CMC ited States Government.
) protocol for managing X.509 public key certificates in applications that use t
he Commercial National Security Algorithm (CNSA) Suite published by the United S
tates Government.
</t> </t>
<t>The profile applies to the capabilities, configuration, and operation o
<t>The profile applies to the capabilities, configuration, and operation of all f all components of US National Security Systems that manage X.509 public key ce
components of US National Security Systems that manage X.509 public key certific rtificates over CMS. It is also appropriate for all other US Government systems
ates over CMS. It is also appropriate for all other US Government systems that that process high-value information.
process high-value information.
</t> </t>
<t>The profile is made publicly available here for use by developers and o
<t>The profile is made publicly available here for use by developers and operato perators of these and any other system deployments.
rs of these and any other system deployments.
</t> </t>
</abstract> </abstract>
</front>
</front> <middle>
<middle>
<section anchor="intro" title="Introduction">
<t>This document specifies a profile of the Certificate Management over CMS (CMC
) protocol to comply with the United States National Security Agency's Commercia
l National Security Algorithm (CNSA) Suite <xref target="CNSA" />. The profile a
pplies to the capabilities, configuration, and operation of all components of US
National Security Systems <xref target="SP80059" />. It is also appropriate for
all other US Government systems that process high-value information. It is made
publicly available for use by developers and operators of these and any other s
ystem deployments.</t>
<t>This document does not define any new cryptographic algorithm suite; instead,
it defines a CNSA compliant profile of CMC. CMC is defined in <xref target="RFC
5272" />, <xref target="RFC5273" />, and <xref target="RFC5274" />, and is updat
ed by <xref target="RFC6402" />. This document profiles CMC to manage X.509 publ
ic key certificates in compliance with the CNSA Suite Certificate and Certificat
e Revocation List (CRL) Profile <xref target="ID.cnsa-cert-profile" />. This doc
ument specifically focuses on defining CMC interactions for both initial enrollm
ent and rekey of CNSA Suite public key certificates between a client and a Certi
fication Authority (CA). One or more Registration Authorities (RAs) may act as
intermediaries between the client and the CA. This profile may be further tailo
red by specific communities to meet their needs. Specific communities will also
define Certificate Policies that implementations need to comply with.</t>
</section> <!-- intro -->
<section anchor="cnsa" title="The Commercial National Security Algorithm Suit
e">
<t>The National Security Agency (NSA) profiles commercial cryptographic algor
ithms and protocols as part of its mission to support secure, interoperable comm
unications for US Government National Security Systems. To this end, it publishe
s guidance both to assist with the US Government transition to new algorithms, a
nd to provide vendors - and the Internet community in general - with information
concerning their proper use and configuration within the scope of US Government
National Security Systems.</t>
<t>Recently, cryptographic transition plans have become overshadowed by the p
rospect of the development of a cryptographically-relevant quantum computer. NSA
has established the Commercial National Security Algorithm (CNSA) Suite to prov
ide vendors and IT users near-term flexibility in meeting their cybersecurity in
teroperability requirements. The purpose behind this flexibility is to avoid ven
dors and customers making two major transitions in a relatively short timeframe,
as we anticipate a need to shift to quantum-resistant cryptography in the near
future.</t>
<t>NSA is authoring a set of RFCs, including this one, to provide updated gui
dance concerning the use of certain commonly available commercial algorithms in
IETF protocols. These RFCs can be used in conjunction with other RFCs and crypto
graphic guidance (e.g., NIST Special Publications) to properly protect Internet
traffic and data-at-rest for US Government National Security Systems.</t>
</section> <!-- cnsa -->
<section anchor="terms" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x
ref target="RFC8174" /> when, and only when, they appear in all capitals, as sho
wn here.</t>
<t>The terminology in <xref target="RFC5272" /> Section 2.1 applies to this prof
ile.</t>
<t>The term "Certificate Request" is used to refer to a single PKCS #10 or CRMF
structure. All PKI Requests are Full PKI Requests, and all PKI Responses are Ful
l PKI Responses; the respective set of terms should be interpreted synonymously
in this document.</t>
</section> <!-- terms -->
<section anchor="reqts" title="Requirements and Assumptions">
<t>Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-
Hellman (ECDH) key pairs are on the curve P-384. FIPS 186-4 <xref target="FIPS1
86" />, Appendix B.4, provides useful guidance for elliptic curve key pair gener
ation that SHOULD be followed by systems that conform to this document.</t>
<t>RSA key pairs (public, private) are identified by the modulus size expressed
in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 b
its, respectively.</t>
<t>RSA signature key pairs used in CNSA Suite compliant implementations are eith
er RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2^16&lt;e&lt;2^256 and
be odd per <xref target="FIPS186" />.</t>
<t>It is recognized that, while the vast majority of RSA signatures are currentl
y made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme
for new applications is RSASSA-PSS. CNSA Suite compliant X.509 certificates wi
ll be issued in accordance with <xref target="ID.cnsa-cert-profile" />, and whil
e those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the s
ubject's private key can be used to generate signatures of either signing scheme
. Where use of RSASSA-PSS is indicated in this document, the following paramete
rs apply:
<list style="symbols">
<t>the hash algorithm MUST be id-sha384 as defined in <xref target="RFC8017" />;
</t>
<t>the mask generation function MUST use the algorithm identifier mfg1SHA384Iden
tifier as defined in <xref target="RFC4055" />;</t>
<t>the salt length MUST be 48 octets; and</t>
<t>the trailerField MUST have value 1.</t>
</list>
These parameters will not appear in a certificate and MUST be securely communica
ted with the signature as required by Section 2.2 of <xref target="RFC4056" />.
Application developers are obliged to ensure that the chosen signature scheme is
appropriate for the application and will be interoperable within the intended o
perating scope of the application.</t>
<t>This document assumes that the required trust anchors have been securely prov
isioned to the client and, when applicable, to any RAs.</t>
<t>All requirements in <xref target="RFC5272" />, <xref target="RFC5273" />, <xr
ef target="RFC5274" />, and <xref target="RFC6402" /> apply, except where overri
dden by this profile.</t>
<t>This profile was developed with the scenarios described in <xref target="scen
arios" /> in mind. However, use of this profile is not limited to just those sc
enarios.</t>
<t>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 c
lient 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 cryptograph
ic token through an out-of-band secure protocol.</t>
<t>This profile uses the term "rekey" in the same manner as does CMC (defined in
Section 2 of <xref target="RFC5272" />). The profile makes no specific stateme
nts about the ability to do "renewal" operations; however, the statements applic
able to rekey should be applied to renewal as well.</t>
<t>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.</t>
<t>This profile does not discuss key establishment certification requests from c
ryptographic modules that cannot generate a one-time signature with a key establ
ishment 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.</t>
</section> <!-- reqts -->
<section anchor="client-reqts-gen" title="Client Requirements: Generating PKI Re
quests">
<t>This section specifies the conventions employed when a client requests a cert <section anchor="intro" numbered="true" toc="default">
ificate from a Public Key Infrastructure (PKI).</t> <name>Introduction</name>
<t>The Full PKI Request MUST be used; it MUST be encapsulated in a SignedData; a <t>This document specifies a profile of the Certificate Management over CMS (CMC
nd the SignedData MUST be constructed in accordance with <xref target="ID.cnsa-s ) protocol to comply with the United States National Security Agency's Commercia
mime-profile" />. The PKIData content type defined in <xref target="RFC5272" /> l National Security Algorithm (CNSA) Suite <xref target="CNSA" format="default"/
is used with the following additional requirements: >. The profile applies to the capabilities, configuration, and operation of all
<list style="symbols"> <!-- 1 --> components of US National Security Systems <xref target="SP80059" format="defaul
<t>controlSequence SHOULD be present. t"/>. It is also appropriate for all other US Government systems that process hi
<list style="symbols"> <!-- 2 --> gh-value information. It is made publicly available for use by developers and op
<t>TransactionId and SenderNonce SHOULD be included. Other CMC controls MA erators of these and any other system deployments.
Y be included.</t>
<t>If the request is being authenticated using a shared-secret, then Ident
ity Proof Version 2 control MUST be included with the following constraints:
<list style="symbols"> <!-- 3 -->
<t>hashAlgId MUST be id-sha384 for all certification requests (algorith
m OIDs are defined in <xref target="RFC5754" />);</t>
<t>macAlgId MUST be HMAC-SHA384 (the HMAC algorithm is defined in <xref
target="RFC4231" />).</t>
</list> <!-- 3 -->
</t>
<t>If the subject included in the certification request is NULL or otherwi
se does not uniquely identify the end-entity, then the POP Link Random control M
UST be included, and the POP Link Witness Version 2 control MUST be included in
the inner <xref target="RFC2986">PKCS #10</xref> or Certificate Request Message
Format (CRMF) <xref target="RFC4211" /> request as described in <xref target="tg
d-cert-reqst" /> and <xref target="cert-reqst-msg" />.
</t>
</list> <!-- 2 -->
</t>
<t>reqSequence MUST be present. It MUST include at least one tcr (see <xref
target="tgd-cert-reqst" />) or crm (see <xref target="cert-reqst-msg" />) Tagged
Request. Support for the orm choice is OPTIONAL.
</t>
</list> <!-- 1 -->
</t> </t>
<t>The private signing key used to generate the encapsulating SignedData MUST co <t>This document does not define any new cryptographic algorithm suites; instead
rrespond to the public key of an existing signature certificate unless an approp , it defines a CNSA-compliant profile of CMC. CMC is defined in <xref target="RF
riate signature certificate does not yet exist, such as during initial enrollmen C5272" format="default"/>, <xref target="RFC5273" format="default"/>, and <xref
t.</t> target="RFC5274" format="default"/> and is updated by <xref target="RFC6402" for
mat="default"/>. This document profiles CMC to manage X.509 public key certifica
<t>The encapsulating SignedData MUST be generated using SHA-384 and either ECDSA tes in compliance with the CNSA Suite Certificate and Certificate Revocation Lis
on P-384, or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 t (CRL) profile <xref target="RFC8603" format="default"/>. This document specifi
or RSA-4096 key.</t> cally focuses on defining CMC interactions for both the initial enrollment and r
ekey of CNSA Suite public key certificates between a client and a Certification
<t>If an appropriate signature certificate does not yet exist, and if a Full PKI Authority (CA). One or more Registration Authorities (RAs) may act as intermedi
Request includes one or more certification requests and is authenticated using aries between the client and the CA. This profile may be further tailored by sp
a shared-secret (because no appropriate certificate exists yet to authenticate t ecific communities to meet their needs. Specific communities will also define c
he request), the Full PKI Request MUST be signed using the private key correspon ertificate policies that implementations need to comply with.
ding to the public key of one of the requested certificates. When necessary (i. </t>
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 p
air intended for use in a key establishment certificate. However, servers are n
ot required to allow this behavior.</t>
<section anchor="tgd-cert-reqst" title="Tagged Certification Request">
<t>The reqSequence tcr choice conveys <xref target="RFC2986">PKCS #10</xref>
syntax. The CertificateRequest MUST comply with <xref target="RFC5272" />, Sect
ion 3.2.1.2.1, with the following additional requirements:
<list style="symbols"> <!-- 1 -->
<t>certificationRequestInfo:
<list style="symbols"> <!-- 2 -->
<t>subjectPublicKeyInfo MUST be set as defined in Section 4.4 of <xref
target="ID.cnsa-cert-profile" />;</t>
<t>attributes:
<list style="symbols"> <!-- 3 -->
<t>The ExtensionReq attribute MUST be included with its contents as
follows:
<list style="symbols"> <!-- 4 -->
<t>The Key Usage extension MUST be included, and it MUST be set a
s defined in <xref target="ID.cnsa-cert-profile" />.</t>
<t>For rekey requests, the SubjectAltName extension MUST be inclu
ded 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 sign
ature is NULL.</t>
<t>Other extension requests MAY be included as desired.</t>
</list></t> <!-- 4 -->
<t>The ChangeSubjectName attribute, as defined in <xref target="RFC6
402" />, MUST be included if the Full PKI Request encapsulating this Tagged Cert
ification Request is being signed by a key for which a certificate currently exi
sts and the existing certificate's Subject or SubjectAltName does not match the
desired Subject or SubjectAltName of this certification request.</t>
<t>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 cert
ification request is NULL or otherwise does not uniquely identify the end-entity
. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha38
4 for certification requests, as defined in <xref target="RFC5754" />; macAlgori
thm MUST be HMAC-SHA384, as defined in <xref target="RFC4231" />.</t>
</list></t> <!-- 3 -->
<t>signatureAlgorithm MUST be ecdsa-with-sha384 for P-384 certification re
quests, and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 c
ertification requests;</t>
<t>signature MUST be generated using the private key corresponding to the
public key in the CertificationRequestInfo, for both signature and key establish
ment certification requests. The signature provides proof-of-possession of the
private key to the CA.</t>
</list></t> <!-- 2 -->
</list></t> <!-- 1 --> <section anchor="terms" numbered="true" toc="default">
<name>Terminology</name>
</section> <!-- tgd-cert-reqst --> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI
RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD
</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NO
T RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in t
his document are to be interpreted as described in BCP&nbsp;14 <xref target="RFC
2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capital
s, as shown here.
</t>
<t>The terminology in <xref target="RFC5272" sectionFormat="comma" section
="2.1"/> applies to this profile.</t>
<t>The term "certificate request" is used to refer to a single PKCS #10
or Certificate Request Message Format (CRMF) structure. All PKI Requests
are Full PKI Requests, and all PKI Responses are Full PKI Responses; the respect
ive set of terms should be interpreted synonymously in this document.</t>
</section>
<!-- terms -->
<section anchor="cert-reqst-msg" title="Certificate Request Message"> </section>
<!-- intro -->
<t>The reqSequence crm choice conveys <xref target="RFC4211">Certificate Requ <section anchor="cnsa" numbered="true" toc="default">
est Message Format (CRMF)</xref> syntax. The CertReqMsg MUST comply with <xref <name>The Commercial National Security Algorithm Suite</name>
target="RFC5272" />, Section 3.2.1.2.2, with the following additional requiremen <t>The National Security Agency (NSA) profiles commercial cryptographic al
ts: gorithms and protocols as part of its mission to support secure, interoperable c
ommunications for US Government National Security Systems. To this end, it publi
shes guidance both to assist with the US Government transition to new algorithms
and to provide vendors -- and the Internet community in general -- with informa
tion concerning their proper use and configuration within the scope of US Govern
ment National Security Systems.</t>
<t>Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically relevant quantum
computer. The NSA has established the Commercial National Security
Algorithm (CNSA) Suite to provide vendors and IT users near-term
flexibility in meeting their cybersecurity interoperability
requirements. The purpose behind this flexibility is to avoid having vendo
rs and customers make two major transitions in a relatively short timeframe, as
we anticipate a need to shift to quantum-resistant cryptography in the near futu
re.</t>
<t>The NSA is authoring a set of RFCs, including this one, to provide upda
ted guidance concerning the use of certain commonly available commercial algorit
hms in IETF protocols. These RFCs can be used in conjunction with other RFCs and
cryptographic guidance (e.g., NIST Special Publications) to properly protect In
ternet traffic and data-at-rest for US Government National Security Systems.</t>
</section>
<!-- cnsa -->
<list style="symbols"> <section anchor="reqts" numbered="true" toc="default">
<name>Requirements and Assumptions</name>
<t>Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve
Diffie-Hellman (ECDH) key pairs are on the P-384 curve. FIPS 186-4 <xref
target="FIPS186" format="default"/>, Appendix B.4 provides useful guidance for e
lliptic curve key pair generation that <bcp14>SHOULD</bcp14> be followed by syst
ems that conform to this document.</t>
<t>RSA key pairs (public, private) are identified by the modulus size expr
essed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and
4096 bits, respectively.</t>
<t>popo MUST be included using the signature (POPOSigningKey) proof-of-pos <t>RSA signature key pairs used in CNSA Suite-compliant implementations are eith
session choice and set as defined in <xref target="RFC4211" />, Section 4.1, for er RSA-3072 or RSA-4096. The RSA exponent e <bcp14>MUST</bcp14> satisfy 2<sup>16
both signature and key establishment certification requests. The POPOSigningKey </sup> &lt; e &lt; 2<sup>256</sup> and be odd per <xref target="FIPS186" format=
poposkInput field MUST be omitted. The POPOSigningKey algorithmIdentifier MUST "default"/>.
be ecdsa-with-sha384 for P-384 certification requests, and sha384WithRSAEncrypt </t>
ion or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests. The sign
ature MUST be generated using the private key corresponding to the public key in
the CertTemplate.</t>
</list></t> <t>It is recognized that, while the vast majority of RSA signatures are cu rrently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certifica tes will be issued in accordance with <xref target="RFC8603" format="default"/>, and while those certificates must be signed and validated using RSASSA-PKCS1-v1 _5, the subject's private key can be used to generate signatures of either signi ng scheme. Where use of RSASSA-PSS is indicated in this document, the following parameters apply:
<t>The CertTemplate MUST comply with <xref target="RFC5272" />, Section 3.2.1 </t>
.2.2, with the following additional requirements: <ul spacing="normal">
<li>The hash algorithm <bcp14>MUST</bcp14> be id-sha384 as defined in <x
ref target="RFC8017" format="default"/>;</li>
<li>The mask generation function <bcp14>MUST</bcp14> use the algorithm i
dentifier mfg1SHA384Identifier as defined in <xref target="RFC4055" format="defa
ult"/>;</li>
<li>The salt length <bcp14>MUST</bcp14> be 48 octets; and</li>
<li>The trailerField <bcp14>MUST</bcp14> have value 1.</li>
</ul>
<t>
<list style="symbols"> These parameters will not appear in a certificate and <bcp14>MUST</bcp14> be sec
urely
communicated with the signature, as required by <xref
target="RFC4056" sectionFormat="of" section="2.2"/>. Application developer
s are obliged to ensure that the chosen signature scheme is appropriate for the
application and will be interoperable within the intended operating scope of the
application.</t>
<t>This document assumes that the required trust anchors have been securel
y provisioned to the client and, when applicable, to any RAs.</t>
<t>All requirements in <xref target="RFC5272" format="default"/>, <xref ta
rget="RFC5273" format="default"/>, <xref target="RFC5274" format="default"/>, an
d <xref target="RFC6402" format="default"/> apply, except where overridden by th
is profile.</t>
<t>This profile was developed with the scenarios described in <xref target
="scenarios" format="default"/> in mind. However, use of this profile is not li
mited to just those scenarios.</t>
<t>The term "client" in this profile typically refers to an end-entity. Ho
wever, 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, b
ut it does perform the CMC protocol interactions with the RA and/or CA. For exa
mple, the client may be a token management system that communicates with a crypt
ographic token through an out-of-band secure protocol.</t>
<t>This profile uses the term "rekey" in the same manner as CMC does (defi
ned in <xref target="RFC5272" sectionFormat="of" section="2"/>). The profile ma
kes no specific statements about the ability to do "renewal" operations; however
, the statements applicable to "rekey" should be applied to "renewal" as well.</
t>
<t>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 th
e end-entity.</t>
<t>This profile does not discuss 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 pr
ofile would be needed to define the use of another proof-of-possession technique
.</t>
</section>
<!-- reqts -->
<t>If version is included, it MUST be set to 2 as defined in Section 4.3 o f <xref target="ID.cnsa-cert-profile" />;</t> <section anchor="client-reqts-gen" numbered="true" toc="default">
<t>publicKey MUST be set as defined in Section 4.4 of <xref target="ID.cns a-cert-profile" />;</t> <name>Client Requirements: Generating PKI Requests</name>
<t>extensions: <t>This section specifies the conventions employed when a client requests a cert
ificate from a Public Key Infrastructure (PKI).
</t>
<list style="symbols"> <t>The Full PKI Request <bcp14>MUST</bcp14> be used; it <bcp14>MUST</bcp14> be e
ncapsulated in a SignedData; and the SignedData <bcp14>MUST</bcp14> be construct
ed in accordance with <xref target="RFC8755" format="default"/>. The PKIData con
tent type defined in <xref target="RFC5272" format="default"/> is used with the
following additional requirements:
</t>
<t>The Key Usage extension MUST be included, and it MUST be set as defi <ul spacing="normal">
ned in <xref target="ID.cnsa-cert-profile" />.</t> <!-- 1 -->
<li>
<t>controlSequence <bcp14>SHOULD</bcp14> be present.
</t>
<ul spacing="normal">
<!-- 2 -->
<li>TransactionId and SenderNonce <bcp14>SHOULD</bcp14> be included. Other
CMC controls <bcp14>MAY</bcp14> be included.</li>
<li>
<t>If the request is being authenticated using a shared-secret, th
en Identity Proof Version 2 control <bcp14>MUST</bcp14> be included with the fol
lowing constraints:
</t>
<ul spacing="normal">
<!-- 3 -->
<li>hashAlgId <bcp14>MUST</bcp14> be id-sha384 for all certification re
quests (algorithm OIDs are defined in <xref target="RFC5754" format="default"/>)
.</li>
<li>macAlgId <bcp14>MUST</bcp14> be HMAC-SHA384 (the Hashed
Message Authentication Code (HMAC) algorithm is defined in <xref
target="RFC4231" format="default"/>).</li>
</ul>
<!-- 3 -->
<t>For rekey requests, the SubjectAltName extension MUST be included an </li>
d set equal to the SubjectAltName of the certificate that is being used to sign <li>If the subject name included in the certification request is NUL
the SignedData encapsulating the request (i.e., not the certificate being rekeye L
d) if the Subject field of the certificate being used to generate the signature or otherwise does not uniquely identify the end-entity, then the
is NULL.</t> POP Link Random control <bcp14>MUST</bcp14> be included, and the
POP Link Witness Version 2 control <bcp14>MUST</bcp14> be included
in the inner PKCS #10 <xref target="RFC2986" format="default"/> or
Certificate Request Message Format (CRMF) <xref target="RFC4211"
format="default"/> request as described in Sections <xref target="tgd
-cert-reqst" format="counter"/> and <xref target="cert-reqst-msg" format="counte
r"/>.
</li>
</ul>
<!-- 2 -->
</li>
<li>reqSequence <bcp14>MUST</bcp14> be present. It <bcp14>MUST</bcp14>
include at least one tcr (see <xref target="tgd-cert-reqst" format="default"/>)
or crm (see <xref target="cert-reqst-msg" format="default"/>) TaggedRequest. Sup
port for the orm choice is <bcp14>OPTIONAL</bcp14>.
</li>
</ul>
<!-- 1 -->
<t>The private signing key used to generate the encapsulating SignedData <
bcp14>MUST</bcp14> correspond to the public key of an existing signature certifi
cate unless an appropriate signature certificate does not yet exist, such as dur
ing initial enrollment.</t>
<t>The encapsulating SignedData <bcp14>MUST</bcp14> be generated using SHA
-384 and either ECDSA on P-384 or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-P
SS with an RSA-3072 or RSA-4096 key.</t>
<t>If an appropriate signature certificate does not yet exist and if a Ful
l PKI Request includes one or more certification requests and is authenticated u
sing a shared-secret (because no appropriate certificate exists yet to authentic
ate the request), the Full PKI Request <bcp14>MUST</bcp14> be signed using the p
rivate key corresponding to the public key of one of the requested certificates.
When necessary (i.e., because there is no existing signature certificate and t
here is no signature certification request included), a Full PKI Request <bcp14>
MAY</bcp14> be signed using a key pair intended for use in a key establishment c
ertificate. However, servers are not required to allow this behavior.</t>
<section anchor="tgd-cert-reqst" numbered="true" toc="default">
<name>Tagged Certification Request</name>
<t>The reqSequence tcr choice conveys PKCS #10 <xref target="RFC2986"
format="default"/> syntax. The CertificateRequest <bcp14>MUST</bcp14>
comply with <xref target="RFC5272" sectionFormat="comma" section="3.2.1.2
.1"/>, with the following additional requirements:
<t>Other extension requests MAY be included as desired.</t> </t>
<ul spacing="normal">
<!-- 1 -->
</list></t> <li>
<t>certificationRequestInfo:
<t>controls: </t>
<ul spacing="normal">
<!-- 2 -->
<li>subjectPublicKeyInfo <bcp14>MUST</bcp14> be set as defined in <xref
target="RFC8603" sectionFormat="of" section="5.4"/>.</li>
<li>
<t>Attributes:
<list style="symbols"> </t>
<ul spacing="normal">
<!-- 3 -->
<t>The ChangeSubjectName attribute, as defined in <xref target="RFC6402 <li>
" />, MUST be included if the Full PKI Request encapsulating this Tagged Certifi <t>The ExtensionReq attribute <bcp14>MUST</bcp14> be include
cation Request is being signed by a key for which a certificate currently exists d with its contents as follows:
and the existing certificate's Subject or SubjectAltName does not match the des
ired Subject or SubjectAltName of this certification request.</t>
<t>The POP Link Witness Version 2 attribute MUST be included if the reques </t>
t is being authenticated using a shared-secret, and the Subject in the certifica <ul spacing="normal">
tion request is NULL or otherwise does not uniquely identify the end-entity. In <!-- 4 -->
the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384 for <li>The keyUsage extension <bcp14>MUST</bcp14> be included, and i
certification requests; macAlgorithm MUST be HMAC-SHA384 when keyGenAlgorithm i t <bcp14>MUST</bcp14> be set as defined in <xref target="RFC8603" format="defaul
s id-sha384.</t> t"/>.</li>
<li>For rekey requests, the SubjectAltName extension <bcp1
4>MUST</bcp14> be included and set equal to the SubjectAltName of the certificat
e 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 us
ed to generate the signature is NULL.</li>
<li>Other extension requests <bcp14>MAY</bcp14> be include
d as desired.</li>
</ul>
</li>
<!-- 4 -->
</list></t> <li>The ChangeSubjectName attribute, as defined in <xref target="RFC
6402" format="default"/>, <bcp14>MUST</bcp14> be included if the Full PKI Reques
t encapsulating this Tagged Certification Request is being signed by a key for w
hich a certificate currently exists and the existing certificate's subject field
or SubjectAltName extension does not match the desired subject name or SubjectA
ltName extension of this certification request.</li>
<li>The POP Link Witness Version 2 attribute <bcp14>MUST</bcp1
4> be included if the request is being authenticated using a shared-secret and t
he subject name in the certification request is NULL or otherwise does not uniqu
ely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGe
nAlgorithm <bcp14>MUST</bcp14> be id-sha384 for certification requests, as defin
ed in <xref target="RFC5754" format="default"/>; macAlgorithm <bcp14>MUST</bcp14
> be HMAC-SHA384, as defined in <xref target="RFC4231" format="default"/>.</li>
</ul>
</li>
<!-- 3 -->
</list></t> <li>signatureAlgorithm <bcp14>MUST</bcp14> be ecdsa-with-sha384 for P-384
certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072
and RSA-4096 certification requests.</li>
<li>signature <bcp14>MUST</bcp14> be generated using the private k
ey corresponding to the public key in the CertificationRequestInfo for both sign
ature and key establishment certification requests. The signature provides proo
f-of-possession of the private key to the CA.</li>
</ul>
</li>
<!-- 2 -->
</section> <!-- cert-reqst-msg --> </ul>
<!-- 1 -->
</section> <!-- client-reqts-gen --> </section>
<!-- tgd-cert-reqst -->
<section anchor="ra_reqts" title="RA Requirements"> <section anchor="cert-reqst-msg" numbered="true" toc="default">
<name>Certificate Request Message</name>
<t>The reqSequence crm choice conveys Certificate Request Message
Format (CRMF) <xref target="RFC4211" format="default"/>
syntax. The CertReqMsg <bcp14>MUST</bcp14> comply with <xref target="RFC
5272"
sectionFormat="comma" section="3.2.1.2.2"/>, with the following additiona
l requirements:
<t>This section addresses the optional case where one or more RAs act as interme </t>
diaries between clients and a CA as described in Section 7 of <xref target="RFC5 <ul spacing="normal">
272" />. In this section, the term "client" refers to the entity from which the <li>popo <bcp14>MUST</bcp14> be included using the signature (POPOSign
RA received the PKI Request. This section is only applicable to RAs.</t> ingKey)
proof-of-possession choice and be set as defined in <xref
target="RFC4211" sectionFormat="comma" section="4.1"/> for both signatu
re and key establishment certification requests. The POPOSigningKey poposkInput
field <bcp14>MUST</bcp14> be omitted. The POPOSigningKey algorithmIdentifier <b
cp14>MUST</bcp14> be ecdsa-with-sha384 for P-384 certification requests and sha3
84WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification req
uests. The signature <bcp14>MUST</bcp14> be generated using the private key cor
responding to the public key in the CertTemplate.</li>
</ul>
<section anchor="ra-proc-reqst" title="RA Processing of Requests"> <t>The CertTemplate <bcp14>MUST</bcp14> comply with <xref target="RFC5272" secti
onFormat="comma" section="3.2.1.2.2"/>, with the following additional requiremen
ts:
</t>
<t>RAs conforming to this document MUST ensure that only the permitted signat <ul spacing="normal">
ure, hash, and MAC algorithms described throughout this profile are used in requ <li>If version is included, it <bcp14>MUST</bcp14> be set to 2 as defi
ests; if they are not, the RA MUST reject those requests. The RA SHOULD return ned in
a CMCFailInfo with the value of badAlg <xref target="RFC5272" />.</t> <xref target="RFC8603" sectionFormat="of" section="5.3"/>.</li>
<li>publicKey <bcp14>MUST</bcp14> be set as defined in <xref
target="RFC8603" sectionFormat="of" section="5.4"/>.</li>
<li>
<t>Extensions:</t>
<ul spacing="normal">
<li>The keyUsage extension <bcp14>MUST</bcp14> be included, and it
<bcp14>MUST</bcp14> be set as defined in <xref target="RFC8603" format="default
"/>.</li>
<li>For rekey requests, the SubjectAltName extension <bcp14>MUST</
bcp14> be included and set equal to the SubjectAltName of the certificate that i
s being used to sign the SignedData encapsulating the request (i.e., not the cer
tificate being rekeyed) if the subject name of the certificate being used to gen
erate the signature is NULL.</li>
<li>Other extension requests <bcp14>MAY</bcp14> be included as des
ired.</li>
</ul>
</li>
<li>
<t>Controls:
<t>When processing end-entity-generated SignedData objects, RAs MUST NOT perf </t>
orm Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate ext <ul spacing="normal">
ension processing <xref target="RFC6010" />.</t> <li>The ChangeSubjectName attribute, as defined in <xref target="R
FC6402" format="default"/>, <bcp14>MUST</bcp14> be included if the Full PKI Requ
est encapsulating this Tagged Certification Request is being signed by a key for
which a certificate currently exists and the existing certificate's subject nam
e or SubjectAltName extension does not match the desired subject name or Subject
AltName extension of this certification request.</li>
<li>The POP Link Witness Version 2 attribute <bcp14>MUST</bcp14> b
e included if the request is being authenticated using a shared-secret and the s
ubject name in the certification request is NULL or otherwise does not uniquely
identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlg
orithm <bcp14>MUST</bcp14> be id-sha384 for certification requests; macAlgorithm
<bcp14>MUST</bcp14> be HMAC-SHA384 when keyGenAlgorithm is id-sha384.</li>
</ul>
</li>
</ul>
</section>
<!-- cert-reqst-msg -->
<t>Other RA processing is as in <xref target="RFC5272" />.</t> </section>
<!-- client-reqts-gen -->
</section> <!-- ra-proc-reqsts --> <section anchor="ra_reqts" numbered="true" toc="default">
<name>RA Requirements</name>
<t>This section addresses the optional case where one or more RAs act as
intermediaries between clients and a CA as described in <xref target="RFC5
272" sectionFormat="of" section="7"/>. In this section, the term "client" refer
s to the entity from which the RA received the PKI Request. This section is only
applicable to RAs.</t>
<section anchor="ra-proc-reqst" numbered="true" toc="default">
<name>RA Processing of Requests</name>
<t>RAs conforming to this document <bcp14>MUST</bcp14> ensure that only
the permitted signature, hash, and MAC algorithms described throughout this prof
ile are used in requests; if they are not, the RA <bcp14>MUST</bcp14> reject tho
se requests. The RA <bcp14>SHOULD</bcp14> return a CMCFailInfo with the value o
f badAlg <xref target="RFC5272" format="default"/>.</t>
<t>When processing end-entity-generated SignedData objects, RAs <bcp14>M
UST NOT</bcp14> perform Cryptographic Message Syntax (CMS) Content Constraints (
CCC) certificate extension processing <xref target="RFC6010" format="default"/>.
</t>
<t>Other RA processing is performed as described in <xref target="RFC527
2" format="default"/>.</t>
</section>
<!-- ra-proc-reqsts -->
<section anchor="ra-gend-pki-reqst" title="RA-Generated PKI Requests"> <section anchor="ra-gend-pki-reqst" numbered="true" toc="default">
<t>RAs mediate the certificate request process by collecting Client requests in batches. The RA MUST encapsulate client-generated PKI Requests in a new RA-si gned PKI Request, it MUST create a Full PKI Request encapsulated in a SignedData , and the SignedData MUST be constructed in accordance with <xref target="ID.cns a-smime-profile" />. The PKIData content type complies with <xref target="RFC52 72" /> with the following additional requirements: <name>RA-Generated PKI Requests</name>
<list style="symbols"> <t>RAs mediate the certificate request process by collecting client requ
<t>controlSequence MUST be present. It MUST include the following CMC cont ests in batches. The RA <bcp14>MUST</bcp14> encapsulate client-generated PKI Req
rols: Transaction ID, Sender Nonce, and Batch Requests. Other appropriate CMC co uests in a new RA-signed PKI Request, it <bcp14>MUST</bcp14> create a Full PKI R
ntrols MAY be included.</t> equest encapsulated in a SignedData, and the SignedData <bcp14>MUST</bcp14> be c
<t>cmsSequence MUST be present. It contains the original, unmodified requ onstructed in accordance with <xref target="RFC8755" format="default"/>. The PK
est(s) received from the client.</t> IData content type complies with <xref target="RFC5272" format="default"/> with
</list></t> the following additional requirements:
<figure><artwork align="left"> </t>
<ul spacing="normal">
<li>controlSequence <bcp14>MUST</bcp14> be present. It
<bcp14>MUST</bcp14> include the following CMC controls: Transaction
ID, Sender Nonce, and Batch Requests. Other appropriate CMC controls
<bcp14>MAY</bcp14> be included.</li>
<li>cmsSequence <bcp14>MUST</bcp14> be present. It contains the origi
nal, unmodified request(s) received from the client.</li>
</ul>
<sourcecode name="" type=""><![CDATA[
SignedData (applied by the RA) SignedData (applied by the RA)
PKIData PKIData
controlSequence (Transaction ID, Sender Nonce, controlSequence (Transaction ID, Sender Nonce,
Batch Requests) Batch Requests)
cmsSequence cmsSequence
SignedData (applied by Client) SignedData (applied by client)
PKIData PKIData
controlSequence (Transaction ID, Sender Nonce) controlSequence (Transaction ID, Sender Nonce)
reqSequence reqSequence
TaggedRequest TaggedRequest
{TaggedRequest} {TaggedRequest}
{SignedData (second Client request) {SignedData (second client request)
PKIData...} PKIData...}
</artwork></figure> ]]></sourcecode>
<t>Authorization to sign RA-generated Full PKI Requests
<t>Authorization to sign RA-generated Full PKI Requests SHOULD be indicated i <bcp14>SHOULD</bcp14> be indicated in the RA certificate by inclusion
n the RA certificate by inclusion of the id-kp-cmcRA EKU from <xref target="RFC6 of the id-kp-cmcRA Extended Key Usage (EKU) from <xref target="RFC6402"
402" />. The RA certificate MAY also include the CCC certificate extension <xref format="default"/>. The RA certificate <bcp14>MAY</bcp14> also include
target="RFC6010" />, or it MAY indicate authorization through inclusion of the the CCC certificate extension <xref target="RFC6010"
CCC certificate extension alone. The RA certificate may also be authorized throu format="default"/>, or it <bcp14>MAY</bcp14> indicate authorization
gh local configuration.</t> through inclusion of the CCC certificate extension alone. The RA
certificate may also be authorized through the local configuration.</t>
<t>If the RA is authorized via the CCC extension, then the CCC extension MUST <t>If the RA is authorized via the CCC extension, then the CCC extension
include the object identifier for the PKIData content type. CCC SHOULD be inclu <bcp14>MUST</bcp14> include the object identifier for the PKIData content type.
ded if constraints are to be placed on the content types generated.</t> CCC <bcp14>SHOULD</bcp14> be included if constraints are to be placed on the co
ntent types generated.</t>
<t>The outer SignedData MUST be generated using SHA-384 and either ECDSA on P
-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 k
ey.</t>
<t>If the Full PKI Response is a successful response to a PKI Request that on
ly contained a Get Certificate or Get CRL control, then the algorithm used in th
e response and MUST match the algorithm used in the request.</t>
</section> <!-- ra-gend-pki-reqst -->
<section anchor="ra-gend-resp" title="RA-Generated PKI Responses">
<t>In order for an RA certificate using the CCC certificate extension to be a
uthorized to generate responses, the object identifier for the PKIResponse conte
nt type must be present in the CCC certificate extension.</t>
</section> <!-- ra-gend-resp -->
</section> <!-- ra-reqts -->
<section anchor="ca-reqts" title="CA Requirements">
<t>This section specifies the requirements for CAs that receive PKI Requests and
that generate PKI Responses.</t>
<section anchor="ca-proc-reqst" title="CA Processing of PKI Requests">
<t>CAs conforming to this document MUST ensure that only the permitted signat
ure, hash, and MAC algorithms described throughout this profile are used in requ
ests; 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 va
lue of badAlg <xref target="RFC5272" />.</t>
<t>For requests involving an RA (i.e., batched requests), 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 ext
ension. The request MUST be rejected if an attempt to modify those certificatio
n request fields is present. The CA SHOULD return a CMCStatusInfoV2 control wit
h CMCStatus of failed and a CMCFailInfo with a value of badRequest.</t>
<t>When processing end-entity-generated SignedData objects, CAs MUST NOT perf <t>The outer SignedData <bcp14>MUST</bcp14> be generated using SHA-384 and eithe
orm CCC certificate extension processing <xref target="RFC6010" />.</t> r ECDSA on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 o
r RSA-4096 key.
</t>
<t>If a client-generated PKI Request includes the ChangeSubjectName attribute <t>If the Full PKI Response is a successful response to a PKI Request that only
as described in <xref target="tgd-cert-reqst" /> or <xref target="cert-reqst-msg contained a Get Certificate or Get CRL control, then the algorithm used in the r
" /> above, the CA MUST ensure that name change is authorized. The mechanism for esponse <bcp14>MUST</bcp14> match the algorithm used in the request.
ensuring that the name change is authorized is out of scope. A CA that perform </t>
s this check and finds that the name change is not authorized MUST reject the PK
I Request. The CA SHOULD return an Extended CMC Status Info control (CMCStatusIn
foV2) with CMCStatus of failed.</t>
<t>Other processing of PKIRequests is as in <xref target="RFC5272" />.</t> </section>
</section> <!-- ca-proc-reqst --> <!-- ra-gend-pki-reqst -->
<section anchor="ca-gend-resp" title="CA-Generated PKI Responses"> <section anchor="ra-gend-resp" numbered="true" toc="default">
<name>RA-Generated PKI Responses</name>
<t>In order for an RA certificate using the CCC certificate extension to
be authorized to generate responses, the object identifier for the PKIResponse
content type must be present in the CCC certificate extension.</t>
</section>
<!-- ra-gend-resp -->
<t>CAs send PKI Responses to both Client-generated requests and RA-generated </section>
requests. If a Full PKI Response is returned in direct response to a Client-gene <!-- ra-reqts -->
rated request, it MUST be encapsulated in a SignedData, and the SignedData MUST
be constructed in accordance with <xref target="ID.cnsa-smime-profile" />.</t>
<t>If the PKI Response is in response to an RA-generated PKI Request, then th <section anchor="ca-reqts" numbered="true" toc="default">
e above PKI Response is encapsulated in another CA-generated PKI Response. That <name>CA Requirements</name>
PKI Response MUST be encapsulated in a SignedData and the SignedData MUST be co <t>This section specifies the requirements for CAs that receive PKI Reques
nstructed in accordance with <xref target="ID.cnsa-smime-profile" />. The above ts and generate PKI Responses.</t>
PKI Response is placed in the encapsulating PKI Response cmsSequence field. Th <section anchor="ca-proc-reqst" numbered="true" toc="default">
e other fields are as above with the addition of the batch response control in c <name>CA Processing of PKI Requests</name>
ontrolSequence. The following illustrates a successful CA response to an RA-enc <t>CAs conforming to this document <bcp14>MUST</bcp14> ensure that
apsulated PKI Request, both of which include Transaction IDs and Nonces:</t> only the permitted signature, hash, and MAC algorithms described
throughout this profile are used in requests; if they are not, the CA
<bcp14>MUST</bcp14> reject those requests. The CA
<bcp14>SHOULD</bcp14> return a CMCStatusInfoV2 control with a CMCStatus o
f failed and a CMCFailInfo with the value of badAlg <xref target="RFC5272" forma
t="default"/>.</t>
<t>For requests involving an RA (i.e., batched requests), the CA
<bcp14>MUST</bcp14> verify the RA's authorization. The following
certificate fields <bcp14>MUST NOT</bcp14> be modifiable using the
Modify Certification Request control: publicKey and the keyUsage
extension. The request <bcp14>MUST</bcp14> be rejected if an attempt
to modify those certification request fields is present. The CA
<bcp14>SHOULD</bcp14> return a CMCStatusInfoV2 control with a CMCStatus o
f failed and a CMCFailInfo with a value of badRequest.</t>
<t>When processing end-entity-generated SignedData objects, CAs <bcp14>M
UST NOT</bcp14> perform CCC certificate extension processing <xref target="RFC60
10" format="default"/>.</t>
<t>If a client-generated PKI Request includes the ChangeSubjectName
attribute as described in <xref target="tgd-cert-reqst"
format="default"/> or <xref target="cert-reqst-msg" format="counter"/>
above, the CA <bcp14>MUST</bcp14> ensure that name change is
authorized. The mechanism for ensuring that the name change is
authorized is out of scope. A CA that performs this check and finds
that the name change is not authorized <bcp14>MUST</bcp14> reject the
PKI Request. The CA <bcp14>SHOULD</bcp14> return an Extended CMC
Status Info control (CMCStatusInfoV2) with a CMCStatus of failed.</t>
<t>Other processing of PKIRequests is performed as described in <xref ta
rget="RFC5272" format="default"/>.</t>
</section>
<!-- ca-proc-reqst -->
<figure><artwork align="left"> <section anchor="ca-gend-resp" numbered="true" toc="default">
<name>CA-Generated PKI Responses</name>
<t>CAs send PKI Responses to both client-generated requests and RA-gener
ated requests. If a Full PKI Response is returned in direct response to a client
-generated request, it <bcp14>MUST</bcp14> be encapsulated in a SignedData, and
the SignedData <bcp14>MUST</bcp14> be constructed in accordance with <xref targe
t="RFC8755" format="default"/>.</t>
<t>If the PKI Response is in response to an RA-generated PKI Request, th
en the above PKI Response is encapsulated in another CA-generated PKI Response.
That PKI Response <bcp14>MUST</bcp14> be encapsulated in a SignedData, and the
SignedData <bcp14>MUST</bcp14> be constructed in accordance with <xref target="R
FC8755" format="default"/>. The above PKI Response is placed in the encapsulati
ng PKI Response cmsSequence field. The other fields are as above with the addit
ion of the batch response control in controlSequence. The following illustrates
a successful CA response to an RA-encapsulated PKI Request, both of which inclu
de Transaction IDs and Nonces:</t>
<sourcecode name="" type=""><![CDATA[
SignedData (applied by the CA) SignedData (applied by the CA)
PKIResponse PKIResponse
controlSequence (Transaction ID, Sender Nonce, Recipient controlSequence (Transaction ID, Sender Nonce, Recipient
Nonce, Batch Response) Nonce, Batch Response)
cmsSequence cmsSequence
SignedData (applied by CA and includes returned SignedData (applied by CA and includes returned
certificates) certificates)
PKIResponse PKIResponse
controlSequence (Transaction ID, Sender Nonce, controlSequence (Transaction ID, Sender Nonce,
Recipient Nonce) Recipient Nonce)
</artwork></figure> ]]></sourcecode>
<t>The same private key used to sign certificates <bcp14>MUST NOT</bcp14
<t>The same private key used to sign certificates MUST NOT be used to sign Fu > be used to sign Full PKI Response messages. Instead, a separate certificate i
ll PKI Response messages. Instead, a separate certificate indicating authorizat ndicating authorization to sign CMC responses <bcp14>MUST</bcp14> be used.</t>
ion to sign CMC responses MUST be used.</t> <t>Authorization to sign Full PKI Responses <bcp14>SHOULD</bcp14> be ind
icated in the CA certificate by inclusion of the id-kp-cmcCA EKU from <xref targ
<t>Authorization to sign Full PKI Responses SHOULD be indicated in the CA cer et="RFC6402" format="default"/>. The CA certificate <bcp14>MAY</bcp14> also incl
tificate by inclusion of the id-kp-cmcCA EKU from <xref target="RFC6402" />. The ude the CCC certificate extension <xref target="RFC6010" format="default"/>, or
CA certificate MAY also include the CCC certificate extension <xref target="RFC it <bcp14>MAY</bcp14> indicate authorization through inclusion of the CCC certif
6010" />, or it MAY indicate authorization through inclusion of the CCC certific icate extension alone. The CA certificate may also be authorized through local c
ate extension alone. The CA certificate may also be authorized through local con onfiguration.</t>
figuration.</t> <t>In order for a CA certificate using the CCC certificate extension to
be authorized to generate responses, the object identifier for the PKIResponse c
<t>In order for an CA certificate using the CCC certificate extension to be a ontent type must be present in the CCC certificate extension. CCC <bcp14>SHOULD<
uthorized to generate responses, the object identifier for the PKIResponse conte /bcp14> be included if constraints are to be placed on the content types generat
nt type must be present in the CCC certificate extension. CCC SHOULD be included ed.</t>
if constraints are to be placed on the content types generated.</t> <t>Signatures applied to individual certificates are as required in <xre
f target="RFC8603" format="default"/>.</t>
<t>Signatures applied to individual certificates are as required in <xref tar <t>The signature on the SignedData of a successful response to a
get="ID.cnsa-cert-profile" />.</t> client-generated request, or each individual inner SignedData on the
successful response to an RA-generated request, <bcp14>MUST</bcp14> be
<t>The signature on the SignedData of a successful response to a Client-gener generated using SHA-384 and either ECDSA on P-384 or RSA using
ated request, or each individual inner SignedData on the successful response to RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key. An
a RA-generated request, MUST be generated using SHA-384 and either ECDSA on P-38 unsuccessful response <bcp14>MUST</bcp14> be signed using the same key
4 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key. type and algorithm that signed the request.</t>
An unsuccessful response MUST be signed using the same key-type and algorithm t <t>The outer SignedData on the Full PKI Response to any RA-generated
hat signed the request.</t> PKI Request <bcp14>MUST</bcp14> be signed with the same key type and algo
rithm that signed the request.</t>
<t>The outer SignedData on the Full PKI Response to any RA-generated PKI Requ <t>The SignedData on a successful Full PKI Response to a PKI Request
est MUST be signed with the same key-type and algorithm that signed the request. that only contained a Get Certificate or Get CRL control
</t> <bcp14>MUST</bcp14> be signed with the same key type and algorithm that s
igned the request.</t>
<t>The SignedData on a successful Full PKI Response to a PKI Request that onl </section>
y contained a Get Certificate or Get CRL control MUST be signed with the same ke <!-- ca-gend-resp -->
y-type and algorithm that signed the request.</t>
</section> <!-- ca-gend-resp -->
</section> <!-- ca-reqts -->
<section anchor="client-reqts-proc" title="Client Requirements: Processing PKI R
esponses">
<t>Clients conforming to this document MUST ensure that only the permitted signa
ture, hash, and MAC algorithms described throughout this profile are used in res
ponses; if they are not, the client MUST reject those responses.</t>
<t>Clients MUST authenticate all Full PKI Responses. This includes verifying th
at the PKI Response is signed by an authorized CA or RA whose certificate valida
tes back to a trust anchor. The authorized CA certificate MUST include the id-k
p-cmcCA EKU and/or include a CCC extension that includes the object identifier f
or the PKIResponse content type. Or, the CA is determined to be authorized to s
ign responses through an implementation-specific mechanism. The PKI Response ca
n be signed by an RA if it is an error message, if it is a response to a Get Cer
tificate or Get CRL request, or if the PKI Response contains an inner PKI Respon
se signed by a CA. In the last case, each layer of PKI Response MUST still cont
ain 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 extension that includes t
he object identifier for the PKIResponse content type. Or, the RA is determined
to be authorized to sign responses through local configuration.</t>
<t>When a newly issued certificate is included in the PKI Response, the client M
UST 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.</t>
<t>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 C
MC Status Info control (CMCStatusInfoV2) with CMCStatus set to failed to a user
console, error log, or the server.</t>
<t>If the Full PKI Response contains an Extended CMC Status Info control with a
CMCStatus set to failed, then local policy will determine whether the client res
ends a duplicate certification request back to the server or an error state is r
eturned to a console or error log.</t>
</section> <!-- client-reqts-proc -->
<section anchor="shared-secrets" title="Shared-Secrets">
<t>When the Identity Proof V2 and POP Link Witness V2 controls are used, the sha
red-secret MUST be randomly generated and securely distributed. The shared-secr
et MUST provide at least 192 bits of strength.</t>
</section> <!-- shared-secrets -->
<section anchor="sec-considerations" title="Security Considerations">
<t>Protocol security considerations are found in <xref target="RFC2986" />, <xre
f target="RFC4211" />, <xref target="ID.cnsa-smime-profile" />, <xref target="RF
C5272" />, <xref target="RFC5273" />, <xref target="RFC5274" />, <xref target="I
D.cnsa-cert-profile" />, and <xref target="RFC6402" />. When CCC is used to auth
orize RA and CA certificates, then the security considerations in <xref target="
RFC6010" /> also apply. Algorithm security considerations are found in <xref ta
rget="ID.cnsa-smime-profile" />.</t>
<t>Compliant with NIST Special Publication 800-57 <xref target="SP80057" />, thi
s profile defines proof-of-possession of a key establishment private key by perf
orming a digital signature. Except for one-time proof-of-possession, a single k
ey pair MUST NOT be used for both signature and key establishment.</t>
<t>This specification requires implementations to generate key pairs and other r
andom values. The use of inadequate pseudo-random number generators (PRNGs) can
result in little or no security. The generation of quality random numbers is d
ifficult. NIST Special Publication 800-90A <xref target="SP80090A" />, FIPS 186
-3 <xref target="FIPS186" />, and <xref target="RFC4086" /> offer random number
generation guidance.</t>
<t>When RAs are used, the list of authorized RAs MUST be securely distributed ou
t-of-band to CAs.</t>
<t>Presence of the POP Link Witness Version 2 and POP Link Random attributes pro
tects against substitution attacks.</t>
<t>The Certificate Policy for a particular environment will specify whether expi </section>
red certificates can be used to sign certification requests.</t> <!-- ca-reqts -->
</section> <!-- sec-considerations --> <section anchor="client-reqts-proc" numbered="true" toc="default">
<name>Client Requirements: Processing PKI Responses</name>
<t>Clients conforming to this document <bcp14>MUST</bcp14> ensure that onl
y the permitted signature, hash, and MAC algorithms described throughout this pr
ofile are used in responses; if they are not, the client <bcp14>MUST</bcp14> rej
ect those responses.</t>
<t>Clients <bcp14>MUST</bcp14> authenticate all Full PKI Responses. This
includes verifying that the PKI Response is signed by an authorized CA or RA who
se certificate validates back to a trust anchor. The authorized CA certificate
<bcp14>MUST</bcp14> include the id-kp-cmcCA EKU and/or a CCC extension that incl
udes the object identifier for the PKIResponse content type. Otherwise, the CA
is determined to be authorized to sign responses through an implementation-speci
fic mechanism. The PKI Response can be signed by an RA if it is an error messag
e, if it is a response to a Get Certificate or Get CRL request, or if the PKI Re
sponse contains an inner PKI Response signed by a CA. In the last case, each la
yer of PKI Response <bcp14>MUST</bcp14> still contain an authorized, valid signa
ture signed by an entity with a valid certificate that verifies back to an accep
table trust anchor. The authorized RA certificate <bcp14>MUST</bcp14> include t
he id-kp-cmcRA EKU and/or include a CCC extension that includes the object ident
ifier for the PKIResponse content type. Otherwise, the RA is determined to be a
uthorized to sign responses through local configuration.</t>
<t>When a newly issued certificate is included in the PKI Response, the cl
ient <bcp14>MUST</bcp14> verify that the newly issued certificate's public key m
atches the public key that the client requested. The client <bcp14>MUST</bcp14>
also ensure that the certificate's signature is valid and that the signature va
lidates back to an acceptable trust anchor.</t>
<t>Clients <bcp14>MUST</bcp14> 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
(CMCStatusInfoV2) with the CMCStatus set to failed to a user console, erro
r log, or the server.</t>
<t>If the Full PKI Response contains an Extended CMC Status Info control w
ith a CMCStatus set to failed, then local policy will determine whether the clie
nt resends a duplicate certification request back to the server or an error stat
e is returned to a console or error log.</t>
</section>
<!-- client-reqts-proc -->
<section anchor="iana-considerations" title="IANA Considerations"> <section anchor="shared-secrets" numbered="true" toc="default">
<name>Shared-Secrets</name>
<t>When the Identity Proof V2 and POP Link Witness V2 controls are used, t
he shared-secret <bcp14>MUST</bcp14> be randomly generated and securely distribu
ted. The shared-secret <bcp14>MUST</bcp14> provide at least 192 bits of strengt
h.</t>
</section>
<!-- shared-secrets -->
<t>This document has no IANA actions.</t> <section anchor="sec-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Protocol security considerations are found in <xref target="RFC2986" fo
rmat="default"/>, <xref target="RFC4211" format="default"/>, <xref target="RFC87
55" format="default"/>, <xref target="RFC5272" format="default"/>, <xref target=
"RFC5273" format="default"/>, <xref target="RFC5274" format="default"/>, <xref t
arget="RFC8603" format="default"/>, and <xref target="RFC6402" format="default"/
>. When CCC is used to authorize RA and CA certificates, then the security consi
derations in <xref target="RFC6010" format="default"/> also apply. Algorithm se
curity considerations are found in <xref target="RFC8755" format="default"/>.</t
>
<t>Compliant with NIST Special Publication 800-57 <xref target="SP80057" f
ormat="default"/>, this profile defines proof-of-possession of a key establishme
nt private key by performing a digital signature. Except for one-time proof-of-
possession, a single key pair <bcp14>MUST NOT</bcp14> be used for both signature
and key establishment.</t>
<t>This specification requires implementations to generate key pairs and o
ther random values. The use of inadequate pseudorandom number generators (PRNGs
) can result in little or no security. The generation of quality random numbers
is difficult. NIST Special Publication 800-90A <xref target="SP80090A" format=
"default"/>, FIPS 186-3 <xref target="FIPS186" format="default"/>, and <xref tar
get="RFC4086" format="default"/> offer random number generation guidance.</t>
<t>When RAs are used, the list of authorized RAs <bcp14>MUST</bcp14> be
securely distributed out of band to CAs.</t>
<t>Presence of the POP Link Witness Version 2 and POP Link Random attribut
es protects against substitution attacks.</t>
<t>The certificate policy for a particular environment will specify whethe
r expired certificates can be used to sign certification requests.</t>
</section>
<!-- sec-considerations -->
</section> <!-- iana-considerations --> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<!-- iana-considerations -->
</middle> </middle>
<back>
<!-- ===== BACK MATTER ===== -->
<back> <!-- ===== BACK MATTER ===== --> <references>
<name>References</name>
<references title="Normative References"> <references>
<name>Normative References</name>
<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Polic <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/issuances/Polic
ies.htm"> ies.cfm">
<front> <front>
<title>Use of Public Standards for Secure Information Sharing</title> <title>Use of Public Standards for Secure Information Sharing</title
<author><organization>Committee for National Security Systems</organiz >
ation></author> <seriesInfo name="CNSS Policy" value="15"/>
<date month="October" year="2016"></date> <author>
</front> <organization>Committee on National Security Systems</organization
<seriesInfo name="CNSS Policy" value="15" /> >
</reference> <!-- CNSA --> </author>
<date month="October" year="2016"/>
</front>
</reference>
<!-- CNSA -->
<reference anchor="FIPS186" target="http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf"> <reference anchor="FIPS186" target="http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf">
<front> <front>
<title>Digital Signature Standard (DSS)</title> <title>Digital Signature Standard (DSS)</title>
<seriesInfo name="FIPS PUB"
value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
<author> <author>
<organization>National Institute of Standards and Technology</org anization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="July" year="2013" /> <date month="July" year="2013"/>
</front>
<seriesInfo name="Federal Information Processing Standard" value
="186-4" />
</reference> <!-- FIPS186 -->
&rfc2119;
&rfc2986;
&rfc4055;
&rfc4056;
&rfc4086;
&rfc4211;
&rfc4231;
&rfc5272;
&rfc5273;
&rfc5274;
&rfc5754;
&rfc6010;
&rfc6402;
&rfc8017;
&rfc8174;
<reference anchor="ID.cnsa-smime-profile" target="https://tools.ietf.org/h
tml/draft-jenkins-cnsa-smime-profile">
<front>
<title>Using CNSA Suite Algorithms in Secure/Multipurpose Internet
Mail Extensions(S/MIME)</title>
<author initials="M." surname="Jenkins" />
<date month="February" year="2018" />
</front> </front>
<annotation>Work in progress.</annotation> </reference>
</reference> <!-- ID.cnsa-smime-profile --> <!-- FIPS186 -->
<reference anchor="ID.cnsa-cert-profile" target="https://tools.ietf.org/ht
ml/draft-jenkins-cnsa-cert-crl-profile">
<front>
<title>Commercial National Security Algorithm (CNSA) Suite Certificat
e and Certificate Revocation List (CRL) Profile</title>
<author initials="M." surname="Jenkins" />
<author initials="L." surname="Zieglar" />
<date month="January" year="2018" />
</front>
<annotation>Work in progress.</annotation>
</reference> <!-- ID.cnsa-cert-profile -->
</references>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4055.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4056.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4211.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5273.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5274.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5754.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6010.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8017.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.x
ml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8755
.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.
xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="SP80057" target="http://doi.org/10.6028/NIST.SP.800-57p t1r4"> <reference anchor="SP80057" target="http://doi.org/10.6028/NIST.SP.800-57p t1r4">
<front> <front>
<title>Recommendation for Key Management, Part 1: General</title> <title>Recommendation for Key Management, Part 1: General</title>
<author> <seriesInfo name="Special Publication" value="800-57, Part 1,
<organization>National Institute of Standards and Technology</organi Revision 4"/>
zation>
</author> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r4"/>
<date month="January" year="2016" /> <author>
</front> <organization>National Institute of Standards and Technology</orga
<seriesInfo name="Special Publication 800-57" value="" /> nization>
</reference> <!-- SP80057 --> </author>
<date month="January" year="2016"/>
</front>
</reference>
<!-- SP80057 -->
<reference anchor="SP80059" target="https://csrc.nist.gov/publications/d etail/sp/800-59/final"> <reference anchor="SP80059" target="https://csrc.nist.gov/publications/d etail/sp/800-59/final">
<front> <front>
<title>Guideline for Identifying an Information System as a Nation <title>Guideline for Identifying an Information System as a National
al Security System</title> Security System</title>
<author> <seriesInfo name="Special Publication" value="800-59"/>
<organization>National Institute of Standards and Technology</ <seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
organization> <author><organization>National Institute of Standards and Technology</organizati
</author> on></author>
<date month="August" year="2003" /> <date month="August" year="2003"/>
</front> </front>
<seriesInfo name="Special Publication 800" value="59" /> </reference>
</reference> <!-- SP80059 --> <!-- SP80059 -->
<reference anchor="SP80090A" target="http://doi.org/10.6028/NIST.SP.800-90Ar1"> <reference anchor="SP80090A" target="http://doi.org/10.6028/NIST.SP.800-90Ar1">
<front> <front>
<title>Recommendation for Random Number Generation Using Deterministic <title>Recommendation for Random Number Generation Using Determinist
Random Bit Generators</title> ic Random Bit Generators</title>
<author> <seriesInfo name="Special Publication 800-90A" value="Revision
<organization>National Institute of Standards and Technology</organi 1"/>
zation> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/>
</author> <author>
<date month="June" year="2015" /> <organization>National Institute of Standards and Technology</orga
</front> nization>
<seriesInfo name="Special Publication 800-90A" value="Revision 1" </author>
/> <date month="June" year="2015"/>
</reference> <!-- SP80090A --> </front>
</reference>
<!-- SP80090A -->
</references> </references>
</references>
<section anchor="scenarios" title="Scenarios"> <!-- Appendix A --> <section anchor="scenarios" numbered="true" toc="default">
<name>Scenarios</name>
<!-- Appendix A -->
<t>This section illustrates several potential certificate enrollment and rekey s cenarios supported by this profile. This section does not intend to place any l imits or restrictions on the use of CMC.</t> <t>This section illustrates several potential certificate enrollment and rekey s cenarios supported by this profile. This section does not intend to place any l imits or restrictions on the use of CMC.</t>
<section anchor="init_enroll" numbered="true" toc="default">
<name>Initial Enrollment</name>
<t>This section describes three scenarios for authenticating initial enr
ollment requests:
</t>
<ol spacing="normal" type="1">
<li>Previously certified signature key-pair (e.g., Manufacturer Instal
led Certificate).</li>
<li>Shared-secret distributed securely out of band.</li>
<li>RA authentication.</li>
</ol>
<section anchor="prev_inst" numbered="true" toc="default">
<name>Previously Certified Signature Key-Pair</name>
<t>In this scenario, the end-entity has a private signing key and a co
rresponding public key certificate obtained from a cryptographic module manufact
urer recognized by the CA. The end-entity signs a Full PKI Request with the priv
ate key that corresponds to the subject public key of the previously installed s
ignature certificate. The CA will verify the authorization of the previously ins
talled certificate and issue an appropriate new certificate to the end-entity.</
t>
</section>
<!-- prev_inst -->
<section anchor="init_enroll" title="Initial Enrollment"> <section anchor="ss_oob" numbered="true" toc="default">
<name>Shared-Secret Distributed Securely Out of Band</name>
<t>This section describes three scenarios for authenticating initial enrollme <t>In this scenario, the CA distributes a shared-secret out of band
nt requests: to the end-entity that the end-entity uses to authenticate its
<list style="numbers"> certification request. The end-entity signs the Full PKI Request
<t>Previously certified signature key-pair (e.g., Manufacturer Installed C with the private key for which the certification is being
ertificate);</t> requested. The end-entity includes the Identity Proof Version 2
<t>Shared-secret distributed securely out-of-band;</t> control to authenticate the request using the shared-secret. The CA
<t>RA authentication.</t> uses either the Identification control or the subject name in the
</list></t> end-entity's enclosed PKCS #10 <xref target="RFC2986"
format="default"/> or CRMF <xref target="RFC4211" format="default"/>
<section anchor="prev_inst" title="Previously Certified Signature Key-pair certification request message to identify the request. The
"> end-entity performs either the POP Link Witness Version 2 mechanism
as described in <xref target="RFC5272" sectionFormat="comma"
<t>In this scenario, the end-entity has a private signing key, and a corre section="6.3.1.1"/> or the shared-secret/subject distinguished
sponding public key certificate obtained from a cryptographic module manufacture name linking mechanism as described in <xref target="RFC5272"
r recognized by the CA. The end-entity signs a Full PKI Request with the private sectionFormat="comma" section="6.3.2"/>. The subject name in the
key that corresponds to the subject public key of the previously installed sign enclosed PKCS #10 <xref target="RFC2986" format="default"/> or CRMF <xr
ature certificate. The CA will verify the authorization of the previously instal ef target="RFC4211" format="default"/> certification
led certificate and issue an appropriate new certificate to the end-entity.</t> request does not necessarily match the issued certificate, as it may
be used just to help identify the request (and the corresponding shared
</section> <!-- prev_inst --> -secret) to the CA.</t>
</section>
<section anchor="ss_oob" title="Shared-Secret Distributed Securely Out-of- <!-- ss_oob -->
Band">
<t>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 ce
rtification is being requested. The end-entity includes the Identity Proof Versi
on 2 control to authenticate the request using the shared-secret. The CA uses e
ither the Identification control or the Subject in the end-entity's enclosed <xr
ef target="RFC2986">PKCS #10</xref> or <xref target="RFC4211">CRMF</xref> certif
ication request message to identify the request. The end-entity performs either
the POP Link Witness Version 2 mechanism as described in <xref target="RFC5272"
/>, Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name (DN) link
ing mechanism as described in <xref target="RFC5272" />, Section 6.3.2. The Sub
ject in the enclosed <xref target="RFC2986">PKCS #10</xref> or <xref target="RFC
4211">CRMF</xref> certification request does not necessarily match the issued ce
rtificate, as it may be used just to help identify the request (and correspondin
g shared-secret) to the CA.</t>
</section> <!-- ss_oob -->
<section anchor="ra_auth" title="RA Authentication">
<t>In this scenario, the end-entity does not automatically authenticate it
s enrollment request to the CA, either because the end-entity has nothing to aut
henticate the request with or because organizational policy requires an RA's inv
olvement. 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 an
d signs the request as described in Section 5.2, forwarding the new request on t
o the CA. The Subject in the <xref target="RFC2986">PKCS #10</xref> or <xref tar
get="RFC4211">CRMF</xref> certification request is not required to match the iss
ued certificate, it may be used just to help identify the request to the RA and/
or CA.</t>
</section> <!-- ra_auth -->
</section> <!-- init_enroll -->
<section anchor="rekey" title="Rekey">
<t>There are two scenarios to support the rekey of certificates that are alre
ady enrolled. One addresses the rekey of signature certificates and the other a
ddresses 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.</t>
<section anchor="rk_sig" title="Rekey of Signature Certificates"> <section anchor="ra_auth" numbered="true" toc="default">
<name>RA Authentication</name>
<t>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
the organizational policy requires an RA's involvement. The end-entity
creates a Full PKI Request and sends it to an RA. The RA verifies
the authenticity of the request. If the request is approved, the RA enc
apsulates and
signs the request as described in <xref target="cert-reqst-msg"/>,
forwarding the new request on to the CA. The subject name in the PKCS
#10 <xref target="RFC2986" format="default"/> or CRMF <xref
target="RFC4211" format="default"/> certification request is not requir
ed to match the issued certificate; it may be used just to help identify the req
uest to the RA and/or CA.</t>
</section>
<!-- ra_auth -->
<t>When a signature certificate is rekeyed, the <xref target="RFC2986">PKC </section>
S #10</xref> or <xref target="RFC4211">CRMF</xref> certification request message <!-- init_enroll -->
enclosed in the Full PKI Request will include the same Subject as the current s
ignature certificate. The Full PKI Request will be signed by the current privat
e key corresponding to the current signature certificate.</t>
</section> <!-- rk_sig --> <section anchor="rekey" numbered="true" toc="default">
<name>Rekey</name>
<t>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 mig
ht allow a grace period during which an expired certificate could be used to rek
ey.</t>
<section anchor="rk_sig" numbered="true" toc="default">
<name>Rekey of Signature Certificates</name>
<t>When a signature certificate is rekeyed, the <xref
target="RFC2986" format="default">PKCS #10</xref> or <xref target="RFC4
211" format="default">CRMF</xref> certification request message enclosed in the
Full PKI Request will include the same subject name as the current signature cer
tificate. The Full PKI Request will be signed by the current private key corres
ponding to the current signature certificate.</t>
</section>
<!-- rk_sig -->
<section anchor="rk_kes" title="Rekey of Key Establishment Certificates"> <section anchor="rk_kes" numbered="true" toc="default">
<t>When a key establishment certificate is rekeyed, the Full PKI Request w ill 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. </t> <name>Rekey of Key Establishment Certificates</name>
</section> <!-- rk_kes --> <t>When a key establishment certificate is rekeyed, the Full PKI Request will ge
nerally be signed by the current private key corresponding to the current signat
ure certificate. If there is no current signature certificate, one of the initi
al enrollment options in <xref target="init_enroll"/> may be used.
</t>
</section>
<!-- rk_kes -->
</section> <!-- rekey --> </section>
<!-- rekey -->
</section> <!-- scenarios --> </section>
<!-- scenarios -->
</back> <!-- ===== END BACK MATTER ===== --> </back>
<!-- ===== END BACK MATTER ===== -->
</rfc> </rfc>
 End of changes. 96 change blocks. 
796 lines changed or deleted 833 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/