Movatterモバイル変換

Internet Engineering Task Force (IETF)                        L. ZieglarRequest for Comments: 6403                                           NSACategory: Informational                                        S. TurnerISSN: 2070-1721                                                     IECA                                                                 M. Peck                                                           November 2011Suite B Profile of Certificate Management over CMSAbstract   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.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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6403.Copyright Notice   Copyright (c) 2011 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 mustZieglar, et al.               Informational                     [Page 1]

RFC 6403                   Suite B CMC Profile             November 2011   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.1.  Introduction   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.2.  Terminology   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].   The terminology in[RFC5272] Section 2.1 applies to this profile.3.  Requirements and Assumptions   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.   This document assumes that the required trust anchors have been   securely provisioned to the client and, when applicable, to any RAs.   All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402]   apply, except where overridden by this profile.   This profile was developed with the scenarios described inAppendix A   in mind.  However, use of this profile is not limited to just those   scenarios.   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 thatZieglar, et al.               Informational                     [Page 2]

RFC 6403                   Suite B CMC Profile             November 2011   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.   This profile uses the term "rekey" in the same manner as does CMC   (defined inSection 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.   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.   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.4.  Client Requirements: Generating PKI Requests   This section specifies the conventions employed when a client   requests a certificate from a Public Key Infrastructure (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:   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 Sections4.1 and4.2.Zieglar, et al.               Informational                     [Page 3]

RFC 6403                   Suite B CMC Profile             November 2011   o  reqSequence MUST be present.  It MUST include at least one tcr      (seeSection 4.1) or crm (seeSection 4.2) TaggedRequest.  Support      for the orm choice is OPTIONAL.   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.   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.   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.4.1.  Tagged Certification Request   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:   o  certificationRequestInfo:      *  subjectPublicKeyInfo MUST be set as defined inSection 4.4 of         [RFC5759];      *  attributes:         -  The ExtensionReq attribute MUST be included with its            contents as follows:            o  The Key Usage extension MUST be included, and it MUST be               set as defined in [RFC5759].Zieglar, et al.               Informational                     [Page 4]

RFC 6403                   Suite B CMC Profile             November 2011            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  Other extension requests MAY be included as desired.         -  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.         -  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].      *  signatureAlgorithm MUST be ecdsa-with-sha256 for P-256         certification requests and MUST be ecdsa-with-sha384 for P-384         certification requests;      *  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.4.2.  Certificate Request Message   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:   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.Zieglar, et al.               Informational                     [Page 5]

RFC 6403                   Suite B CMC Profile             November 2011      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.   The CertTemplate MUST comply with[RFC5272], Section 3.2.1.2.2, with   the following additional requirements:   o  version MAY be included and, if included, it MUST be set to 2 as      defined inSection 4.3 of [RFC5759];   o  publicKey MUST be set as defined inSection 4.4 of [RFC5759];   o  extensions:      *  The Key Usage extension MUST be included, and it MUST be set as         defined in [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.      *  Other extension requests MAY be included as desired.   o  controls:      *  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.      *  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.Zieglar, et al.               Informational                     [Page 6]

RFC 6403                   Suite B CMC Profile             November 20115.  RA Requirements   This section addresses the optional case where one or more RAs act as   intermediaries between the client and CA as described inSection 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.5.1.  RA Processing of Requests   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].   When processing end-entity-generated SignedData objects, RAs MUST NOT   perform Cryptographic Message Syntax (CMS) Content Constraints (CCC)   certificate extension processing [RFC6010].   Other RA processing is as in [RFC5272].5.2.  RA-Generated PKI Requests   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:   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  cmsSequence MUST be present.  It contains the original, unmodified      request(s) received from the client.   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.Zieglar, et al.               Informational                     [Page 7]

RFC 6403                   Suite B CMC Profile             November 2011   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.5.3.  RA-Generated Errors   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.6.  CA Requirements   This section specifies the requirements for CAs that receive PKI   Requests and that generate PKI Responses.6.1.  CA Processing of PKI Requests   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].   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.   When processing end-entity-generated SignedData objects, CAs MUST NOT   perform CCC certificate extension processing [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 CAZieglar, et al.               Informational                     [Page 8]

RFC 6403                   Suite B CMC Profile             November 2011   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.   Other processing of PKIRequests is as in [RFC5272].6.2.  CA-Generated PKI Responses   If a Full PKI Response is returned, it MUST be encapsulated in a   SignedData, and the SignedData MUST be constructed as defined in   [RFC6318].   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:      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)   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.Zieglar, et al.               Informational                     [Page 9]

