One document matched: draft-ietf-pkix-cmc-compl-04.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes"?>
<rfc docName="draft-ietf-pkix-cmc-compl-04" ipr="full3978" obsoletes="" updates="">
<front>
<title>CMC Compliance Document</title>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<postal>
<street>PO Box 675</street>
<city>Gold Bar</city>
<region>WA</region>
<code>98251</code>
</postal>
<phone>(425) 785-1031</phone>
<email>jimsch@exmsft.com</email>
</address>
</author>
<author initials="M." surname="Myers" fullname="Michael Myers">
<organization>TraceRoute Security, Inc.</organization>
<address>
<email>myers@fastq.com</email>
</address>
</author>
<date month="November" year="2007"/>
<workgroup>PKIX Working Group</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Overview">
<t>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 Certificate Authority(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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="terms" title="Terminology">
<t>There are several different terms, abbreviations and acronyms used in this document that we define here for convenience and consistency of usage:</t>
<t>
<list style="hanging">
<t hangText="End-Entity"> (EE) refers to the entity that owns a key pair and for whom a certificate is issued.</t>
<t hangText="Registration Authority (RA)"> or Local RA (LRA) refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the End-Entity and the Certification Authority. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.</t>
<t hangText="Certification Authority"> (CA) refers to the entity that issues certificates.</t>
<t hangText="Client">refers to an entity that creates a PKI Request. In this document both RAs and EEs can be clients.</t>
<t hangText="Server">refers to the entities that process PKI Requests and create PKI Responses. In this document both CAs and RAs can be servers.</t>
<t hangText="PKCS #10">refers to the Public Key Cryptography Standard #10 <xref target="PKCS10"/>, which defines a certification request syntax.</t>
<t hangText="CRMF">refers to the Certificate Request Message Format RFC <xref target="CRMF"/>. CMC uses this certification request syntax defined in this document as part of the protocol.</t>
<t hangText="CMS">refers to the Cryptographic Message Syntax RFC <xref target="CMS"/>. This document provides for basic cryptographic services including encryption and signing with and without key management.</t>
<t hangText="PKI Request/Response"> refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc.</t>
<t hangText="Proof-Of-Identity">refers to the client proving they are who they say that are to the server.</t>
<t hangText="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.</t>
<t hangText="Transport wrapper"> refers to the outermost CMS wrapping layer.</t>
</list>
</t>
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section anchor="all" title="Requirements for All Entities">
<t>All <xref target="CMC-STRUCT"/> and <xref target="CMC-TRANS"/> compliance statements MUST be adhered to unless specifically stated otherwise in this document.</t>
<t>All entities MUST support Full PKI Requests, Simple PKI Responses and Full PKI Responses. Severs SHOULD support Simple PKI Requests.</t>
<t>All entities MUST support the use of the CRMF syntax for certification requests. Support for the PKCS#10 syntax for certification requests SHOULD be implemented by servers.</t>
<t>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.</t>
<t>All entities MUST implement the HTTP transport mechanism as defined in <xref target="CMC-TRANS"/>. Other transport mechanisms MAY be implemented.</t>
<section title="Cryptographic Algorithm Requirements">
<t>All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in SignedData (see <xref target="CMS-ALG"/>). Entities MAY be verify other signature algorithms. It is strongly suggested that RSA-PSS with SHA-1 be verified (see <xref target="CMS-RSA-PSS"/>). It is strongly suggested that SHA-256 using RSA and RSA-PSS be verified (see <xref target="RSA-256"/>).</t>
<t>All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for SignedData (see <xref target="CMS-ALG"/>). Other signatures algorithms MAY be used for generation.</t>
<t>All entities MUST support AES as the content encryption algorithm for EnvelopedData (see <xref target="CMS-AES"/>). Other content encryption algorithms MAY be implemented.</t>
<t>All entities MUST support RSA as a key transport algorithm for EnvelopedData (see <xref target="CMS-ALG"/>). All entities SHOULD support RSA-OAEP (see <xref target="CMS-RSA-OAEP"/>) as a key transport algorithm. Other key transport algorithms MAY be implemented.</t>
<t>If an entity supports key agreement for EnvelopedData, they MUST support Diffie-Hellman (see <xref target="CMS-DH"/>).</t>
<t>If an entity supports PasswordRecipientInfo for EnvelopedData or AuthenticatedData, they MUST support PBKDF2 for key derivation algorithms. They MUST support AES key wrap (see <xref target="RFC3394"/> as the key encryption algorithm. </t>
<t>If AuthenticatedData is supported, PasswordRecipientInfo MUST be supported.</t>
<t>Algorithm requirements for the Identity Proof Version 2 control (Section 6.2.1 of <xref target="CMC-STRUCT"/>) are: SHA-1 MUST be implemented for hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1 MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented for macAlgId.</t>
<t>Algorithm requirements for the Pop Link Witness Version 2 control (Section 5.3.1 of <xref target="CMC-STRUCT"/>) are: SHA-1 MUST be implemented for keyGenAlgorithm. SHA-256 SHOUL be implemented for keyGenAlgorithm. PBKDF2 MAY be implemented for keyGenAlgorithm. HMAC-SHA1 MUST be implemented for macAlgorithm. HMAC-SHA256 SHOULD be implemented for macAlgorithm.</t>
<t>Algorithm requirements for the Encrypted POP and Decrypted POP controls (Section 6.7 of <xref target="CMC-STRUCT"/>) are: SHA-1 MUST be implemented for witnessAlgID. SHA-256 SHULD be implemented for witnessAlgID. HMAC-SHA1 MUST be implemented for thePOPAlgID. HMAC-SHA256 SHOULD be implemented for thePOPAlgID.</t>
<t>Algorithm requirements for Publish Trust Anchors control (Section 6.15 of <xref target="CMC-STRUCT"/>) are: SHA-1 MUST be implemented for hashAlgorithm. SHA-256 SHOULD be implemented for hashAlgorithm.</t>
<t>If an EE generates DH keys for certification, it MUST support section 4 of <xref target="DH-POP"/>. EEs MAY support section 3 of <xref target="DH-POP"/>. CAs and RAs that do POP verification MUST support section 4 of <xref target="DH-POP"/> and SHOULD support section 3 of <xref target="DH-POP"/>.</t>
<t>EEs that need to use a signature algorithm for keys that cannot produce a signature MUST support Appendix C of <xref target="CMC-STRUCT"/> and MUST support the Encrypted/Decrypted POP controls. CAs and RAs that do POP verification MUST support this signature algorithm and MUST support the Encrypted/Decrypted POP controls.</t>
</section>
<section title="Controls">
<texttable anchor="control_table" title="CMC Control Attributes">
<preamble>The following table lists the name and level of support required for each control.</preamble>
<ttcol align="left">Control</ttcol>
<ttcol align="left">EE</ttcol>
<ttcol align="left">RA</ttcol>
<ttcol align="left">CA</ttcol>
<c>Extended CMC Status Info</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>CMC Status Info</c> <c>SHOULD</c> <c>SHOULD</c> <c>SHOULD</c>
<c>Identity Proof Version 2</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Identity Proof</c> <c>SHOULD</c> <c>SHOULD</c> <c>SHOULD</c>
<c>Identification</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>POP Link Random</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>POP Link Witness Version 2</c><c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>POP Link Witness</c> <c>SHOULD</c> <c>MUST</c> <c>MUST</c>
<c>Data Return</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Modify Cert Request</c> <c>N/A</c> <c>MUST</c> <c>(2)</c>
<c>Add Extensions</c> <c>N/A</c> <c>MAY</c> <c>(1)</c>
<c>Transaction ID</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Sender Nonce</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Recipient Nonce</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Encrypted POP</c> <c>(4)</c> <c>(5)</c> <c>SHOULD</c>
<c>Decrypted POP</c> <c>(4)</c> <c>(5)</c> <c>SHOULD</c>
<c>RA POP Witness</c> <c>N/A</c> <c>SHOULD</c> <c>(1)</c>
<c>Get Certificate</c> <c>optional</c> <c>optional</c> <c>optional</c>
<c>Get CRL</c> <c>optional</c> <c>optional</c> <c>optional</c>
<c>Revocation Request</c> <c>SHOULD</c> <c>SHOULD</c> <c>MUST</c>
<c>Registration Info</c> <c>SHOULD</c> <c>SHOULD</c> <c>SHOULD</c>
<c>Response Information</c> <c>SHOULD</c> <c>SHOULD</c> <c>SHOULD</c>
<c>Query Pending</c> <c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Confirm Cert. Acceptance</c><c>MUST</c> <c>MUST</c> <c>MUST</c>
<c>Publish Trust Anchors</c> <c>(3)</c> <c>(3)</c> <c>(3)</c>
<c>Authenticate Data</c> <c>(3)</c> <c>(3)</c> <c>(3)</c>
<c>Batch Request</c> <c>N/A</c> <c>MUST</c> <c>(2)</c>
<c>Batch Responses</c> <c>N/A</c> <c>MUST</c> <c>(2)</c>
<c>Publication Information</c> <c>optional</c> <c>optional</c> <c>optional</c>
<c>Control Processed</c> <c>N/A</c> <c>MUST</c> <c>(2)</c>
</texttable>
<t>Notes:</t>
<list style="numbers">
<t>CAs SHOULD implement this control if designed to work with RAs.</t>
<t>CAs MUST implement this control if designed to work with RAs.</t>
<t>Implementation is optional for these controls. We strongly suggest that they be implemented in order to populate client trust anchors.</t>
<t>EEs only need to implement this if (a) they support key agreement algorithms or (b) they need to operate in environments where the hardware keys cannot provide POP.</t>
<t>RAs SHOULD implement this if they implement RA POP Witness.</t>
</list>
<t>Strong consideration should be given to implementing the Authenticate Data and Publish Trust Anchors controls as this gives a simple method for distributing trust anchors into clients without user intervention.</t>
</section>
<section title="CRMF Feature Requirements">
<t>The following additional restrictions are placed on CRMF features:</t>
<t>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.</t>
<t>The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported. An alternative method is under development to provide this functionality.</t>
<t>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.</t>
<t>The id-regCtrl-protocolEncrKey is not used.</t>
</section>
<section anchor="client" title="Requirements for Clients">
<t>No additional requirements.</t>
</section>
</section>
<section anchor="server" title="Requirements for Servers">
<t>No additional requirements.</t>
</section>
<section anchor="EE" title="Requirements for EEs">
<t>If an entity implements Diffie-Hellman, it MUST implement either the DH-POP Proof-of-Possession as defined in <xref target="DH-POP"/> Section 4 or the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.</t>
</section>
<section anchor="RA" title="Requirements for RAs">
<t>RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.</t>
<t>All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in section 3.8 of <xref target="CMC-STRUCT"/></t>
</section>
<section anchor="CA" title="Requirements for CAs">
<t>Providing for CAs to work in an environment with RAs is strongly suggested.
Implementation of such support is strongly suggested as this permits the delegation of substantial administrative interaction onto an RA rather than at the CA.</t>
<t>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-SHA1 and DH keys <xref target="SMALL-SUB-GROUP"/> or known bad exponents for RSA keys.</t>
<t>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.</t>
<t>CAs SHOULD implement both the DH-POP Proof-of-Possession as defined in <xref target="DH-POP"/> Section 4 and the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.</t>
</section>
<section title="Security Considerations">
<t>This document uses <xref target="CMC-STRUCT"/> and <xref target="CMC-TRANS"/> as building blocks to this document. The security sections of those two documents are included by reference.</t>
<t>Knowledge of how an entity is expected to operate is vital in determining which sections of requirements are applicable to that entity. Care needs to be taken in determining which sections apply and fullly implementing the necessary code.</t>
<t>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 <xref target="SMALL-SUB-GROUP"/> and <xref target="HASH-ATTACKS"/>.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations in this document.</t>
</section>
<section title="Acknowledgements">
<t>The authors and the Working Group are grateful for the participation of Xiaoui Lui and Jeff Weinstein in helping to author the original versions of this document. </t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="CMC-STRUCT">
<front>
<title>Certificate Management Messages over CMS</title>
<author initials="J." surname="Schaad" fullname="Jim Schaad"/>
<author initials="M." surname="Myers" fullname="Michael Myers"/>
<date month="August" year="2006"/>
</front>
<seriesInfo name="draft-ietf-pkix-2797-bis-05.txt" value=""/>
</reference>
<reference anchor="CMC-TRANS">
<front>
<title>CMC Transport</title>
<author initials="J." surname="Schaad"/>
<author initials="M." surname="Myers" fullname="Michael Myers"/>
<author initials="X." surname="Liu" fullname="Xiaoyi Liu"/>
<author initials="J." surname="Weinstein" fullname="Jeff Weinstein"/>
<date month="December" year="2004"/>
</front>
<seriesInfo name="Work In Progress" value=""/>
</reference>
<reference anchor="CMS">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials="R." surname="Housley"/>
<date month="July" year="2004"/>
</front>
<seriesInfo name="RFC" value="3852"/>
</reference>
<reference anchor="CMS-AES">
<front>
<title>Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
<author initials="J." surname="Schaad"/>
<date month="July" year="2003"/>
</front>
<seriesInfo name="RFC" value="3565"/>
</reference>
<reference anchor="CMS-ALG">
<front>
<title>Cryptographic Message Syntax (CMS) Algorithms</title>
<author initials="R." surname="Housley"/>
<date month="August" year="2002"/>
</front>
<seriesInfo name="RFC" value="3370"/>
</reference>
<reference anchor="CMS-DH">
<front>
<title>Diffie-Hellman Key Agreement Method</title>
<author initials="E." surname="Rescorla"/>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2631"/>
</reference>
<reference anchor="CRMF">
<front>
<title>Internet X.509 Certificate Request M2essage Format</title>
<author initials="J." surname="Schaad"/>
<date month="September" year="2005"/>
</front>
<seriesInfo name="RFC" value="4211"/>
</reference>
<reference anchor="CMS-RSA-OAEP">
<front>
<title>Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)</title>
<author initials="R." surname="Housley"/>
<date month="July" year="2003"/>
</front>
<seriesInfo name="RFC" value="3560"/>
</reference>
<reference anchor="CMS-RSA-PSS">
<front>
<title>Use of the RSA PSS Signature Algorithm in CMS</title>
<author initials="J." surname="Schaad"/>
<date month="December" year="2003"/>
</front>
<seriesInfo name="Work In Progress" value=""/>
</reference>
<reference anchor="DH-POP">
<front>
<title>Diffie-Hellman Proof-of-Possession Algorithms</title>
<author initials="H." surname="Prafullchandra"/>
<author initials="J." surname="Schaad"/>
<date month="June" year="2000"/>
</front>
<seriesInfo name="RFC" value="2875"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
</reference>
<reference anchor="RSA-256">
<front>
<title>Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="J." surname="Schaad"/>
<author initials="B." surname="Kaliski"/>
<author initials="R." surname="Housley"/>
<date month="June" year="2005"/>
</front>
<seriesInfo name="RFC" value="4055"/>
</reference>
<reference anchor="RFC3394">
<front>
<title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title>
<author initials="J." surname="Schaad"/>
<author initials="R." surname="Housley"/>
<date month="September" year="2002"/>
</front>
<seriesInfo name="RFC" value="3394"/>
</reference>
</references>
<references title="Informational References">
<reference anchor="PKCS10">
<front>
<title>PKCS #10: Certification Request Syntax v1.5</title>
<author initials="B." surname="Kaliski"/>
<date year="1997" month="October"/>
</front>
<seriesInfo name="RFC" value="2314"/>
</reference>
<reference anchor="SMALL-SUB-GROUP">
<front>
<title>Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME</title>
<author initials="R." surname="Zuccherato"/>
<date month="March" year="2000"/>
</front>
<seriesInfo name="RFC" value="2785"/>
</reference>
<reference anchor="HASH-ATTACKS">
<front>
<title>Attacks on Cryptographic Hashes in Internet Protocols</title>
<author initials="P." surname="Hoffman"/>
<author initials="B." surname="Schneier"/>
<date month="November" year="2005"/>
</front>
<seriesInfo name="RFC" value="4270"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:33:28 |