PKIX Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Expires: June 4, 2005 M. Myers
TraceRoute Security, Inc.
X. Liu
Cisco
J. Weinstein
December 2004
CMC Complience Document
draft-ietf-pkix-cmc-compl-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 June 4, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document provides a set of compliance statements about the CMC
(Certificate Management over CMS) enrollment protocol. The ASN.1
Schaad, et al. Expires June 4, 2005 [Page 1]
Internet-Draft CMC Complience Document December 2004
structures and the transport mechanisms for the CMC enrollment
protocol are covered in other documents. This document provides the
information needed to make a compliant version of CMC
Schaad, et al. Expires June 4, 2005 [Page 2]
Internet-Draft CMC Complience Document December 2004
1. Overview
The CMC (Certificate Management over CMS) protocol is designed in
terms of a client/server relationship. In the simplest case the
client is the requestor of the certificate (i.e. the End Entity or
EE) and the server is the issuer of the certificate (i.e. the CA).
The introduction of an RA (registration authority) into the set of
agents complicates the picture only slightly. The RA becomes the
server with respect to the certificate requestor, and it becomes the
client with respect to the certificate issuer. Any number of RAs can
be inserted into the picture in this manner.
The RAs may serve specialized purposes that are not currently covered
by this document. One such purpose would be a Key Escrow agent. As
such all certificate requests for encryption keys would be directed
through this RA and it would take appropriate action to do the key
archival. Key recovery requests could be defined in the CMC
methodology allowing for the Key Escrow agent to perform that
operation acting as the final server in the chain of agents.
If there are multiple RAs in the system, it is considered normal that
not all RAs will see all certificate requests. The routing between
the RAs may be dependent on the content of the certificate requests
involved
This document is divided into six sections, each section specifying
the requirements that are specific to a class of agents in the CMC
model. These are 1) All agents, 2) all servers, 3) all clients, 4)
all End Entities, 5) all Registration Entities, 6) all certificate
authorities.
Schaad, et al. Expires June 4, 2005 [Page 3]
Internet-Draft CMC Complience Document December 2004
2. Terminology
There are several different terms, abbreviations and acronyms used in
this document that we define here for convenience and consistency of
usage:
"End-Entity" (EE) refers to the entity that owns a key pair and
for whom a certificate is issued.
"RA" or "LRA" refers to a (Local) Registration Authority. A
registration authority acts as an intermediary between an
End-Entity and a Certification Authority. Multiple RAs can exist
between the End-Entity and the Certification Authority.
"CA" refers to a Certification Authority. A Certification
Authority is the entity that performs the actual issuance of a
certificate.
"Client" refers to an entity that creates a PKI request. In this
document both RAs and End-Entities can be clients.
"Server" refers to the entities that process PKI requests and
create PKI responses. CAs and RAs can be servers in this
document. Other documents could define entities such as key
escrow agents that could also be serves
"PKCS#10" refers the Public Key Cryptography Standard #10. This
is one of a set of standards defined by RSA Laboratories in the
1980s. PKCS#10 defines a Certificate Request Message syntax.
"CRMF" refers to the Certificate Request Message Format RFC
[CRMF]. We are using certificate request message format defined
in this document as part of our management protocol.
"CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This
document provides for basic cryptographic services including
encryption and signing with and without key management.
"POP" is an acronym for "Proof of Possession". POP refers to a
value that can be used to prove that the private key corresponding
to a public key is in the possession and can be used by an
end-entity. A discussion on POP can be found in appendix C of
[CRMF].
"Transport wrapper" refers to the outermost CMS wrapping layer.
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 [RFC 2119].
Schaad, et al. Expires June 4, 2005 [Page 4]
Internet-Draft CMC Complience Document December 2004
3. Requirements for All Entities
All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be
adhered to unless specifically stated otherwise in this document.
The extendedFailInfo field SHOULD NOT be populated in the
CMCStatusInfoExt object; the failInfo field SHOULD be used to relay
this information. If the extendedFailInfo field is used, it is
suggested that an additional CMCStatusInfoExt item exist for the same
body part with a failInfo field.
All entities MUST process the following control attributes:
id-cmc-statusInfoExt, id-cmc-dataReturn, id-cmc-transactionId,
id-cmc-senderNonce, id-cmc-recipientNonce, id-cmc-queryPending,
id-cmc-identification, id-cmc-identityProof, id-cmc-idPOPLinkRandom,
id-cmc-idPOPLinkWitness, id-cmc-confirmCertAcceptance.
All entities SHOULD be able to process the following control
attributes: id-cmc-statusInfo, id-cmc-revokeRequest, id-cmc-regInfo,
id-cmc-responseInfo.
Implementation of the id-cmc-getCert, id-cmc-getCRL,
id-cmc-trustRoots, id-cmc-authData and id-cmc-publishCertificate
controls is optional. Strong consideration should be given to
implementing the id-cmc-authData and id-cmc-trustRoots controls as
this gives a simple method for distributing trust anchors into
clients without user intervention.
All entities MUST implement the HTTP transport mechanism as defined
in [CMC-TRANS]. Other transport mechanisms MAY be implemented.
3.1 Cryptographic Algorithm Requirments
All entities MUST verify DSA and RSA-SHA1 signatures as defined in
[CMS-ALG]. Other signature algorithms MAY be verified. It is
strongly suggested that RSA-PSS as defined in [CMS-RSA-PSS] also be
verified. It is strongly suggested that SHA-256 using RSA and
RSA-PSS also be verified. (Details are found in [RSA-256].)
All entities MUST generate either DSA or RSA-SHA1 signatures as
defined in [CMS-ALG]. Other signatures algorithms MAY be used for
generation.
If an entity implements a data encryption algorithm, AES as defined
in [CMS-AES] MUST be implemented. Other algorithms MAY be
implemented.
If an entity implements a key transport algorithm, RSA as defined in
Schaad, et al. Expires June 4, 2005 [Page 5]
Internet-Draft CMC Complience Document December 2004
[CMS-ALG] MUST be implemented. RSA-OAEP as defined in [CMS-RSA-OAEP]
SHOULD be implemented. Other key transport algorithms MAY be
implemented.
If an entity implements a key agreement algorithm, Diffie-Hellman as
defined in [CMS-DH] MUST be implemented.
3.2 CRMF Feature Requirments
The following additional restrictions are placed on CRMF features:
The registration control tokens id-regCtrl-regToken and
id-regCtrl-authToken MUST NOT be used. No specific CMC feature is
used to replace these items, but generally the CMC controls
identification and identityProof will perform the same service and
are more specifically defined.
The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be
supported. An alternative method is under development to provide
this functionality.
The behavior of id-regCtrl-oldCertID is not presently used. It is
replaced by issuing the new certificate and using the
id-cmc-publishCert to remove the old certificate from publication.
This operation would not normally be accompanied by an immediate
revocation of the old certificate, however that can be accomplished
by the id-cmc-revokeRequest control.
The id-regCtrl-protocolEncrKey is not used.
3.3 Requirements for Clients
All compliant client applications MUST support full enrollment
responses. (This allows for error handling not otherwise supported.)
Schaad, et al. Expires June 4, 2005 [Page 6]
Internet-Draft CMC Complience Document December 2004
4. Requirements for Servers
All compliant server applications MUST support CRMF certificate
requests. All compliant server applications SHOULD support PKCS10
certificate requests both in the simple and full message formats.
Schaad, et al. Expires June 4, 2005 [Page 7]
Internet-Draft CMC Complience Document December 2004
5. Requirements for EEs
All EE applications MUST support either the simple or full enrollment
requests/response pair. All client application SHOULD support the
full enrollment request/response pair.
When generating full enrollment requests, the CRMF request format is
preferred over the PKCS10 request format.
If an entity implements Diffie-Hellman, it MUST implement either the
DH-POP Proof-of-Possession as defined in [DH-POP] Section 4 or the
challenge-response POP controls id-cmc-encryptedPOP and
id-cmc-decryptedPOP.
Schaad, et al. Expires June 4, 2005 [Page 8]
Internet-Draft CMC Complience Document December 2004
6. Requirements for RAs
RAs MUST implement the following controls: id-cmc-modCertTemplate,
id-cmc-batchRequests, id-cmc-batchResponses. RAs SHOULD implement
the id-cmc-addExtensions control.
RAs SHOULD be able to do delegated POP. RAs implementing this
feature MUST implement the id-cmc-lraPOPWitness control.
RAs MUST generate full enrollment requests.
All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as
covered in section 3.8 of [CMC-STRUCT]
Schaad, et al. Expires June 4, 2005 [Page 9]
Internet-Draft CMC Complience Document December 2004
7. Requirements for CAs
CAs MUST accept PKCS10 certificate requests. CAs MUST accept CRMF
certificate requests.
CAs MUST implement the Simple Enrollment protocol. CAs MUST
implement the Full Enrollment protocol.
CAs MUST implement the following additional control attributes:
identification, identityProof, dataReturn, addExtensions,
transactionID, senderNonce, recipientNonce, lraPOPWitness,
revokeRequest. All CAs designed to work in an environment where RAs
are permitted MUST implement the id-cmc-modCertTemplate,
id-cmc-batchRequests and id-cmc-BatchResponses controls. Such CAs
SHOULD also implement the id-cmc-addExtensions control.
Implementation of such support is strongly suggested as this permits
the delegation of substantial administrative interaction onto an RA
rather than at the CA.
CAs MUST perform at least minimal checks on all public keys before
issuing a certificate. At a minimum a check for syntax would occur
with the POP operation. Additionally CAs SHOULD perform simple
checks for known bad keys such as small subgroups for DSA and DH keys
[SMALL-SUBGROUPS] or known bad exponents for RSA keys (i.e. 3).
CAs MUST enforce POP checking before issuing any certificate. CAs
MAY delegate the POP operation to an RA for those cases where 1) a
challenge/response message pair must be used, 2) an RA performs
escrow of a key and checks for POP in that manner or 3) an unusual
algorithm is used and that validation is done at the RA.
CAs SHOULD implement both the DH-POP Proof-of-Possession as defined
in [DH-POP] Section 4 and the challenge-response POP controls
id-cmc-encryptedPOP and id-cmc-decryptedPOP.
Schaad, et al. Expires June 4, 2005 [Page 10]
Internet-Draft CMC Complience Document December 2004
8. Acknowledgements
The authors would like to thank Brian LaMacchia for his work in
developing and writing up many of the concepts presented in this
document. The authors would also like to thank Alex Deacon and Barb
Fox for their contributions.
Schaad, et al. Expires June 4, 2005 [Page 11]
Internet-Draft CMC Complience Document December 2004
9. References
9.1 Nomative References
[CMC-STRUCT]
Schaad, J., Myers, M., Liu, X. and J. Weinstein,
"Certificate Management Messages over CMS", Work in
Progress , December 2004.
[CMC-TRANS]
Schaad, J., Myers, M., Liu, X. and J. Weinstein, "CMC
Transport", Work In Progress , December 2004.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, July 2003.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[CRMF] Schaad, J., "Internet X.509 Certificate Request M2essage
Format", Work In Progress , December 1999.
[CMS-RSA-OAEP]
Housley, R., "Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax (CMS)",
RFC 3560, July 2003.
[CMS-RSA-PSS]
Schaad, J., "Use of the RSA PSS Signature Algorithm in
CMS", Work In Progress , December 2003.
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
Proof-of-Possession Algorithms", RFC 2875, June 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RSA-256] Schaad, J., "Additional Algorithms and Identifiers for RSA
Cryptography for use in the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", Work in Progress , July 2004.
Schaad, et al. Expires June 4, 2005 [Page 12]
Internet-Draft CMC Complience Document December 2004
9.2 Informational References
[SMALL-SUB-GROP]
Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.
Authors' Addresses
Jim Schaad
Soaring Hawk Consulting
PO Box 675
Gold Bar, WA 98251
Phone: (425) 785-1031
Email: jimsch@exmsft.com
Michael Myers
TraceRoute Security, Inc.
Email: myers@coastside.inc
Xiaoyi Liu
Cisco
170 West Tasman Drive
San Jose, CA 95134
Phone: (480) 526-7430
Email: xliu@cisco.com
Jeff Weinstein
Email: jsw@meer.net
Schaad, et al. Expires June 4, 2005 [Page 13]
Internet-Draft CMC Complience Document December 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schaad, et al. Expires June 4, 2005 [Page 14]