RFC 6403                   Suite B CMC Profile             November 2011   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.   If the PKI Response is in response to an RA-encapsulated PKI Request,   the signature algorithm for each SignedData is selected   independently.7.  Client Requirements: Processing PKI Responses   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.   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 CCCZieglar, et al.               Informational                    [Page 10]

RFC 6403                   Suite B CMC Profile             November 2011   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.   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.   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.   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.8.  Shared-Secrets   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.9.  Security Considerations   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].   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.   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.Zieglar, et al.               Informational                    [Page 11]

RFC 6403                   Suite B CMC Profile             November 2011   When RAs are used, the list of authorized RAs must be securely   distributed out-of-band to CAs.   Presence of the POP Link Witness Version 2 and POP Link Random   attributes protects against substitution attacks.   The Certificate Policy for a particular environment will specify   whether expired certificates can be used to sign certification   requests.10.  Acknowledgments   Michael Peck wishes to acknowledge that he was employed at the   National Security Agency during much of the work on this document.11.  References11.1.  Normative References   [DSS]      National Institute of Standards and Technology (NIST),              FIPS 186-3: Digital Signature Standard (DSS), June 2009.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification              Request Syntax Specification Version 1.7",RFC 2986,              November 2000.   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,              "Randomness Requirements for Security",BCP 106,RFC 4086,              June 2005.   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure              Certificate Request Message Format (CRMF)",RFC 4211,              September 2005.   [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.   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS              (CMC)",RFC 5272, June 2008.   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS              (CMC): Transport Protocols",RFC 5273, June 2008.Zieglar, et al.               Informational                    [Page 12]

RFC 6403                   Suite B CMC Profile             November 2011   [RFC5274]  Schaad, J. and M. Myers, "Certificate Management Messages              over CMS (CMC): Compliance Requirements",RFC 5274, June              2008.   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic              Message Syntax",RFC 5754, January 2010.   [RFC5759]  Solinas, J. and L. Zieglar, "Suite B Certificate and              Certificate Revocation List (CRL) Profile",RFC 5759,              January 2010.   [RFC6010]  Housley, R., Ashmore, S., and C. Wallace, "Cryptographic              Message Syntax (CMS) Content Constraints Extension",RFC6010, September 2010.   [RFC6318]  Housley, R. and J. Solinas, "Suite B in              Secure/Multipurpose Internet Mail Extensions (S/MIME)",RFC 6318, June 2011.   [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)              Updates",RFC 6402, November 2011.11.2.  Informative References   [SP80057]  National Institute of Standards and Technology (NIST),              Special Publication 800-57 Part 1: Recommendation for Key              Management, March 2007.   [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.Zieglar, et al.               Informational                    [Page 13]

RFC 6403                   Suite B CMC Profile             November 2011Appendix A.  Scenarios   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.A.1.  Initial Enrollment   This section describes three scenarios for authenticating initial   enrollment requests:   1. Previously installed signature certificate (e.g., Manufacturer      Installed Certificate);   2. Shared-secret distributed securely out-of-band;   3. RA authentication.A.1.1.  Previously Installed Signature Certificate   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.A.1.2.  Shared-Secret Distributed Securely Out-of-Band   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.Zieglar, et al.               Informational                    [Page 14]

RFC 6403                   Suite B CMC Profile             November 2011A.1.3.  RA Authentication   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 inSection 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.A.2.  Rekey   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.A.2.1.  Rekey of Signature Certificates   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.A.2.2.  Rekey of Key Establishment Certificates   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 inAppendix A.1   may be used.Zieglar, et al.               Informational                    [Page 15]

RFC 6403                   Suite B CMC Profile             November 2011Authors' Addresses   Lydia Zieglar   National Information Assurance Research Laboratory   National Security Agency   EMail: llziegl@tycho.ncsc.mil   Sean Turner   IECA, Inc.   3057 Nutley Street, Suite 106   Fairfax, VA 22031   USA   EMail: turners@ieca.com   Michael Peck   EMail: mpeck@alumni.virginia.eduZieglar, et al.               Informational                    [Page 16]