Suite B Profile of Certificate Management over CMS
draft-turner-suiteb-cmc-03
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6403.
|
|
|---|---|---|---|
| Authors | Michael Peck , Lydia Zieglar , Sean Turner | ||
| Last updated | 2018-08-01 (Latest revision 2010-06-30) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6403 (Historic) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Tim Polk | ||
| IESG note | ** No value found for 'doc.notedoc.note' ** | ||
| Send notices to | mpeck@alumni.virginia.edu |
draft-turner-suiteb-cmc-03
Network Working Group Lydia Zieglar, NSA
Internet-Draft Sean Turner, IECA
Intended Status: Informational Mike Peck
Expires: December 30, 2010 June 30, 2010
Suite B Profile of Certificate Management over CMS
draft-turner-suiteb-cmc-03.txt
Abstract
The United States Government has published guidelines for "NSA Suite
B Cryptography", which defines cryptographic algorithm policy for
national security applications. This document specifies a profile of
the Certificate Management over CMS (CMC) protocol for managing Suite
B X.509 public key certificates. This profile is a refinement of RFC
5272, RFC 5273, and RFC 5274.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 30, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zieglar, et al. Expires December 30, 2010 [Page 1]
Internet-Draft Suite B CMC Profile May 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 [CMCbis], 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 [CMCbis]
apply, except where overridden by this profile.
Zieglar, et al. Expires December 30, 2010 [Page 2]
Internet-Draft Suite B CMC Profile May 2010
This profile was developed with the scenarios described in Appendix A
in mind. However, use of this profile is not limited to just those
scenarios.
The term "client" in this profile typically refers to an end-entity.
However, it may instead refer to a third party acting on the
end-entity's behalf. The client may or may not be the entity that
actually generates the key pair, but it does perform the CMC protocol
interactions with the RA and/or CA. For example, the client may be a
token management system that communicates with a cryptographic token
through an out-of-band secure protocol.
This profile uses the term "rekey" in the same manner as does CMC
(defined in section 2 of [RFC5272]). The profile makes no specific
statements about the ability to do "renewal" operations, however the
statements applicable to rekey should be applied to renewal as well.
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 certificate 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
[RFC5008]. 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 certificate requests,
and MUST be id-sha384 for P-384 certificate 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
Zieglar, et al. Expires December 30, 2010 [Page 3]
Internet-Draft Suite B CMC Profile May 2010
certificate 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 CRMF request as described in
Sections 4.1 and 4.2.
o reqSequence MUST be present. It MUST include at least one tcr
(see Section 4.1) or crm (see Section 4.2) TaggedRequest.
Support for the orm choice is OPTIONAL.
If the Full PKI Request contains a P-256 public key certificate
request, then the SignedData encapsulating the Full PKI Request MUST
be generated using either SHA-256 and ECDSA with P-256 or using SHA-
384 and ECDSA with P-384. If the Full PKI Request contains a P-384
public key certificate request, then the SignedData MUST be generated
using SHA-384 and ECDSA with 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, a Full
PKI Request includes one or more certificate 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. A Full PKI Request
MAY be signed using a key pair intended for use in a key
establishment certificate when necessary because there is no existing
signature certificate and there is no signature certificate request
included. However, servers are not required to allow this behavior.
4.1. Tagged Certificate 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:
o subjectPublicKeyInfo MUST be set as defined in 4.4 of
[RFC5759];
o attributes:
o The ExtensionReq attribute MUST be included and contain:
Zieglar, et al. Expires December 30, 2010 [Page 4]
Internet-Draft Suite B CMC Profile May 2010
o The Key Usage extension MUST be included and it MUST be
set as defined in [RFC5759].
o For rekey requests, the SubjectAltName extension MUST be
included and set equal to the SubjectAltName of the
certificate which is being used to sign the SignedData
encapsulating the request (i.e., not the certificate
being re-keyed) if its Subject field of the certificate
being used to generate the signature is NULL.
o Other extension requests MAY be included as desired.
o The ChangeSubjectName attribute, as defined in [CMCbis],
MUST be included if the Full PKI Request encapsulating this
Tagged Certificate 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 certificate
request.
o 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 certificate 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 certificate
requests and MUST be id-sha384 for P-384 certificate
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].
o signatureAlgorithm MUST be ecdsa-with-sha256 for P-256
certificate requests, and MUST be ecdsa-with-sha384 for P-384
certificate requests;
o signature MUST be generated using the private key
corresponding to the public key in the
CertificationRequestInfo, for both signature and key
establishment certificate 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:
Zieglar, et al. Expires December 30, 2010 [Page 5]
Internet-Draft Suite B CMC Profile May 2010
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.
The POPOSigningKey poposkInput field MUST be omitted. The
POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha256 for
P-256 certificate requests, and MUST be ecdsa-with-sha384 for
P-384 certificate 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 in paragraph 4.3 of [RFC5759];
o publicKey MUST be set as defined in 4.4 of [RFC5759];
o extensions:
o The Key Usage extension MUST be included and it MUST be set as
defined in [RFC5759].
o For rekey requests, the SubjectAltName extension MUST be
included and set equal to the SubjectAltName of the
certificate which is being used to sign the SignedData
encapsulating the request (i.e., not the certificate being re-
keyed) if the Subject field of the certificate being used to
generate the signature is NULL.
o Other extension requests MAY be included as desired.
o controls:
o The ChangeSubjectName attribute, as defined in [CMCbis], MUST
be included if the Full PKI Request encapsulating this Tagged
Certificate 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 certificate request.
o 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 certificate request is NULL or otherwise
does not uniquely identify the end-entity. In POP Link Witness
Version 2 attribute, keyGenAlgorithm MUST be id-sha256 or id-
sha384 for P-256 certificate requests and MUST be id-sha384
for P-384 certificate requests; macAlgorithm MUST be HMAC-
Zieglar, et al. Expires December 30, 2010 [Page 6]
Internet-Draft Suite B CMC Profile May 2010
SHA256 when keyGenAlgorithm is id-sha256 and MUST be
HMAC-SHA384 when keyGenAlgorithm is id-sha384.
5. RA Requirements
This section addresses the optional case where one or more RAs act as
intermediaries between the client and CA as described in Section 7 of
[RFC5272]. In this section, the term "client" refers to the entity
from which the RA received the PKI Request. This section is only
applicable to RAs.
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 CA 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 [CCC] processing.
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
[RFC5008]. 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 either with
an Extended Key Usage (EKU) and/or with the CCC certificate extension
[CCC]. Certificates may also be authorized through local
configuration. Authorized Certificates SHOULD include the id-kp-
cmcRA Extended Key Usage (EKU) from [CMCbis]. Authorized
certificates MAY also include the CCC certificate extension [CCC] or
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
Zieglar, et al. Expires December 30, 2010 [Page 7]
Internet-Draft Suite B CMC Profile May 2010
content type. CCC SHOULD be included if constraints are to be placed
on the content types generated.
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 with P-256 or SHA-384 and ECDSA with 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 with 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 with 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 with P-256 or SHA-384 and ECDSA with P-384.
5.3. RA-Generated Errors
RA certificates authorized with the CCC certificate extension [CCC]
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 certificate 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, RAs MUST NOT
perform Cryptographic Message Syntax (CMS) Content Constraints (CCC)
certificate extension [CCC] processing.
If the client-generated PKI Request includes a ChangeSubjectName
attribute either in the CertRequest controls field for a CRMF request
Zieglar, et al. Expires December 30, 2010 [Page 8]
Internet-Draft Suite B CMC Profile May 2010
or in the tcr attributes field for a PKCS#10 request, then the CA
MUST ensure that name change is authorized. The mechanism for
ensuring that the name change is authorized is out-of-scope. If the
CA performs this check, and the name change is not authorized, then
the CA MUST reject the PKI Request. The CA SHOULD return a
CMCStatusInfoV2 control with CMCStatus of failed.
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
[RFC5008].
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 [RFC5008]. 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 Extended Key Usage
(EKU) and/or with the Cryptographic Message Syntax (CMS) Content
Constraints (CCC) certificate extension [CCC]. Certificates may also
be authorized through local configuration. Authorized Certificates
SHOULD include the id-kp-cmcCA EKU from [CMCbis]. Authorized
certificates MAY also include the CCC certificate extension [CCC] or
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
Zieglar, et al. Expires December 30, 2010 [Page 9]
Internet-Draft Suite B CMC Profile May 2010
content type. CCC SHOULD be included if constraints are to be placed
on the content types generated.
The signature on the SignedData MUST be generated using either ECDSA
P-256 with SHA-256 or ECDSA P-384 with SHA-384. If the Full PKI
Response is a successful response to a P-256 public key certificate
request, then the SignedData MUST be generated using either SHA-256
and ECDSA with P-256 or SHA-384 and ECDSA with P-384. If the Full
PKI Response is a successful response to a P-384 public key
certificate request, then the SignedData MUST be generated using SHA-
384 and ECDSA with P-384. If the Full PKI Response is a successful
response to certificate requests on both the P-256 and P-356 curves,
then the SignedData MUST be generated using SHA-384 and ECDSA with 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 with P-256 or SHA-384 and ECDSA with P-384. If the Full PKI
Response is an unsuccessful response to certificate requests on both
the P-256 and P-356 curves, then the SignedData MUST be generated
using SHA-384 and ECDSA with 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 with P-256 or SHA-384 and ECDSA with P-384.
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 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 later
case, each layer of PKI Response MUST still contain an authorized,
valid signature signed by an entity with a valid certificate that
verifies back to an acceptable trust anchor. The authorized RA
certificate MUST include the id-kp-cmcRA EKU and/or include a CCC
extension that includes the object identifier for the PKIResponse
Zieglar, et al. Expires December 30, 2010 [Page 10]
Internet-Draft Suite B CMC Profile May 2010
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 certificate request back to the server or
whether 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 certificate requests and at least 192 bits of
strength for P-384 certificate requests.
9. Security Considerations
Protocol security considerations are found in [RFC2986], [RFC4211],
[RFC5008], [RFC5272], [RFC5273], [RFC5274], [RFC5759], and [CMCbis].
When CCC is used to authorize RA and CA certificates, then the
security considerations in [CCC] also apply. Algorithm security
considerations are found in [RFC5008].
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. Expires December 30, 2010 [Page 11]
Internet-Draft Suite B CMC Profile May 2010
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 protect against substitution attacks.
The Certificate Policy for a particular environment will specify
whether expired certificates can be used to sign certificate
requests.
10. IANA Considerations
None: All identifiers are already registered. Please remove this
section prior to publication as an RFC.
11. References
11.1. Normative References
[CCC] Housley, R., Wallace, C., and S. Ashmore, "Cryptographic
Message Syntax (CMS) Content Constraints X.509
Certificate Extension", draft-housley-cms-content-
constraints-extn-06, work-in-progress.
[CMCbis] Schaad, J., "Certificate Management over CMS (CMC)
Updates", draft-ietf-pkix-rfc5272-bis-00.txt, work-in-
progress.
[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", RFC 2119, BCP 14, March 1997.
[RFC2986] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5", RFC 2986, November 2000.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC4211] J. Schaad, "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[RFC4231] M. Nystrom, "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC
4231, December 2005.
Zieglar, et al. Expires December 30, 2010 [Page 12]
Internet-Draft Suite B CMC Profile May 2010
[RFC5008] Solinas, J. and R. Housley, "Suite B in
Secure/Multipurpose Internet Mail Extensions (S/MIME)",
RFC 5008, September 2007.
[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.
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages
over CMS (CMC): Compliance Requirements", RFC 5274, June
2008.
[RFC5754] S. Turner, "Using SHA2 Algorithms with CMS", RFC 5754,
January 2010.
[RFC5759] Solinas, J., and L. Zieglar, "Suite B Certificate and
Certificate Revocation List (CRL) Profile", RFC5759,
January 2010.
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.
Appendix 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.
Zieglar, et al. Expires December 30, 2010 [Page 13]
Internet-Draft Suite B CMC Profile May 2010
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
certificate 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 DN Linking mechanism as described in [RFC5272]
section 6.3.2. The Subject in the enclosed PKCS #10 or CRMF
certificate request does not necessarily match the issued
certificate, as it may just be used to help identify the request (and
corresponding shared secret) to the CA.
A.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 in Section 5.2, forwarding the new request on to the CA.
The Subject in the PKCS #10 or CRMF certification request is not
required to match the issued certificate, it may just be used 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 may require initial enrollment to
Zieglar, et al. Expires December 30, 2010 [Page 14]
Internet-Draft Suite B CMC Profile May 2010
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 in section A.1 may
be used.
Authors' Addresses
Michael Peck
National Security Agency
Email: mpeck@alumni.virginia.edu
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
Zieglar, et al. Expires December 30, 2010 [Page 15]