< draft-turner-suiteb-cmc-02.txt   draft-turner-suiteb-cmc-03.txt >
Network Working Group Lydia Zieglar, NSA Network Working Group Lydia Zieglar, NSA
Internet-Draft Mike Peck, NSA Internet-Draft Sean Turner, IECA
Intended Status: Informational Sean Turner, IECA Intended Status: Informational Mike Peck
Expires: December 7, 2010 June 7, 2010 Expires: December 30, 2010 June 30, 2010
Suite B Profile of Certificate Management over CMS Suite B Profile of Certificate Management over CMS
draft-turner-suiteb-cmc-02.txt draft-turner-suiteb-cmc-03.txt
Abstract Abstract
The United States Government has published guidelines for "NSA Suite The United States Government has published guidelines for "NSA Suite
B Cryptography", which defines cryptographic algorithm policy for B Cryptography", which defines cryptographic algorithm policy for
national security applications. This document specifies a profile of national security applications. This document specifies a profile of
the Certificate Management over CMS (CMC) protocol for managing Suite the Certificate Management over CMS (CMC) protocol for managing Suite
B X.509 public key certificates. This profile is a refinement of RFC B X.509 public key certificates. This profile is a refinement of RFC
5272, RFC 5273, and RFC 5274. 5272, RFC 5273, and RFC 5274.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 7, 2010. This Internet-Draft will expire on December 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 26 skipping to change at page 4, line 26
be generated using either SHA-256 and ECDSA with P-256 or using SHA- 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 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 public key certificate request, then the SignedData MUST be generated
using SHA-384 and ECDSA with P-384. using SHA-384 and ECDSA with P-384.
A Full PKI Request MUST be signed using the private key that A Full PKI Request MUST be signed using the private key that
corresponds to the public key of an existing signature certificate corresponds to the public key of an existing signature certificate
unless an appropriate signature certificate does not yet exist, such unless an appropriate signature certificate does not yet exist, such
as during initial enrollment. as during initial enrollment.
If a Full PKI Request includes one or more certificate requests and If an appropriate signature certificate does not yet exist, a Full
is authenticated using a shared secret (because no appropriate 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 certificate exists yet to authenticate the request), the Full PKI
Request MUST be signed using the private key corresponding to the Request MUST be signed using the private key corresponding to the
public key of one of the requested certificates. A Full PKI Request 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 MAY be signed using a key pair intended for use in a key
establishment certificate when necessary because there is no existing establishment certificate when necessary because there is no existing
signature certificate and there is no signature certificate request signature certificate and there is no signature certificate request
included. However, servers are not required to allow this behavior. included. However, servers are not required to allow this behavior.
4.1. Tagged Certificate Request 4.1. Tagged Certificate Request
skipping to change at page 8, line 38 skipping to change at page 8, line 40
6.1. CA Processing of PKI Requests 6.1. CA Processing of PKI Requests
CAs conforming to this document MUST ensure that only the permitted CAs conforming to this document MUST ensure that only the permitted
signature, hash, and MAC algorithms described throughout this profile signature, hash, and MAC algorithms described throughout this profile
are used in requests; if they are not, the CA MUST reject those are used in requests; if they are not, the CA MUST reject those
requests. The CA SHOULD return a CMCStatusInfoV2 control with requests. The CA SHOULD return a CMCStatusInfoV2 control with
CMCStatus of failed and a CMCFailInfo with the value of badAlg CMCStatus of failed and a CMCFailInfo with the value of badAlg
[RFC5272]. [RFC5272].
For requests involving an RA, the CA MUST verify the RA's For requests involving an RA, the CA MUST verify the RA's
authorization. Authorized RAs MAY, and end-entities MUST NOT, authorization. The following certificate fields MUST NOT be
include the Modify Certification Request control. The following modifiable using the Modify Certification Request control: publicKey
certificate fields MUST NOT be modifiable using the Modify and the key usage extension. The request MUST be rejected if an
Certification Request control: publicKey and the key usage extension. attempt to modify those certificate request fields is present. The
The request MUST be rejected if an attempt to modify those CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed
certificate request fields is present. The CA SHOULD return a and a CMCFailInfo with a value of badRequest.
CMCStatusInfoV2 control with CMCStatus of failed and a CMCFailInfo
with a value of badRequest.
When processing end-entity generated SignedData objects, RAs MUST NOT When processing end-entity generated SignedData objects, RAs MUST NOT
perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) perform Cryptographic Message Syntax (CMS) Content Constraints (CCC)
certificate extension [CCC] processing. certificate extension [CCC] processing.
If the client-generated PKI Request includes a ChangeSubjectName If the client-generated PKI Request includes a ChangeSubjectName
attribute either in the CertRequest controls field for a CRMF request attribute either in the CertRequest controls field for a CRMF request
or in the tcr attributes field for a PKCS#10 request, then the CA or in the tcr attributes field for a PKCS#10 request, then the CA
MUST ensure that name change is authorized. The mechanism for MUST ensure that name change is authorized. The mechanism for
ensuring that the name change is authorized is out-of-scope. If the ensuring that the name change is authorized is out-of-scope. If the
skipping to change at page 12, line 24 skipping to change at page 12, line 27
None: All identifiers are already registered. Please remove this None: All identifiers are already registered. Please remove this
section prior to publication as an RFC. section prior to publication as an RFC.
11. References 11. References
11.1. Normative References 11.1. Normative References
[CCC] Housley, R., Wallace, C., and S. Ashmore, "Cryptographic [CCC] Housley, R., Wallace, C., and S. Ashmore, "Cryptographic
Message Syntax (CMS) Content Constraints X.509 Message Syntax (CMS) Content Constraints X.509
Certificate Extension", draft-housley-cms-content- Certificate Extension", draft-housley-cms-content-
constraints-extn-05, work-in-progress. constraints-extn-06, work-in-progress.
[CMCbis] Schaad, J., "Certificate Management over CMS (CMC) [CMCbis] Schaad, J., "Certificate Management over CMS (CMC)
Updates", draft-ietf-pkix-rfc5272-bis-00.txt, work-in- Updates", draft-ietf-pkix-rfc5272-bis-00.txt, work-in-
progress. progress.
[DSS] National Institute of Standards and Technology (NIST), [DSS] National Institute of Standards and Technology (NIST),
FIPS 186-3: Digital Signature Standard (DSS), June 2009. FIPS 186-3: Digital Signature Standard (DSS), June 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
skipping to change at page 14, line 5 skipping to change at page 13, line 37
[SP80057] National Institute of Standards and Technology (NIST), [SP80057] National Institute of Standards and Technology (NIST),
Special Publication 800-57 Part 1: Recommendation for Key Special Publication 800-57 Part 1: Recommendation for Key
Management, March 2007. Management, March 2007.
[SP80090] National Institute of Standards and Technology (NIST), [SP80090] National Institute of Standards and Technology (NIST),
Special Publication 800-90: Recommendation for Random Special Publication 800-90: Recommendation for Random
Number Generation Using Deterministic Random Number Bits Number Generation Using Deterministic Random Number Bits
Generators (Revised), March 2007. Generators (Revised), March 2007.
Authors' Addresses
Michael Peck
National Security Agency
9800 Savage Road Ste 6704
Ft. Meade, MD 20755-6704
USA
Email: mpeck@restarea.ncsc.mil
Lydia Zieglar
National Security Agency
9800 Savage Road Ste 6704
Ft. Meade, MD 20755-6704
USA
Email: llziegl@tycho.ncsc.mil
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners@ieca.com
Appendix A. Scenarios Appendix A. Scenarios
This section illustrates several potential certificate enrollment and This section illustrates several potential certificate enrollment and
rekey scenarios supported by this profile. This section does not rekey scenarios supported by this profile. This section does not
intend to place any limits or restrictions on the use of CMC. intend to place any limits or restrictions on the use of CMC.
A.1. Initial Enrollment A.1. Initial Enrollment
This section describes three scenarios for authenticating initial This section describes three scenarios for authenticating initial
enrollment requests: enrollment requests:
skipping to change at line 725 skipping to change at page 15, line 23
Full PKI Request will be signed by the current private key Full PKI Request will be signed by the current private key
corresponding to the current signature certificate. corresponding to the current signature certificate.
A.2.2. Rekey of Key Establishment Certificates A.2.2. Rekey of Key Establishment Certificates
When a key establishment certificate is rekeyed, the Full PKI Request When a key establishment certificate is rekeyed, the Full PKI Request
will generally be signed by the current private key corresponding to will generally be signed by the current private key corresponding to
the current signature certificate. If there is no current signature the current signature certificate. If there is no current signature
certificate, one of the initial enrollment options in section A.1 may certificate, one of the initial enrollment options in section A.1 may
be used. 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
 End of changes. 8 change blocks. 
42 lines changed or deleted 15 lines changed or added

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