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

Versions: 00 01 02 03 04 05 rfc5274                                     
PKIX Working Group                                            M. Myers
Internet Draft                                                VeriSign
Document: draft-ietf-pkix-cmc-compl-00.txt                      X. Liu
February 2001                                                    Cisco
Expires: July 2001                                           J. Schaad
                                                Soaring Hawk Consulting
                                                           J. Weinstein

                        CMC Compliance Document

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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.

   Comments or suggestions for improvement may be made on the "ietf-
   pkix" mailing list, or directly to the author.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document provides a set of compliance statements about the CMC
   enrollment protocol.  The documents [CMC-STRUCT] and [CMC-TRANS]
   provide the definitions of the structure and transport protocols
   defined for CMC.  This document provides the information needed to
   make a compliant version of CMC.

   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].

1. Overview

   A set of structures and controls for providing an enrollment
   protocol has been provided in [CMC-STRUCT].  The design of this
   protocol was such that additional items could be added later as was
   designed.  A set of transport mechanisms for CMC messages as been
   defined in [CMC-TRANS], again additional mechanisms may be defined


   at a later date.  This document covers the compliance issues that
   are needed to implement a compliant CMC enrollment protocol.


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.
   "LRA" or "RA" 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.
   "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.
   "Transport wrapper" refers to the outermost CMS wrapping layer.

3. Requirements for All Entities

   [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered
   to unless specifically stated otherwise in this document.

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

   All entities MUST verify DSA and RSA-SHA1 signatures as defined in
   [CMS-ALG].  Other signature algorithms MAY be verified.

   All entities MUST generate either DSA or RSA-SHA1 signatures as
   defined in [CMS-ALG].  Other signatures algorithms MAY be used for
   generation.

   All entities MUST implement the DH-POP Proof-of-Possession as
   defined in [DH-POP] Section 4.



   No signature signing alg.

   The extendedFailInfo field SHOULD NOT be populated in the
   CMCStatusInfo object, the failInfo  field SHOULD be used to relay
   this information.

   All entities MUST process the following control attributes:
   CMCStatusInfoEx, CMCStatusInfo,

   All entities MUST implement the HTTP transport mechanism as defined
   in [CMC-TRANS].  Other transport mechanisms MAY be implemented.

4. Requirements for End-Entities

   EEs MAY generate PKCS10 certificate requests.  EEs SHOULD generate
   CRMF certificate requests.  EEs MUST generate one of the certificate
   request messages.

   EEs MUST implement either the Simple or Full Enrollment protocol.

5. 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

6. Requirements for RAs

   RAs MUST implement the following additional control attributes:
   identification, identityProof, dataReturn, transactionID,
   senderNonce, recipientNonce, lraPOPWitness,

7. Acknowledgments

   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.

8. References

   [CMS]      Housley, R., "Cryptographic Message Syntax", RFC 2630,
              June 1999.

   [CRMF]     Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
              X.509 Certificate Request Message Format", RFC 2511,
   March
              1999.



   [DH]       B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"

   [DH-POP]   H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-
              Possession Algorithms", Work in Progress.

   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [PKCS1]    Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
              2313, March 1998.

   [PKCS7]    Kaliski, B., "PKCS #7: Cryptographic Message Syntax
   v1.5",
              RFC 2315, October 1997.

   [PKCS8]    RSA Laboratories, "PKCS#8: Private-Key Information Syntax
              Standard, Version 1.2", November 1, 1993.

   [PKCS10]   Kaliski, B., "PKCS #10: Certification Request Syntax
              v1.5", RFC 2314, October 1997.

   [PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 2459, January 1999.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SMIMEV2]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
   L.
              Repka, "S/MIME Version 2 Message Specification", RFC
   2311,
              March 1998.

   [SMIMEV3]  Ramsdell, B., "S/MIME Version 3 Message Specification",
              RFC 2633, June 1999.

   [X942]     Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
              2631, June 1999.

9. Authors' Addresses

   Michael Myers
   TraceRoute Security, Inc.

   EMail: myers@coastside.inc


   Xiaoyi Liu
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134

   Phone: (480) 526-7430
   EMail: xliu@cisco.com




   Jim Schaad
   Soaring Hawk Consulting

   EMail:  jimsch@exmsft.com


   Jeff Weinstein

   EMail: jsw@meer.net


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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