[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 rfc5274                                     
PKIX Working Group                                             J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Expires: September 3, 2006                                      M. Myers
                                               TraceRoute Security, Inc.
                                                           March 2, 2006

                        CMC Complience Document

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document provides a set of compliance statements about the CMC
   (Certificate Management over CMS) enrollment protocol.  The ASN.1
   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 & Myers          Expires September 3, 2006               [Page 1]

Internet-Draft           CMC Complience Document              March 2006

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

   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

Schaad & Myers          Expires September 3, 2006               [Page 2]

Internet-Draft           CMC Complience Document              March 2006

2.  Terminology

   There are several different terms, abbreviations and acronyms used in
   this document that we define here for convenience and consistency of

      "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

      "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",
   document are to be interpreted as described in [RFC 2119].

Schaad & Myers          Expires September 3, 2006               [Page 3]

Internet-Draft           CMC Complience Document              March 2006

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,

   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

   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

   If an entity implements a data encryption algorithm, AES as defined
   in [CMS-AES] MUST be implemented.  Other algorithms MAY be

   If an entity implements a key transport algorithm, RSA as defined in

Schaad & Myers          Expires September 3, 2006               [Page 4]

Internet-Draft           CMC Complience Document              March 2006

   [CMS-ALG] MUST be implemented.  RSA-OAEP as defined in [CMS-RSA-OAEP]
   SHOULD be implemented.  Other key transport algorithms MAY be

   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 & Myers          Expires September 3, 2006               [Page 5]

Internet-Draft           CMC Complience Document              March 2006

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 & Myers          Expires September 3, 2006               [Page 6]

Internet-Draft           CMC Complience Document              March 2006

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-

Schaad & Myers          Expires September 3, 2006               [Page 7]

Internet-Draft           CMC Complience Document              March 2006

6.  Requirements for RAs

   RAs MUST implement the following controls: id-cmc-modCertTemplate,
   id-cmc-batchRequests, id-cmc-batchResponses, and id-cmc-
   controlProcessed.  RAs SHOULD implement the id-cmc-addExtensions

   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 & Myers          Expires September 3, 2006               [Page 8]

Internet-Draft           CMC Complience Document              March 2006

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: id-
   cmc-revokeRequest.  All CAs designed to work in an environment where
   RAs are permitted MUST implement the id-cmc-lraPOPWitness, id-cmc-
   modCertTemplate, id-cmc-batchRequests, id-cmc-BatchResponses
   controls, and id-cmc-controlProcessed.  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

   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 & Myers          Expires September 3, 2006               [Page 9]

Internet-Draft           CMC Complience Document              March 2006

8.  Security Considerations

   This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to
   this document.  The security sections of those two documents are
   included by reference.

   Knowledge of how an entity is expected to operate is vital in
   determining which sections of requirements are appliciable to that
   entity.  Care needs to be taken in determining which sections apply
   and fulling implmenting the necessary code.

   Cryptographic algorithms have and will be broken or weakened.
   Implementers and users need to check that the cryptographic
   algorithms listed in this document make sense from a security level.
   The IETF from time to time may issue documents dealing with the
   current state of the art.  Two examples of such documents are [SMALL-

Schaad & Myers          Expires September 3, 2006              [Page 10]

Internet-Draft           CMC Complience Document              March 2006

9.  IANA Considerations

   There are no IANA considerations in this document.

Schaad & Myers          Expires September 3, 2006              [Page 11]

Internet-Draft           CMC Complience Document              March 2006

10.  Acknowledgements

   The authors and the Working Group are greatful for the participation
   of Xiaoui Lui and Jeff Weinstein in helping to author the original
   versions of this document.

   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 & Myers          Expires September 3, 2006              [Page 12]

Internet-Draft           CMC Complience Document              March 2006

11.  References

11.1.  Nomative References

              Schaad, J., Myers, M., Liu, X., and J. Weinstein,
              "Certificate Management Messages over CMS", Work in
              Progress , December 2004.

              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", RFC 4211, September 2005.

              Housley, R., "Use of the RSAES-OAEP Key Transport
              Algorithm in the Cryptographic Message Syntax (CMS)",
              RFC 3560, July 2003.

              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 & Myers          Expires September 3, 2006              [Page 13]

Internet-Draft           CMC Complience Document              March 2006

11.2.  Informational References

              Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
              Attacks on the Diffie-Hellman Key Agreement Method for
              S/MIME", RFC 2785, March 2000.

              Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols", RFC 4270, November 2005.

Schaad & Myers          Expires September 3, 2006              [Page 14]

Internet-Draft           CMC Complience Document              March 2006

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

Schaad & Myers          Expires September 3, 2006              [Page 15]

Internet-Draft           CMC Complience Document              March 2006

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Schaad & Myers          Expires September 3, 2006              [Page 16]