| < draft-ietf-lamps-cmp-updates-17.txt | draft-ietf-lamps-cmp-updates-18.txt > | |||
|---|---|---|---|---|
| LAMPS Working Group H. Brockhaus, Ed. | LAMPS Working Group H. Brockhaus, Ed. | |||
| Internet-Draft D. von Oheimb | Internet-Draft D. von Oheimb | |||
| Updates: 4210, 5912, 6712 (if approved) Siemens | Updates: 4210, 5912, 6712 (if approved) Siemens | |||
| Intended status: Standards Track J. Gray | Intended status: Standards Track J. Gray | |||
| Expires: 16 July 2022 Entrust | Expires: 8 October 2022 Entrust | |||
| 12 January 2022 | 6 April 2022 | |||
| Certificate Management Protocol (CMP) Updates | Certificate Management Protocol (CMP) Updates | |||
| draft-ietf-lamps-cmp-updates-17 | draft-ietf-lamps-cmp-updates-18 | |||
| Abstract | Abstract | |||
| This document contains a set of updates to the syntax and transfer of | This document contains a set of updates to the syntax and transfer of | |||
| Certificate Management Protocol (CMP) version 2. This document | Certificate Management Protocol (CMP) version 2. This document | |||
| updates RFC 4210, RFC 5912, and RFC 6712. | updates RFC 4210, RFC 5912, and RFC 6712. | |||
| The aspects of CMP updated in this document are using EnvelopedData | The aspects of CMP updated in this document are using EnvelopedData | |||
| instead of EncryptedValue, clarifying the handling of p10cr messages, | instead of EncryptedValue, clarifying the handling of p10cr messages, | |||
| improving the crypto agility, as well as adding new general message | improving the crypto agility, as well as adding new general message | |||
| types, extended key usages to identify certificates for use with CMP, | types, extended key usages to identify certificates for use with CMP, | |||
| and '.well-known' HTTP path segments. | and well-known URI path segments. | |||
| To properly differentiate the support of EnvelopedData instead of | To properly differentiate the support of EnvelopedData instead of | |||
| EncryptedValue, the CMP version 3 is introduced in case a transaction | EncryptedValue, the CMP version 3 is introduced in case a transaction | |||
| is supposed to use EnvelopedData. | is supposed to use EnvelopedData. | |||
| CMP version 3 is introduced to enable signaling support of | CMP version 3 is introduced to enable signaling support of | |||
| EnvelopedData instead of EncryptedValue and signaling the use of an | EnvelopedData instead of EncryptedValue and signaling the use of an | |||
| explicit hash AlgorithmIdentifier in certConf messages, as far as | explicit hash AlgorithmIdentifier in certConf messages, as far as | |||
| needed. | needed. | |||
| skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| 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." | |||
| This Internet-Draft will expire on 16 July 2022. | This Internet-Draft will expire on 8 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Convention and Terminology . . . . . . . . . . . . . . . 4 | 1.1. Convention and Terminology . . . . . . . . . . . . . . . 4 | |||
| 2. Updates to RFC 4210 - Certificate Management Protocol | 2. Updates to RFC 4210 - Certificate Management Protocol | |||
| (CMP) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | (CMP) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 4 | 2.1. New Section 1.1. - Changes Since RFC 4210 . . . . . . . . 4 | |||
| 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 5 | 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 5 | |||
| 2.3. Update Section 5.1.1. - PKI Message Header . . . . . . . 7 | 2.3. Update Section 5.1.1. - PKI Message Header . . . . . . . 7 | |||
| 2.4. New Section 5.1.1.3. - CertProfile . . . . . . . . . . . 7 | 2.4. New Section 5.1.1.3. - CertProfile . . . . . . . . . . . 7 | |||
| 2.5. Update Section 5.1.3.1. - Shared Secret Information . . . 8 | 2.5. Update Section 5.1.3.1. - Shared Secret Information . . . 8 | |||
| 2.6. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 8 | 2.6. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 8 | |||
| 2.7. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 9 | 2.7. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 9 | |||
| 2.8. Update Section 5.3.4. - Certification Response . . . . . 11 | 2.8. New Section 5.2.9 - GeneralizedTime . . . . . . . . . . . 11 | |||
| 2.9. Update Section 5.3.18. - Certificate Confirmation | 2.9. Update Section 5.3.4. - Certification Response . . . . . 11 | |||
| 2.10. Update Section 5.3.18. - Certificate Confirmation | ||||
| Content . . . . . . . . . . . . . . . . . . . . . . . . 12 | Content . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13 | 2.11. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13 | |||
| 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key | 2.12. Update Section 5.3.19.3. - Encryption/Key Agreement Key | |||
| Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13 | Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13 | 2.13. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13 | |||
| 2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14 | 2.14. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14 | |||
| 2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 14 | 2.15. New Section 5.3.19.15 - Root CA Certificate Update . . . 14 | |||
| 2.15. New Section 5.3.19.16 - Certificate Request Template . . 15 | 2.16. New Section 5.3.19.16 - Certificate Request Template . . 15 | |||
| 2.16. New Section 5.3.19.17 - CRL update retrieval . . . . . . 16 | 2.17. New Section 5.3.19.17 - CRL Update Retrieval . . . . . . 16 | |||
| 2.17. Update Section 5.3.21 - Error Message Content . . . . . . 17 | 2.18. Update Section 5.3.21 - Error Message Content . . . . . . 17 | |||
| 2.18. Replace Section 5.3.22 - Polling Request and Response . . 18 | 2.19. Replace Section 5.3.22 - Polling Request and Response . . 18 | |||
| 2.19. Update Section 7 - Version Negotiation . . . . . . . . . 22 | 2.20. Update Section 7 - Version Negotiation . . . . . . . . . 22 | |||
| 2.20. Update Section 7.1.1. - Clients Talking to RFC 2510 | 2.21. Update Section 7.1.1. - Clients Talking to RFC 2510 | |||
| Servers . . . . . . . . . . . . . . . . . . . . . . . . 24 | Servers . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 2.21. Add Section 8.4 - Private keys for certificate signing and | 2.22. Add Section 8.4 - Private Keys for Certificate Signing and | |||
| CMP message protection . . . . . . . . . . . . . . . . . 24 | CMP Message Protection . . . . . . . . . . . . . . . . . 24 | |||
| 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and | 2.23. Add Section 8.5 - Entropy of Random Numbers, Key Pairs, and | |||
| shared secret information . . . . . . . . . . . . . . . 24 | Shared Secret Information . . . . . . . . . . . . . . . 24 | |||
| 2.23. Add Section 8.6 - Trust anchor provisioning using CMP | 2.24. Add Section 8.6 - Trust Anchor Provisioning Using CMP | |||
| messages . . . . . . . . . . . . . . . . . . . . . . . . 25 | Messages . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 2.24. Update Section 9 - IANA Considerations . . . . . . . . . 26 | 2.25. Update Section 9 - IANA Considerations . . . . . . . . . 26 | |||
| 2.25. Update Appendix B - The Use of Revocation Passphrase . . 28 | 2.26. Update Appendix B - The Use of Revocation Passphrase . . 28 | |||
| 2.26. Update Appendix C - Request Message Behavioral | 2.27. Update Appendix C - Request Message Behavioral | |||
| Clarifications . . . . . . . . . . . . . . . . . . . . . 28 | Clarifications . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 2.27. Update Appendix D.1. - General Rules for Interpretation of | 2.28. Update Appendix D.1. - General Rules for Interpretation of | |||
| These Profiles . . . . . . . . . . . . . . . . . . . . . 29 | These Profiles . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 2.28. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30 | 2.29. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30 | |||
| 2.29. Update Appendix D.4. - Initial Registration/Certification | 2.30. Update Appendix D.4. - Initial Registration/Certification | |||
| (Basic Authenticated Scheme) . . . . . . . . . . . . . . 30 | (Basic Authenticated Scheme) . . . . . . . . . . . . . . 30 | |||
| 3. Updates to RFC 6712 - HTTP Transfer for the Certificate | 3. Updates to RFC 6712 - HTTP Transfer for the Certificate | |||
| Management Protocol (CMP) . . . . . . . . . . . . . . . . 30 | Management Protocol (CMP) . . . . . . . . . . . . . . . . 30 | |||
| 3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30 | 3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30 | |||
| 3.2. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 31 | 3.2. New Section 1.1. - Changes Since RFC 6712 . . . . . . . . 31 | |||
| 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 | 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 | |||
| 3.4. Update Section 6. - IANA Considerations . . . . . . . . . 32 | 3.4. Update Section 6. - IANA Considerations . . . . . . . . . 32 | |||
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
| 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 33 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 33 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 35 | 7.2. Informative References . . . . . . . . . . . . . . . . . 35 | |||
| Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 36 | Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 37 | |||
| A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 37 | A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 37 | |||
| A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 50 | A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 | |||
| Appendix B. History of changes . . . . . . . . . . . . . . . . . 64 | Appendix B. History of Changes . . . . . . . . . . . . . . . . . 64 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 | |||
| 1. Introduction | 1. Introduction | |||
| While using CMP [RFC4210] in industrial and IoT environments and | While using CMP [RFC4210] in industrial and IoT environments and | |||
| developing the Lightweight CMP Profile | developing the Lightweight CMP Profile | |||
| [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were | [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were | |||
| identified in the original CMP specification. This document updates | identified in the original CMP specification. This document updates | |||
| RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these | RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these | |||
| limitations. | limitations. | |||
| Among others, this document improves the crypto agility of CMP, which | Among others, this document improves the crypto agility of CMP, which | |||
| means to be flexible to react on future advances in cryptography. | means to be flexible to react on future advances in cryptography. | |||
| This document also introduces new extended key usages to identify CMP | This document also introduces new extended key usages to identify CMP | |||
| endpoints on registration and certification authorities. | endpoints on registration and certification authorities. | |||
| As the main content of RFC 4210 [RFC4210] and RFC 6712 [RFC6712] | ||||
| stays unchanged, this document lists all sections that are updated, | ||||
| replaced, or added to the current text of the respective RFCs. | ||||
| 1.1. Convention and Terminology | 1.1. Convention and Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| Technical terminology is used in conformance with RFC 4210 [RFC4210], | Technical terminology is used in conformance with RFC 4210 [RFC4210], | |||
| RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words | RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words | |||
| skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 32 ¶ | |||
| KGA: Key generation authority, which generates key pairs on behalf | KGA: Key generation authority, which generates key pairs on behalf | |||
| of an EE. The KGA could be co-located with an RA or a CA. | of an EE. The KGA could be co-located with an RA or a CA. | |||
| EE: End entity, a user, device, or service that holds a PKI | EE: End entity, a user, device, or service that holds a PKI | |||
| certificate. An identifier for the EE is given as its subject | certificate. An identifier for the EE is given as its subject | |||
| of the certificate. | of the certificate. | |||
| 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) | 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) | |||
| 2.1. New Section 1.1. - Changes since RFC 4210 | 2.1. New Section 1.1. - Changes Since RFC 4210 | |||
| The following subsection describes feature updates to RFC 4210 | The following subsection describes feature updates to RFC 4210 | |||
| [RFC4210]. They are always related to the base specification. Hence | [RFC4210]. They are always related to the base specification. Hence | |||
| references to the original sections in RFC 4210 [RFC4210] are used | references to the original sections in RFC 4210 [RFC4210] are used | |||
| whenever possible. | whenever possible. | |||
| Insert this section at the end of the current Section 1: | Insert this section at the end of the current Section 1: | |||
| 1.1. Changes since RFC 4210 | 1.1. Changes Since RFC 4210 | |||
| The following updates are made in [thisRFC]: | The following updates are made in [thisRFC]: | |||
| * Add new extended key usages for various CMP server types, e.g., | * Add new extended key usages for various CMP server types, e.g., | |||
| registration authority and certification authority, to express the | registration authority and certification authority, to express the | |||
| authorization of the entity identified in the certificate | authorization of the entity identified in the certificate | |||
| containing the respective extended key usage extension to act as | containing the respective extended key usage extension to act as | |||
| the indicated PKI management entity. | the indicated PKI management entity. | |||
| * Extend the description of multiple protection to cover additional | * Extend the description of multiple protection to cover additional | |||
| skipping to change at page 6, line 6 ¶ | skipping to change at page 6, line 6 ¶ | |||
| Insert this section at the end of the current Section 4: | Insert this section at the end of the current Section 4: | |||
| 4.5. Extended Key Usage | 4.5. Extended Key Usage | |||
| The Extended Key Usage (EKU) extension indicates the purposes for | The Extended Key Usage (EKU) extension indicates the purposes for | |||
| which the certified key pair may be used. It therefore restricts the | which the certified key pair may be used. It therefore restricts the | |||
| use of a certificate to specific applications. | use of a certificate to specific applications. | |||
| A CA may want to delegate parts of its duties to other PKI management | A CA may want to delegate parts of its duties to other PKI management | |||
| entities. The mechanism to prove this delegation explained in this | entities. This section provides a mechanism to both prove this | |||
| section offers an automatic way of checking the authorization of such | delegation and enable an automated means for checking the | |||
| delegation. Such delegation MAY also be expressed by other means, | authorization of this delegation. Such delegation MAY also be | |||
| e.g., explicit configuration. | expressed by other means, e.g., explicit configuration. | |||
| To offer automatic validation for the delegation of a role by a CA to | To offer automatic validation for the delegation of a role by a CA to | |||
| another entity, the certificates used for CMP message protection or | another entity, the certificates used for CMP message protection or | |||
| signed data for central key generation MUST be issued by the | signed data for central key generation MUST be issued by the | |||
| delegating CA and MUST contain the respective EKUs. This proves the | delegating CA and MUST contain the respective EKUs. This proves the | |||
| authorization of this entity by the delegating CA to act in the given | authorization of this entity by the delegating CA to act in the given | |||
| role as described below. | role as described below. | |||
| The OIDs to be used for these EKUs are: | The OIDs to be used for these EKUs are: | |||
| skipping to change at page 9, line 15 ¶ | skipping to change at page 9, line 15 ¶ | |||
| as an RA MAY forward that message adding its own protection (which | as an RA MAY forward that message adding its own protection (which | |||
| MAY be a MAC or a signature, depending on the information and | MAY be a MAC or a signature, depending on the information and | |||
| certificates shared between the RA and the CA). Moreover, multiple | certificates shared between the RA and the CA). Moreover, multiple | |||
| PKI messages MAY be aggregated. There are several use cases for such | PKI messages MAY be aggregated. There are several use cases for such | |||
| messages. | messages. | |||
| * The RA confirms having validated and authorized a message and | * The RA confirms having validated and authorized a message and | |||
| forwards the original message unchanged. | forwards the original message unchanged. | |||
| * The RA modifies the message(s) in some way (e.g., adds or modifies | * The RA modifies the message(s) in some way (e.g., adds or modifies | |||
| particular field values or add new extensions) before forwarding | particular field values or adds new extensions) before forwarding | |||
| them, then it MAY create its own desired PKIBody. If the changes | them, then it MAY create its own desired PKIBody. If the changes | |||
| made by the RA to PKIMessage break the POP of a certificate | made by the RA to PKIMessage break the POP of a certificate | |||
| request, the RA MUST set the POP RAVerified. It MAY include the | request, the RA MUST set the popo field to RAVerified. It MAY | |||
| original PKIMessage from the EE in the generalInfo field of | include the original PKIMessage from the EE in the generalInfo | |||
| PKIHeader of a nested message (to accommodate, for example, cases | field of PKIHeader of a nested message (to accommodate, for | |||
| in which the CA wishes to check POP or other information on the | example, cases in which the CA wishes to check POP or other | |||
| original EE message). The infoType to be used in this situation | information on the original EE message). The infoType to be used | |||
| is {id-it 15} (see Section 5.3.19 for the value of id-it) and the | in this situation is {id-it 15} (see Section 5.3.19 for the value | |||
| infoValue is PKIMessages (contents MUST be in the same order as | of id-it) and the infoValue is PKIMessages (contents MUST be in | |||
| the message in PKIBody). | the same order as the message in PKIBody). | |||
| * The RA collects several messages that are to be forwarded in the | * A PKI management entity collects several messages that are to be | |||
| same direction and forwards them in a batch. In communication to | forwarded in the same direction and forwards them in a batch. | |||
| the CA request messages and in communication from the CA response | Request messages can be transferred as batch upstream (towards the | |||
| or announcement messages will be collected. This can for instance | CA); response or announce messages can be transferred as batch | |||
| be used when bridging an off-line connection between two PKI | downstream (towards an RA, but not to the EE). This can for | |||
| management entities. | instance be used when bridging an off-line connection between two | |||
| PKI management entities. | ||||
| These use cases are accomplished by nesting the messages within a new | These use cases are accomplished by nesting the messages within a new | |||
| PKI message. The structure used is as follows: | PKI message. The structure used is as follows: | |||
| NestedMessageContent ::= PKIMessages | NestedMessageContent ::= PKIMessages | |||
| 2.7. Replace Section 5.2.2. - Encrypted Values | 2.7. Replace Section 5.2.2. - Encrypted Values | |||
| Section 5.2.2 of RFC 4210 [RFC4210] describes the use of | Section 5.2.2 of RFC 4210 [RFC4210] describes the use of | |||
| EncryptedValue to transport encrypted data. This document extends | EncryptedValue to transport encrypted data. This document extends | |||
| skipping to change at page 10, line 14 ¶ | skipping to change at page 10, line 22 ¶ | |||
| EncryptedKey ::= CHOICE { | EncryptedKey ::= CHOICE { | |||
| encryptedValue EncryptedValue, -- deprecated | encryptedValue EncryptedValue, -- deprecated | |||
| envelopedData [0] EnvelopedData } | envelopedData [0] EnvelopedData } | |||
| See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS | See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS | |||
| [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data | [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data | |||
| structure offers the choice to either use EncryptedValue (for | structure offers the choice to either use EncryptedValue (for | |||
| backward compatibility only) or EnvelopedData. The use of the | backward compatibility only) or EnvelopedData. The use of the | |||
| EncryptedValue structure has been deprecated in favor of the | EncryptedValue structure has been deprecated in favor of the | |||
| EnvelopedData structure. Therefore, it is recommended to use | EnvelopedData structure. Therefore, it is RECOMMENDED to use | |||
| EnvelopedData. | EnvelopedData. | |||
| Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused | Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused | |||
| here, which makes the update backward compatible. Using the new | here, which makes the update backward compatible. Using the new | |||
| syntax with the untagged default choice EncryptedValue is bits-on- | syntax with the untagged default choice EncryptedValue is bits-on- | |||
| the-wire compatible with the old syntax. | the-wire compatible with the old syntax. | |||
| To indicate support for EnvelopedData the pvno cmp2021 is introduced | To indicate support for EnvelopedData the pvno cmp2021 is introduced | |||
| by this document. Details on the usage of pvno values is described | by this document. Details on the usage of pvno values is described | |||
| in Section 7. | in Section 7. | |||
| skipping to change at page 11, line 20 ¶ | skipping to change at page 11, line 29 ¶ | |||
| * Recipient's certificate that contains a key usage extension | * Recipient's certificate that contains a key usage extension | |||
| asserting keyEncipherment: The content-encryption key will be | asserting keyEncipherment: The content-encryption key will be | |||
| protected using the key transport key management technique, as | protected using the key transport key management technique, as | |||
| specified in CMS section 6.2.1 [RFC5652]. | specified in CMS section 6.2.1 [RFC5652]. | |||
| * A password or shared secret: The content-encryption key will be | * A password or shared secret: The content-encryption key will be | |||
| protected using the password-based key management technique, as | protected using the password-based key management technique, as | |||
| specified in CMS section 6.2.4 [RFC5652]. | specified in CMS section 6.2.4 [RFC5652]. | |||
| 2.8. Update Section 5.3.4. - Certification Response | 2.8. New Section 5.2.9 - GeneralizedTime | |||
| The following subsection point implementers to [RFC5280] regarding | ||||
| usage of GeneralizedTime. | ||||
| Insert this section after Section 5.2.8.4: | ||||
| 5.2.9 GeneralizedTime | ||||
| GeneralizedTime is a standard ASN.1 type and SHALL be used as | ||||
| specified in RFC 5280 Section 4.1.2.5.2 [RFC5280]. | ||||
| 2.9. Update Section 5.3.4. - Certification Response | ||||
| Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification | Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification | |||
| Response. This document updates the syntax by using the parent | Response. This document updates the syntax by using the parent | |||
| structure EncryptedKey instead of EncryptedValue as described in | structure EncryptedKey instead of EncryptedValue as described in | |||
| Section 2.7 above. Moreover, it clarifies the certReqId to be used | Section 2.7 above. Moreover, it clarifies the certReqId to be used | |||
| in response to a p10cr message. | in response to a p10cr message. | |||
| Replace the ASN.1 syntax with the following text (Note: This also | Replace the ASN.1 syntax with the following text (Note: This also | |||
| fixes Errata ID 3949 and 4078): | fixes Errata ID 3949 and 4078): | |||
| skipping to change at page 12, line 47 ¶ | skipping to change at page 12, line 47 ¶ | |||
| (cp) message MUST be set to -1. | (cp) message MUST be set to -1. | |||
| Add the following as new paragraphs to the end of the section: | Add the following as new paragraphs to the end of the section: | |||
| The use of EncryptedKey is described in Section 5.2.2. | The use of EncryptedKey is described in Section 5.2.2. | |||
| Note: To indicate support for EnvelopedData the pvno cmp2021 is | Note: To indicate support for EnvelopedData the pvno cmp2021 is | |||
| introduced by this document. Details on the usage of different pvno | introduced by this document. Details on the usage of different pvno | |||
| values are described in Section 7. | values are described in Section 7. | |||
| 2.9. Update Section 5.3.18. - Certificate Confirmation Content | 2.10. Update Section 5.3.18. - Certificate Confirmation Content | |||
| This section introduces an optional hashAlg field to the CertStatus | This section introduces an optional hashAlg field to the CertStatus | |||
| type used in certConf messages to explicitly specify the hash | type used in certConf messages to explicitly specify the hash | |||
| algorithm for those certificates where no hash algorithm is specified | algorithm for those certificates where no hash algorithm is specified | |||
| in the signatureAlgorithm field. | in the signatureAlgorithm field. | |||
| Replace the ASN.1 Syntax of CertStatus with the following text: | Replace the ASN.1 Syntax of CertStatus with the following text: | |||
| CertStatus ::= SEQUENCE { | CertStatus ::= SEQUENCE { | |||
| certHash OCTET STRING, | certHash OCTET STRING, | |||
| certReqId INTEGER, | certReqId INTEGER, | |||
| statusInfo PKIStatusInfo OPTIONAL, | statusInfo PKIStatusInfo OPTIONAL, | |||
| hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} | hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} | |||
| OPTIONAL | OPTIONAL | |||
| } | } | |||
| The hashAlg field SHOULD be used only in exceptional cases where the | The hashAlg field SHOULD be used only in exceptional cases where the | |||
| signatureAlgorithm of the certificate to be confirmed does not | signatureAlgorithm of the certificate to be confirmed does not | |||
| specify a hash algorithm, neither in the OID nor in the parameters. | specify a hash algorithm in the OID or in the parameters. In such | |||
| In such cases, e.g., for EdDSA, the hashAlg MUST be used to specify | cases, e.g., for EdDSA, the hashAlg MUST be used to specify the hash | |||
| the hash algorithm to be used for calculating the certHash value. | algorithm to be used for calculating the certHash value. Otherwise, | |||
| Otherwise, the certHash value SHALL be computed using the same hash | the certHash value SHALL be computed using the same hash algorithm as | |||
| algorithm as used to create and verify the certificate signature. If | used to create and verify the certificate signature. If hashAlg is | |||
| hashAlg is used, the CMP version indicated by the certConf message | used, the CMP version indicated by the certConf message header must | |||
| header must be cmp2021(3). | be cmp2021(3). | |||
| 2.10. Update Section 5.3.19.2. - Signing Key Pair Types | 2.11. Update Section 5.3.19.2. - Signing Key Pair Types | |||
| The following section clarifies the usage of the Signing Key Pair | The following section clarifies the usage of the Signing Key Pair | |||
| Types on referencing EC curves. | Types on referencing EC curves. | |||
| Insert this note at the end of Section 5.3.19.2: | Insert this note at the end of Section 5.3.19.2: | |||
| Note: In case several EC curves are supported, several id-ecPublicKey | Note: In case several EC curves are supported, several id-ecPublicKey | |||
| elements need to be given, one per named curve. | elements need to be given, one per named curve. | |||
| 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair | 2.12. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair | |||
| Types | Types | |||
| The following section clarifies the use of the Encryption/Key | The following section clarifies the use of the Encryption/Key | |||
| Agreement Key Pair Types on referencing EC curves. | Agreement Key Pair Types on referencing EC curves. | |||
| Insert this note at the end of Section 5.3.19.3: | Insert this note at the end of Section 5.3.19.3: | |||
| Note: In case several EC curves are supported, several id-ecPublicKey | Note: In case several EC curves are supported, several id-ecPublicKey | |||
| elements need to be given, one per named curve. | elements need to be given, one per named curve. | |||
| 2.12. Replace Section 5.3.19.9. - Revocation Passphrase | 2.13. Replace Section 5.3.19.9. - Revocation Passphrase | |||
| Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of | Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of | |||
| a revocation passphrase for authenticating a later revocation | a revocation passphrase for authenticating a later revocation | |||
| request. This document updates the handling by using the parent | request. This document updates the handling by using the parent | |||
| structure EncryptedKey instead of EncryptedValue to transport this | structure EncryptedKey instead of EncryptedValue to transport this | |||
| information as described in Section 2.7 above. | information as described in Section 2.7 above. | |||
| Replace the text of the section with the following text: | Replace the text of the section with the following text: | |||
| 5.3.19.9. Revocation Passphrase | 5.3.19.9. Revocation Passphrase | |||
| skipping to change at page 14, line 20 ¶ | skipping to change at page 14, line 20 ¶ | |||
| purpose of authenticating a later revocation request (in the case | purpose of authenticating a later revocation request (in the case | |||
| that the appropriate signing private key is no longer available to | that the appropriate signing private key is no longer available to | |||
| authenticate the request). See Appendix B for further details on the | authenticate the request). See Appendix B for further details on the | |||
| use of this mechanism. | use of this mechanism. | |||
| GenMsg: {id-it 12}, EncryptedKey | GenMsg: {id-it 12}, EncryptedKey | |||
| GenRep: {id-it 12}, < absent > | GenRep: {id-it 12}, < absent > | |||
| The use of EncryptedKey is described in Section 5.2.2. | The use of EncryptedKey is described in Section 5.2.2. | |||
| 2.13. New Section 5.3.19.14 - CA Certificates | 2.14. New Section 5.3.19.14 - CA Certificates | |||
| The following subsection describes PKI general messages using id-it- | The following subsection describes PKI general messages using id-it- | |||
| caCerts. The intended use is specified in Lightweight CMP Profile | caCerts. The intended use is specified in Lightweight CMP Profile | |||
| Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. | Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. | |||
| Insert this section after Section 5.3.19.13: | Insert this section after Section 5.3.19.13: | |||
| 2.3.19.14 CA Certificates | 2.3.19.14 CA Certificates | |||
| This MAY be used by the client to get CA certificates. | This MAY be used by the client to get CA certificates. | |||
| GenMsg: {id-it 17}, < absent > | GenMsg: {id-it 17}, < absent > | |||
| GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF | GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF | |||
| CMPCertificate | < absent > | CMPCertificate | < absent > | |||
| 2.14. New Section 5.3.19.15 - Root CA Certificate Update | 2.15. New Section 5.3.19.15 - Root CA Certificate Update | |||
| The following subsection describes PKI general messages using id-it- | The following subsection describes PKI general messages using id-it- | |||
| rootCaCert and id-it-rootCaKeyUpdate. The use is specified in | rootCaCert and id-it-rootCaKeyUpdate. The use is specified in | |||
| Lightweight CMP Profile Section 4.3 | Lightweight CMP Profile Section 4.3 | |||
| [I-D.ietf-lamps-lightweight-cmp-profile]. | [I-D.ietf-lamps-lightweight-cmp-profile]. | |||
| Insert this section after new Section 5.3.19.14: | Insert this section after new Section 5.3.19.14: | |||
| 5.3.19.15. Root CA Certificate Update | 5.3.19.15. Root CA Certificate Update | |||
| skipping to change at page 15, line 26 ¶ | skipping to change at page 15, line 26 ¶ | |||
| RootCaKeyUpdateContent ::= SEQUENCE { | RootCaKeyUpdateContent ::= SEQUENCE { | |||
| newWithNew CMPCertificate, | newWithNew CMPCertificate, | |||
| newWithOld [0] CMPCertificate OPTIONAL, | newWithOld [0] CMPCertificate OPTIONAL, | |||
| oldWithNew [1] CMPCertificate OPTIONAL | oldWithNew [1] CMPCertificate OPTIONAL | |||
| } | } | |||
| Note: In contrast to CAKeyUpdAnnContent, this type offers omitting | Note: In contrast to CAKeyUpdAnnContent, this type offers omitting | |||
| newWithOld and oldWithNew in the GenRep message, depending on the | newWithOld and oldWithNew in the GenRep message, depending on the | |||
| needs of the EE. | needs of the EE. | |||
| 2.15. New Section 5.3.19.16 - Certificate Request Template | 2.16. New Section 5.3.19.16 - Certificate Request Template | |||
| The following subsection introduces the PKI general message using id- | The following subsection introduces the PKI general message using id- | |||
| it-certReqTemplate. Details are specified in the Lightweight CMP | it-certReqTemplate. Details are specified in the Lightweight CMP | |||
| Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. | Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. | |||
| Insert this section after new Section 5.3.19.15: | Insert this section after new Section 5.3.19.15: | |||
| 5.3.19.16. Certificate Request Template | 5.3.19.16. Certificate Request Template | |||
| This MAY be used by the client to get a template containing | This MAY be used by the client to get a template containing | |||
| skipping to change at page 16, line 37 ¶ | skipping to change at page 16, line 37 ¶ | |||
| The CertReqTemplateValue contains the prefilled certTemplate to be | The CertReqTemplateValue contains the prefilled certTemplate to be | |||
| used for a future certificate request. The publicKey field in the | used for a future certificate request. The publicKey field in the | |||
| certTemplate MUST NOT be used. In case the PKI management entity | certTemplate MUST NOT be used. In case the PKI management entity | |||
| wishes to specify supported public-key algorithms, the keySpec field | wishes to specify supported public-key algorithms, the keySpec field | |||
| MUST be used. One AttributeTypeAndValue per supported algorithm or | MUST be used. One AttributeTypeAndValue per supported algorithm or | |||
| RSA key length MUST be used. | RSA key length MUST be used. | |||
| Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] | Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] | |||
| 2.16. New Section 5.3.19.17 - CRL update retrieval | 2.17. New Section 5.3.19.17 - CRL Update Retrieval | |||
| The following subsection introduces the PKI general message using id- | The following subsection introduces the PKI general message using id- | |||
| it-crlStatusList and id-it-crls. Details are specified in the | it-crlStatusList and id-it-crls. Details are specified in the | |||
| Lightweight CMP Profile Section 4.3 | Lightweight CMP Profile Section 4.3 | |||
| [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after | [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after | |||
| new Section 5.3.19.16: | new Section 5.3.19.16: | |||
| 5.3.19.17. CRL update retrieval | 5.3.19.17. CRL Update Retrieval | |||
| This MAY be used by the client to get new CRLs, specifying the source | This MAY be used by the client to get new CRLs, specifying the source | |||
| of the CRLs and the thisUpdate value of the latest CRL it already | of the CRLs and the thisUpdate value of the latest CRL it already | |||
| has, if available. A CRL source is given either by a | has, if available. A CRL source is given either by a | |||
| DistributionPointName or the GeneralNames of the issuing CA. The | DistributionPointName or the GeneralNames of the issuing CA. The | |||
| DistributionPointName should be treated as an internal pointer to | DistributionPointName should be treated as an internal pointer to | |||
| identify a CRL that the server already has and not as a way to ask | identify a CRL that the server already has and not as a way to ask | |||
| the server to fetch CRLs from external locations. The server shall | the server to fetch CRLs from external locations. The server shall | |||
| provide only those CRLs that are more recent than the ones indicated | provide only those CRLs that are more recent than the ones indicated | |||
| by the client. | by the client. | |||
| skipping to change at page 17, line 23 ¶ | skipping to change at page 17, line 23 ¶ | |||
| dpn [0] DistributionPointName, | dpn [0] DistributionPointName, | |||
| issuer [1] GeneralNames } | issuer [1] GeneralNames } | |||
| CRLStatus ::= SEQUENCE { | CRLStatus ::= SEQUENCE { | |||
| source CRLSource, | source CRLSource, | |||
| thisUpdate Time OPTIONAL } | thisUpdate Time OPTIONAL } | |||
| < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- | < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- | |||
| crls (TBD2). > | crls (TBD2). > | |||
| 2.17. Update Section 5.3.21 - Error Message Content | 2.18. Update Section 5.3.21 - Error Message Content | |||
| Section 5.3.21 of RFC 4210 [RFC4210] describes the regular use of | Section 5.3.21 of RFC 4210 [RFC4210] describes the regular use of | |||
| error messages. This document adds a use by a PKI management entity | error messages. This document adds a use by a PKI management entity | |||
| to initiate delayed delivery in response to certConf, rr, and genm | to initiate delayed delivery in response to certConf, rr, and genm | |||
| requests and to error messages. | requests and to error messages. | |||
| Replace the first sentence of the first paragraph with the following | Replace the first sentence of the first paragraph with the following | |||
| one: | one: | |||
| This data structure MAY be used by EE, CA, or RA to convey error info | This data structure MAY be used by EE, CA, or RA to convey error info | |||
| skipping to change at page 18, line 5 ¶ | skipping to change at page 18, line 5 ¶ | |||
| This message MAY be generated at any time during a PKI transaction. | This message MAY be generated at any time during a PKI transaction. | |||
| If the client sends this request, the server MUST respond with a | If the client sends this request, the server MUST respond with a | |||
| PKIConfirm response, or another ErrorMsg if any part of the header is | PKIConfirm response, or another ErrorMsg if any part of the header is | |||
| not valid. In case a PKI management entity sends an error message to | not valid. In case a PKI management entity sends an error message to | |||
| the EE with the pKIStatusInfo field containing the status "waiting", | the EE with the pKIStatusInfo field containing the status "waiting", | |||
| the EE will initiate polling as described in Section 5.3.22. | the EE will initiate polling as described in Section 5.3.22. | |||
| Otherwise, both sides MUST treat this message as the end of the | Otherwise, both sides MUST treat this message as the end of the | |||
| transaction (if a transaction is in progress). | transaction (if a transaction is in progress). | |||
| 2.18. Replace Section 5.3.22 - Polling Request and Response | 2.19. Replace Section 5.3.22 - Polling Request and Response | |||
| Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling | Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling | |||
| messages are used for ir, cr, and kur messages. This document | messages are used for ir, cr, and kur messages. This document | |||
| extends the polling mechanism for outstanding responses to any kind | extends the polling mechanism for outstanding responses to any kind | |||
| of request message. This update also fixes the inconsistent use of | of request message. This update also fixes the inconsistent use of | |||
| the terms 'rReq' vs. 'pollReq' and 'pRep' vs. 'pollRep'. | the terms 'rReq' vs. 'pollReq' and 'pRep' vs. 'pollRep'. | |||
| Replace Section 5.3.22 with following text: | Replace Section 5.3.22 with following text: | |||
| This pair of messages is intended to handle scenarios in which the | This pair of messages is intended to handle scenarios in which the | |||
| skipping to change at page 19, line 7 ¶ | skipping to change at page 19, line 7 ¶ | |||
| CertResponse data structure with status "waiting" or -1 referring | CertResponse data structure with status "waiting" or -1 referring | |||
| to the complete response. | to the complete response. | |||
| 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if | 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if | |||
| one or more of still pending requested certificates are ready or | one or more of still pending requested certificates are ready or | |||
| the final response to some other type of request is available; | the final response to some other type of request is available; | |||
| otherwise, it will return a pollRep. | otherwise, it will return a pollRep. | |||
| 3 If the EE receives a pollRep, it will wait for at least the number | 3 If the EE receives a pollRep, it will wait for at least the number | |||
| of seconds given in the checkAfter field before sending another | of seconds given in the checkAfter field before sending another | |||
| pollReq.. | pollReq. | |||
| 4 If the EE receives an ip, cp, or kup, then it will be treated in | 4 If the EE receives an ip, cp, or kup, then it will be treated in | |||
| the same way as the initial response; if it receives any other | the same way as the initial response; if it receives any other | |||
| response, then this will be treated as the final response to the | response, then this will be treated as the final response to the | |||
| original request. | original request. | |||
| The following client-side state machine describes polling for | The following client-side state machine describes polling for | |||
| individual CertResponse elements. | individual CertResponse elements. | |||
| START | START | |||
| skipping to change at page 22, line 30 ¶ | skipping to change at page 22, line 30 ¶ | |||
| 12 <- pollRep <- | 12 <- pollRep <- | |||
| 13 Wait | 13 Wait | |||
| 14 Format pollReq | 14 Format pollReq | |||
| 15 -> pollReq -> | 15 -> pollReq -> | |||
| 16 Check status of original request | 16 Check status of original request | |||
| general message response is ready | general message response is ready | |||
| 17 Format genp | 17 Format genp | |||
| 18 <- genp <- | 18 <- genp <- | |||
| 19 Handle genp | 19 Handle genp | |||
| 2.19. Update Section 7 - Version Negotiation | 2.20. Update Section 7 - Version Negotiation | |||
| Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol | Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol | |||
| versions. This document describes the handling of the additional CMP | versions. This document describes the handling of the additional CMP | |||
| version cmp2021 introduced to indicate support of EnvelopedData and | version cmp2021 introduced to indicate support of EnvelopedData and | |||
| hashAlg. | hashAlg. | |||
| Replace the text of the first three paragraphs with the following | Replace the text of the first three paragraphs with the following | |||
| text: | text: | |||
| This section defines the version negotiation between client and | This section defines the version negotiation between client and | |||
| skipping to change at page 24, line 12 ¶ | skipping to change at page 24, line 12 ¶ | |||
| supports, then it MUST send back an ErrorMsg with the | supports, then it MUST send back an ErrorMsg with the | |||
| unsupportedVersion bit set (in the failureInfo field of the | unsupportedVersion bit set (in the failureInfo field of the | |||
| pKIStatusInfo). If the received version is higher than the highest | pKIStatusInfo). If the received version is higher than the highest | |||
| supported version for this request message, then the version in the | supported version for this request message, then the version in the | |||
| error message MUST be the highest version the server supports for | error message MUST be the highest version the server supports for | |||
| this message type; if the received version is lower than the lowest | this message type; if the received version is lower than the lowest | |||
| supported version for this request message then the version in the | supported version for this request message then the version in the | |||
| error message MUST be the lowest version the server supports for this | error message MUST be the lowest version the server supports for this | |||
| message type. | message type. | |||
| 2.20. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers | 2.21. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers | |||
| Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a | Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a | |||
| client sending a cmp2000 message talking to a cmp1999 server. This | client sending a cmp2000 message talking to a cmp1999 server. This | |||
| document extends the section to clients with any higher version than | document extends the section to clients with any higher version than | |||
| cmp1999. | cmp1999. | |||
| Replace the first sentence of Section 7.1.1 with the following text: | Replace the first sentence of Section 7.1.1 with the following text: | |||
| If, after sending a message with a protocol version number higher | If, after sending a message with a protocol version number higher | |||
| than cmp1999, a client receives an ErrorMsgContent with a version of | than cmp1999, a client receives an ErrorMsgContent with a version of | |||
| cmp1999, then it MUST abort the current transaction. | cmp1999, then it MUST abort the current transaction. | |||
| 2.21. Add Section 8.4 - Private keys for certificate signing and CMP | 2.22. Add Section 8.4 - Private Keys for Certificate Signing and CMP | |||
| message protection | Message Protection | |||
| The following subsection addresses the risk arising from reusing the | The following subsection addresses the risk arising from reusing the | |||
| CA private key for CMP message protection. | CA private key for CMP message protection. | |||
| Insert this section after Section 8.3: | Insert this section after Section 8.3 (Note: This fixes Errata ID | |||
| 5731): | ||||
| 8.4. Private keys for certificate signing and CMP message protection | 8.4. Private Keys for Certificate Signing and CMP Message Protection | |||
| When a CA acts as a CMP endpoint, it should not use the same private | When a CA acts as a CMP endpoint, it should not use the same private | |||
| key for issuing certificates and for protecting CMP responses, to | key for issuing certificates and for protecting CMP responses, to | |||
| reduce the number of usages of the key to the minimum required. | reduce the number of usages of the key to the minimum required. | |||
| 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and | 2.23. Add Section 8.5 - Entropy of Random Numbers, Key Pairs, and | |||
| shared secret information | Shared Secret Information | |||
| The following subsection addresses the risk arising from low entropy | The following subsection addresses the risk arising from low entropy | |||
| of random numbers, asymmetric keys, and shared secret information. | of random numbers, asymmetric keys, and shared secret information. | |||
| 8.5. Entropy of random numbers, key pairs, and shared secret | 8.5. Entropy of Random Numbers, Key Pairs, and Shared Secret | |||
| information | Information | |||
| Implementations must generate nonces and private keys from random | Implementations must generate nonces and private keys from random | |||
| input. The use of inadequate pseudo-random number generators (PRNGs) | input. The use of inadequate pseudo-random number generators (PRNGs) | |||
| to generate cryptographic keys can result in little or no security. | to generate cryptographic keys can result in little or no security. | |||
| An attacker may find it much easier to reproduce the PRNG environment | An attacker may find it much easier to reproduce the PRNG environment | |||
| that produced the keys and to search the resulting small set of | that produced the keys and to search the resulting small set of | |||
| possibilities than brute-force searching the whole key space. As an | possibilities than brute-force searching the whole key space. As an | |||
| example of predictable random numbers see CVE-2008-0166 | example of predictable random numbers see CVE-2008-0166 | |||
| [CVE-2008-0166]; consequences of low-entropy random numbers are | [CVE-2008-0166]; consequences of low-entropy random numbers are | |||
| discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of | discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of | |||
| quality random numbers is difficult. ISO/IEC 20543:2019 | quality random numbers is difficult. ISO/IEC 20543:2019 | |||
| [ISO.20543-2019], NIST SP 800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS | [ISO.20543-2019], NIST SP 800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS | |||
| 31 V2.0 [AIS31], and others offer valuable guidance in this area. | 31 V2.0 [AIS31], and others offer valuable guidance in this area. | |||
| skipping to change at page 25, line 36 ¶ | skipping to change at page 25, line 38 ¶ | |||
| information is re-used for different key pairs, the security of the | information is re-used for different key pairs, the security of the | |||
| shared secret information should exceed the security strength of each | shared secret information should exceed the security strength of each | |||
| key pair. | key pair. | |||
| For the case of a PKI management operation that delivers a new trust | For the case of a PKI management operation that delivers a new trust | |||
| anchor (e.g., a root CA certificate) using caPubs or genm (a) that is | anchor (e.g., a root CA certificate) using caPubs or genm (a) that is | |||
| not concluded in a timely manner or (b) where the shared secret | not concluded in a timely manner or (b) where the shared secret | |||
| information is re-used for several key management operations, the | information is re-used for several key management operations, the | |||
| entropy of the shared secret information, if known, should not be | entropy of the shared secret information, if known, should not be | |||
| less than the security strength of the trust anchor being managed by | less than the security strength of the trust anchor being managed by | |||
| the operation. For other cases it is recommended to (a) use a shared | the operation. The shared secret information should have an entropy | |||
| secret information of possibly low security strength (e.g., a | that at least matches the security strength of the key material being | |||
| password) only for a single PKI management operation or (b) use a | managed by the operation. Certain use cases may require shared | |||
| shared secret information with an entropy that at least matches the | secret information that may be of a low security strength, e.g., a | |||
| security strength of the key material being managed by the operation. | human generated password. It is RECOMMENDED that such secret | |||
| information be limited to a single PKI management operation. | ||||
| 2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages | 2.24. Add Section 8.6 - Trust Anchor Provisioning Using CMP Messages | |||
| The following subsection addresses the risk arising from in-band | The following subsection addresses the risk arising from in-band | |||
| provisioning of new trust anchors in a PKI management operation. | provisioning of new trust anchors in a PKI management operation. | |||
| Insert this section after new Section 8.5: | Insert this section after new Section 8.5: | |||
| 8.6. Trust anchor provisioning using CMP messages | 8.6. Trust Anchor Provisioning Using CMP Messages | |||
| The provider of trust anchors, which typically will be an RA involved | A provider of trust anchors, which may be an RA involved in | |||
| in configuration management of its clients, MUST NOT include to-be- | configuration management of its clients, MUST NOT include to-be- | |||
| trusted CA certificates in a CMP message unless it can take | trusted CA certificates in a CMP message unless the specific | |||
| responsibility for making the recipient trust them. When doing so, | deployment scenario can ensure that it is adequate that the receiving | |||
| it MUST exert the same due diligence as for its own trust anchors. | EE trusts these certificates, e.g., by loading them into its trust | |||
| store. | ||||
| Whenever an EE receives in a CMP message, e.g., in the caPubs field | Whenever an EE receives in a CMP message, e.g., in the caPubs field | |||
| of a certificate response or in a general response (genp), a CA | of a certificate response or in a general response (genp), a CA | |||
| certificate for use as a trust anchor, it MUST properly authenticate | certificate for use as a trust anchor, it MUST properly authenticate | |||
| the message sender without already trusting any of the CA | the message sender without already trusting any of the CA | |||
| certificates given in the message. | certificates given in the message. | |||
| Moreover, the EE MUST verify that the sender is an authorized source | Moreover, the EE MUST verify that the sender is an authorized source | |||
| of trust anchors. This authorization is typically indicated using | of trust anchors. This authorization is governed by local policy and | |||
| shared secret information or with a signature-based message | typically indicated using shared secret information or with a | |||
| protection using a certificate issued by a PKI that is explicitly | signature-based message protection using a certificate issued by a | |||
| authorized for this purpose. | PKI that is explicitly authorized for this purpose. | |||
| 2.24. Update Section 9 - IANA Considerations | 2.25. Update Section 9 - IANA Considerations | |||
| Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of | Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of | |||
| that document. As this document defines a new Extended Key Usage, | that document. As this document defines a new Extended Key Usage, | |||
| the IANA Considerations need to be updated accordingly. | the IANA Considerations need to be updated accordingly. | |||
| Add the following paragraphs after the third paragraph of the | Replace the fourth paragraph of this section with the following text: | |||
| section: | ||||
| In the SMI-numbers registry "SMI Security for PKIX Extended Key | In the SMI-numbers registry "SMI Security for PKIX Extended Key | |||
| Purpose Identifiers (1.3.6.1.5.5.7.3)" (see | Purpose Identifiers (1.3.6.1.5.5.7.3)" (see | |||
| https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- | https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- | |||
| numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one | numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one | |||
| addition has been performed. | addition has been performed. | |||
| One new entry has been added: | One new entry has been added: | |||
| +=========+=============+============+ | +=========+=============+============+ | |||
| | Decimal | Description | References | | | Decimal | Description | References | | |||
| +=========+=============+============+ | +=========+=============+============+ | |||
| | 32 | id-kp-cmKGA | [thisRFC] | | | 32 | id-kp-cmKGA | [thisRFC] | | |||
| +---------+-------------+------------+ | +---------+-------------+------------+ | |||
| Table 1: Addition to the PKIX | Table 1: Addition to the PKIX | |||
| Extended Key Purpose Identifiers | Extended Key Purpose Identifiers | |||
| registry | Registry | |||
| In the SMI-numbers registry "SMI Security for PKIX CMP Information | In the SMI-numbers registry "SMI Security for PKIX CMP Information | |||
| Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- | Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- | |||
| numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in | numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in | |||
| RFC 7299 [RFC7299] seven additions have been performed. | RFC 7299 [RFC7299] seven additions have been performed. | |||
| Seven new entries have been added: | Seven new entries have been added: | |||
| +=========+=======================+============+ | +=========+=======================+============+ | |||
| | Decimal | Description | References | | | Decimal | Description | References | | |||
| skipping to change at page 27, line 31 ¶ | skipping to change at page 27, line 31 ¶ | |||
| | 20 | id-it-rootCaCert | [thisRFC] | | | 20 | id-it-rootCaCert | [thisRFC] | | |||
| +---------+-----------------------+------------+ | +---------+-----------------------+------------+ | |||
| | 21 | id-it-certProfile | [thisRFC] | | | 21 | id-it-certProfile | [thisRFC] | | |||
| +---------+-----------------------+------------+ | +---------+-----------------------+------------+ | |||
| | TBD1 | id-it-crlStatusList | [thisRFC] | | | TBD1 | id-it-crlStatusList | [thisRFC] | | |||
| +---------+-----------------------+------------+ | +---------+-----------------------+------------+ | |||
| | TBD2 | id-it-crls | [thisRFC] | | | TBD2 | id-it-crls | [thisRFC] | | |||
| +---------+-----------------------+------------+ | +---------+-----------------------+------------+ | |||
| Table 2: Addition to the PKIX CMP | Table 2: Addition to the PKIX CMP | |||
| Information Types registry | Information Types Registry | |||
| < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- | < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- | |||
| crls (TBD2). > | crls (TBD2). > | |||
| In the SMI-numbers registry " SMI Security for PKIX CRMF Registration | In the SMI-numbers registry " SMI Security for PKIX CRMF Registration | |||
| Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ | Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ | |||
| smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as | smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as | |||
| defined in RFC 7299 [RFC7299] two additions have been performed. | defined in RFC 7299 [RFC7299] two additions have been performed. | |||
| Two new entries have been added: | Two new entries have been added: | |||
| +=========+======================+============+ | +=========+======================+============+ | |||
| | Decimal | Description | References | | | Decimal | Description | References | | |||
| +=========+======================+============+ | +=========+======================+============+ | |||
| | 11 | id-regCtrl-algId | [thisRFC] | | | 11 | id-regCtrl-algId | [thisRFC] | | |||
| +---------+----------------------+------------+ | +---------+----------------------+------------+ | |||
| | 12 | id-regCtrl-rsaKeyLen | [thisRFC] | | | 12 | id-regCtrl-rsaKeyLen | [thisRFC] | | |||
| +---------+----------------------+------------+ | +---------+----------------------+------------+ | |||
| Table 3: Addition to the PKIX CRMF | Table 3: Addition to the PKIX CRMF | |||
| Registration Controls registry | Registration Controls Registry | |||
| 2.25. Update Appendix B - The Use of Revocation Passphrase | 2.26. Update Appendix B - The Use of Revocation Passphrase | |||
| Appendix B of RFC 4210 [RFC4210] describes the use of the revocation | Appendix B of RFC 4210 [RFC4210] describes the use of the revocation | |||
| passphrase. As this document updates RFC 4210 [RFC4210] to utilize | passphrase. As this document updates RFC 4210 [RFC4210] to utilize | |||
| the parent structure EncryptedKey instead of EncryptedValue as | the parent structure EncryptedKey instead of EncryptedValue as | |||
| described in Section 2.7 above, the description is updated | described in Section 2.7 above, the description is updated | |||
| accordingly. | accordingly. | |||
| Replace the first bullet point of this section with the following | Replace the first bullet point of this section with the following | |||
| text: | text: | |||
| * The OID and value specified in Section 5.3.19.9 MAY be sent in a | * The OID and value specified in Section 5.3.19.9 MAY be sent in a | |||
| GenMsg message at any time, or MAY be sent in the generalInfo | GenMsg message at any time, or MAY be sent in the generalInfo | |||
| field of the PKIHeader of any PKIMessage at any time. (In | field of the PKIHeader of any PKIMessage at any time. (In | |||
| particular, the EncryptedKey structure as described in section | particular, the EncryptedKey structure as described in section | |||
| 5.2.2 may be sent in the header of the certConf message that | 5.2.2 may be sent in the header of the certConf message that | |||
| confirms acceptance of certificates requested in an initialization | confirms acceptance of certificates requested in an initialization | |||
| request or certificate request message.) This conveys a | request or certificate request message.) This conveys a | |||
| revocation passphrase chosen by the entity to the relevant CA/RA. | revocation passphrase chosen by the entity to the relevant CA/RA. | |||
| For use of EnvelopedData this is in the decrypted bytes of | When EnvelopedData is used, this is in the decrypted bytes of | |||
| encryptedContent field and for use of EncryptedValue this is in | encryptedContent field. When EncryptedValue is used, this is in | |||
| the decrypted bytes of the encValue field. Furthermore, the | the decrypted bytes of the encValue field. Furthermore, the | |||
| transfer is accomplished with appropriate confidentiality | transfer is accomplished with appropriate confidentiality | |||
| characteristics. | characteristics. | |||
| Replace the third bullet point of this section with the following | Replace the third bullet point of this section with the following | |||
| text: | text: | |||
| * When using EnvelopedData the localKeyId attribute as specified in | * Either the localKeyId attribute of EnvelopedData as specified in | |||
| RFC 2985 [RFC2985] and when using EncryptedValue the valueHint | RFC 2985 [RFC2985] or the valueHint field of EncryptedValue MAY | |||
| field MAY contain a key identifier (chosen by the entity, along | contain a key identifier (chosen by the entity, along with the | |||
| with the passphrase itself) to assist in later retrieval of the | passphrase itself) to assist in later retrieval of the correct | |||
| correct passphrase (e.g., when the revocation request is | passphrase (e.g., when the revocation request is constructed by | |||
| constructed by the entity and received by the CA/RA). | the entity and received by the CA/RA). | |||
| 2.26. Update Appendix C - Request Message Behavioral Clarifications | 2.27. Update Appendix C - Request Message Behavioral Clarifications | |||
| Appendix C of RFC 4210 [RFC4210] provides clarifications to the | Appendix C of RFC 4210 [RFC4210] provides clarifications to the | |||
| request message behavior. As this document updates RFC 4210 | request message behavior. As this document updates RFC 4210 | |||
| [RFC4210] to utilize the parent structure EncryptedKey instead of | [RFC4210] to utilize the parent structure EncryptedKey instead of | |||
| EncryptedValue as described in Section 2.7 above, the description is | EncryptedValue as described in Section 2.7 above, the description is | |||
| updated accordingly. | updated accordingly. | |||
| Replace the comment within the ASN.1 syntax coming after the | Replace the comment within the ASN.1 syntax coming after the | |||
| definition of POPOSigningKey with the following text (Note: This | definition of POPOSigningKey with the following text (Note: This | |||
| fixes Errata ID 2615): | fixes Errata ID 2615): | |||
| skipping to change at page 29, line 40 ¶ | skipping to change at page 29, line 40 ¶ | |||
| -- * Section 5.2.2 of this specification). Therefore, this | -- * Section 5.2.2 of this specification). Therefore, this | |||
| -- * document makes the behavioral clarification of specifying | -- * document makes the behavioral clarification of specifying | |||
| -- * that the contents of "thisMessage" MUST be encoded either as | -- * that the contents of "thisMessage" MUST be encoded either as | |||
| -- * "EnvelopedData" or "EncryptedValue" (only for backward | -- * "EnvelopedData" or "EncryptedValue" (only for backward | |||
| -- * compatibility) and then wrapped in a BIT STRING. This | -- * compatibility) and then wrapped in a BIT STRING. This | |||
| -- * allows the necessary conveyance and protection of the | -- * allows the necessary conveyance and protection of the | |||
| -- * private key while maintaining bits-on-the-wire compatibility | -- * private key while maintaining bits-on-the-wire compatibility | |||
| -- * with RFC 4211 [RFC4211]. | -- * with RFC 4211 [RFC4211]. | |||
| -- ********** | -- ********** | |||
| 2.27. Update Appendix D.1. - General Rules for Interpretation of These | 2.28. Update Appendix D.1. - General Rules for Interpretation of These | |||
| Profiles | Profiles | |||
| Appendix D.1 of RFC 4210 [RFC4210] provides general rules for | Appendix D.1 of RFC 4210 [RFC4210] provides general rules for | |||
| interpretation of the PKI management messages profiles specified in | interpretation of the PKI management messages profiles specified in | |||
| Appendix D and Appendix E of RFC 4210 [RFC4210]. This document | Appendix D and Appendix E of RFC 4210 [RFC4210]. This document | |||
| updates a sentence regarding the new protocol version cmp2021. | updates a sentence regarding the new protocol version cmp2021. | |||
| Replace the last sentence of the first paragraph of the section with | Replace the last sentence of the first paragraph of the section with | |||
| the following text: | the following text: | |||
| Mandatory fields are not mentioned if they have an obvious value | Mandatory fields are not mentioned if they have an obvious value | |||
| (e.g., in this version of these profiles, pvno is always cmp2000). | (e.g., in this version of these profiles, pvno is always cmp2000). | |||
| 2.28. Update Appendix D.2. - Algorithm Use Profile | 2.29. Update Appendix D.2. - Algorithm Use Profile | |||
| Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that | Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that | |||
| implementations must support when claiming conformance with PKI | implementations must support when claiming conformance with PKI | |||
| Management Message Profiles as specified in CMP Appendix D.2 | Management Message Profiles as specified in CMP Appendix D.2 | |||
| [RFC4210]. This document redirects to the new algorithm profile as | [RFC4210]. This document redirects to the new algorithm profile as | |||
| specified in Appendix A.1 of CMP Algorithms | specified in Appendix A.1 of CMP Algorithms | |||
| [I-D.ietf-lamps-cmp-algorithms]. | [I-D.ietf-lamps-cmp-algorithms]. | |||
| Replace the text of the section with the following text: | Replace the text of the section with the following text: | |||
| D.2. Algorithm Use Profile | D.2. Algorithm Use Profile | |||
| For specifications of algorithm identifiers and respective | For specifications of algorithm identifiers and respective | |||
| conventions for conforming implementations, please refer to CMP | conventions for conforming implementations, please refer to CMP | |||
| Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. | Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. | |||
| 2.29. Update Appendix D.4. - Initial Registration/Certification (Basic | 2.30. Update Appendix D.4. - Initial Registration/Certification (Basic | |||
| Authenticated Scheme) | Authenticated Scheme) | |||
| Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ | Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ | |||
| certification scheme. This scheme shall continue using | certification scheme. This scheme shall continue using | |||
| EncryptedValue for backward compatibility reasons. | EncryptedValue for backward compatibility reasons. | |||
| Replace the line specifying protectionAlg of the Initialization | Replace the line specifying protectionAlg of the Initialization | |||
| Response message with the following text (Note: This fixes Errata ID | Response message with the following text (Note: This fixes Errata ID | |||
| 5201): | 5201): | |||
| skipping to change at page 31, line 14 ¶ | skipping to change at page 31, line 14 ¶ | |||
| In addition to reliable transport, CMP requires connection and error | In addition to reliable transport, CMP requires connection and error | |||
| handling from the transfer protocol, which is all covered by HTTP. | handling from the transfer protocol, which is all covered by HTTP. | |||
| Moreover, delayed delivery of CMP response messages may be handled at | Moreover, delayed delivery of CMP response messages may be handled at | |||
| transfer level regardless of the message contents. Since CMP Updates | transfer level regardless of the message contents. Since CMP Updates | |||
| [thisRFC] extends the polling mechanism specified in the second | [thisRFC] extends the polling mechanism specified in the second | |||
| version of CMP [RFC4210] to cover all types of PKI management | version of CMP [RFC4210] to cover all types of PKI management | |||
| transactions, delays detected at application level may also be | transactions, delays detected at application level may also be | |||
| handled within CMP, using pollReq and pollReq messages. | handled within CMP, using pollReq and pollReq messages. | |||
| 3.2. New Section 1.1. - Changes since RFC 6712 | 3.2. New Section 1.1. - Changes Since RFC 6712 | |||
| The following subsection describes feature updates to RFC 6712 | The following subsection describes feature updates to RFC 6712 | |||
| [RFC6712]. They are related to the base specification. Hence | [RFC6712]. They are related to the base specification. Hence | |||
| references to the original sections in RFC 6712 [RFC6712] are used | references to the original sections in RFC 6712 [RFC6712] are used | |||
| whenever possible. | whenever possible. | |||
| Insert this section at the end of the current Section 1: | Insert this section at the end of the current Section 1: | |||
| 1.1 Changes since RFC 6712 | 1.1 Changes Since RFC 6712 | |||
| The following updates are made in [thisRFC]: | The following updates are made in [thisRFC]: | |||
| * Introduce the HTTP path '/.well-known/cmp'. | * Introduce the HTTP path '/.well-known/cmp'. | |||
| * Extend the URI structure. | * Extend the URI structure. | |||
| 3.3. Replace Section 3.6. - HTTP Request-URI | 3.3. Replace Section 3.6. - HTTP Request-URI | |||
| Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This | Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This | |||
| skipping to change at page 31, line 51 ¶ | skipping to change at page 31, line 51 ¶ | |||
| Each CMP server on a PKI management entity supporting HTTP or HTTPS | Each CMP server on a PKI management entity supporting HTTP or HTTPS | |||
| transfer MUST support the use of the path prefix '/.well-known/' as | transfer MUST support the use of the path prefix '/.well-known/' as | |||
| defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease | defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease | |||
| interworking in a multi-vendor environment. | interworking in a multi-vendor environment. | |||
| The CMP client needs to be configured with sufficient information to | The CMP client needs to be configured with sufficient information to | |||
| form the CMP server URI. This is at least the authority portion of | form the CMP server URI. This is at least the authority portion of | |||
| the URI, e.g., 'www.example.com:80', or the full operation path | the URI, e.g., 'www.example.com:80', or the full operation path | |||
| segment of the PKI management entity. Additionally, OPTIONAL path | segment of the PKI management entity. Additionally, OPTIONAL path | |||
| segments MAY be added after the registered application name as part | segments MAY be added after the registered application name as part | |||
| of the full operation path to provide further distinction. A path | of the full operation path to provide further distinction. The path | |||
| segment could for example support the differentiation of specific | segment 'p' followed by an arbitraryLabel <name> could for example | |||
| CAs, certificate profiles, or PKI management operations. A valid | support the differentiation of specific CAs or certificate profiles. | |||
| full CMP path can look like this: | Further path segments, e.g., as specified in the Lightweight CMP | |||
| Profile [I-D.ietf-lamps-lightweight-cmp-profile], could indicate PKI | ||||
| management operations using an operationLabel <operation>. A valid | ||||
| full CMP URI can look like this: | ||||
| http://www.example.com/.well-known/cmp | http://www.example.com/.well-known/cmp | |||
| http://www.example.com/.well-known/cmp/operationLabel | http://www.example.com/.well-known/cmp/<operation> | |||
| http://www.example.com/.well-known/cmp/profileLabel | http://www.example.com/.well-known/cmp/p/<name> | |||
| http://www.example.com/.well-known/cmp/profileLabel/operationLabel | http://www.example.com/.well-known/cmp/p/<name>/<operation> | |||
| 3.4. Update Section 6. - IANA Considerations | 3.4. Update Section 6. - IANA Considerations | |||
| Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of | Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of | |||
| that document. As this document defines a new '.well-known' URI | that document. As this document defines a new well-known URI suffix, | |||
| prefix, the IANA Considerations need to be updated accordingly. | the IANA Considerations need to be updated accordingly. | |||
| Add the following text between the first and second paragraph of the | Replace the second paragraph of this section with the following text: | |||
| section: | ||||
| In the registry of well-known URIs (see | 6.1. Well-Known URI Registration | |||
| https://www.iana.org/assignments/well-known-uris/well-known- | ||||
| uris.xhtml#well-known-uris-1) as defined in RFC 8615 [RFC8615] the | ||||
| following change has been performed. | ||||
| One new name entry has been added: | This document defines a new entry with the following content in the | |||
| "Well-Known URIs" registry (see https://www.iana.org/assignments/ | ||||
| well-known-uris/) as defined in RFC 8615 [RFC8615]. | ||||
| +============+===================+============+ | URI Suffix: cmp | |||
| | URI suffix | Change controller | References | | Change Controller: IETF | |||
| +============+===================+============+ | References: [thisRFC] [I-D.ietf-ace-cmpv2-coap-transport] | |||
| | cmp | IETF | [thisRFC] | | Related Information: CMP has a sub-registry at | |||
| +------------+-------------------+------------+ | [https://www.iana.org/assignments/cmp/] | |||
| Table 4: Addition to the well-known URI | 6.2. CMP Well-Known URI Registry | |||
| registry | ||||
| This document defines a new protocol registry group entitled | ||||
| "Certificate Management Protocol (CMP)" (at | ||||
| https://www.iana.org/assignments/cmp/) with a new registry "CMP Well- | ||||
| Known URI Path Segments" containing three columns: Path Segment, | ||||
| Description, and Reference. New items can be added using the | ||||
| Specification Required RFC 8615 [RFC8615] process. The initial | ||||
| contents of this registry is: | ||||
| Path Segment: p | ||||
| Description: Indicates that the next path segment specifies, e.g., | ||||
| a CA or certificate profile name | ||||
| References: [thisRFC] [I-D.ietf-ace-cmpv2-coap-transport] | ||||
| 4. IANA Considerations | 4. IANA Considerations | |||
| This document contains an update to the IANA Consideration sections | This document contains an update to the IANA Consideration sections | |||
| to be added to [RFC4210] and [RFC6712]. | to be added to [RFC4210] and [RFC6712]. | |||
| This document updates the ASN.1 modules of RFC 4210 Appendix F | This document updates the ASN.1 modules of RFC 4210 Appendix F | |||
| [RFC4210] and RFC 5912 Section 9 [RFC5912]. The OIDs 99 (id-mod- | [RFC4210] and RFC 5912 Section 9 [RFC5912]. The OIDs 99 (id-mod- | |||
| cmp2021-88) and 100 (id-mod-cmp2021-02) were registered in the SMI | cmp2021-88) and 100 (id-mod-cmp2021-02) were registered in the SMI | |||
| Security for PKIX Module Identifier registry to identify the updated | Security for PKIX Module Identifier registry to identify the updated | |||
| ASN.1 modules. | ASN.1 modules. | |||
| < TBD: The temporary registration of cmp URI suffix expires | < TBD: The temporary registration of cmp URI suffix expires | |||
| 2022-05-20. The registration must be extended in time or update from | 2022-05-20. The registration must be extended in time or update from | |||
| provisional to permanent. > | provisional to permanent. > | |||
| < TBD: New protocol registry group "Certificate Management Protocol | ||||
| (CMP)" (at https://www.iana.org/assignments/cmp) and new registry | ||||
| "CMP Well-Known URI Path Segments" with the initial entry 'p' must be | ||||
| registered at IANA. > | ||||
| 5. Security Considerations | 5. Security Considerations | |||
| The security considerations of RFC 4210 [RFC4210] are extended in | The security considerations of RFC 4210 [RFC4210] are extended in | |||
| Section 2.21 to Section 2.23. No changes are made to the existing | Section 2.22 to Section 2.24. No changes are made to the existing | |||
| security considerations of RFC 6712 [RFC6712]. | security considerations of RFC 6712 [RFC6712]. | |||
| 6. Acknowledgements | 6. Acknowledgements | |||
| Special thank goes to Jim Schaad for his guidance and the inspiration | Special thank goes to Jim Schaad for his guidance and the inspiration | |||
| on structuring and writing this document we got from [RFC6402] which | on structuring and writing this document we got from [RFC6402] which | |||
| updates CMC. Special thank also goes also to Russ Housley, Lijun | updates CMC. Special thank also goes also to Russ Housley, Lijun | |||
| Liao, Martin Peylo, and Tomas Gustavsson for reviewing and providing | Liao, Martin Peylo, and Tomas Gustavsson for reviewing and providing | |||
| valuable suggestions on improving this document. | valuable suggestions on improving this document. | |||
| We also thank all reviewers of this document for their valuable | We also thank all reviewers of this document for their valuable | |||
| feedback. | feedback. | |||
| 7. References | 7. References | |||
| 7.1. Normative References | 7.1. Normative References | |||
| [I-D.ietf-ace-cmpv2-coap-transport] | ||||
| Sahni, M. and S. Tripathi, "CoAP Transfer for the | ||||
| Certificate Management Protocol", Work in Progress, | ||||
| Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 | ||||
| November 2021, <https://datatracker.ietf.org/doc/html/ | ||||
| draft-ietf-ace-cmpv2-coap-transport-04>. | ||||
| [I-D.ietf-lamps-cmp-algorithms] | [I-D.ietf-lamps-cmp-algorithms] | |||
| Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, | Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, | |||
| "Certificate Management Protocol (CMP) Algorithms", Work | "Certificate Management Protocol (CMP) Algorithms", Work | |||
| in Progress, Internet-Draft, draft-ietf-lamps-cmp- | in Progress, Internet-Draft, draft-ietf-lamps-cmp- | |||
| algorithms-09, 22 December 2021, | algorithms-12, 6 April 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- | <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- | |||
| cmp-algorithms-09>. | cmp-algorithms-12>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key | [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key | |||
| Infrastructure Certificate Management Protocols", | Infrastructure Certificate Management Protocols", | |||
| RFC 2510, DOI 10.17487/RFC2510, March 1999, | RFC 2510, DOI 10.17487/RFC2510, March 1999, | |||
| <https://www.rfc-editor.org/info/rfc2510>. | <https://www.rfc-editor.org/info/rfc2510>. | |||
| skipping to change at page 35, line 43 ¶ | skipping to change at page 36, line 22 ¶ | |||
| [CVE-2008-0166] | [CVE-2008-0166] | |||
| National Institute of Science and Technology (NIST), | National Institute of Science and Technology (NIST), | |||
| "National Vulnerability Database - CVE-2008-0166", 13 May | "National Vulnerability Database - CVE-2008-0166", 13 May | |||
| 2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>. | 2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>. | |||
| [I-D.ietf-lamps-lightweight-cmp-profile] | [I-D.ietf-lamps-lightweight-cmp-profile] | |||
| Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight | Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight | |||
| Certificate Management Protocol (CMP) Profile", Work in | Certificate Management Protocol (CMP) Profile", Work in | |||
| Progress, Internet-Draft, draft-ietf-lamps-lightweight- | Progress, Internet-Draft, draft-ietf-lamps-lightweight- | |||
| cmp-profile-09, 17 December 2021, | cmp-profile-10, 1 February 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- | <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- | |||
| lightweight-cmp-profile-09>. | lightweight-cmp-profile-10>. | |||
| [IEEE.802.1AR_2018] | [IEEE.802.1AR_2018] | |||
| IEEE, "IEEE Standard for Local and metropolitan area | IEEE, "IEEE Standard for Local and metropolitan area | |||
| networks - Secure Device Identity", IEEE 802.1AR-2018, | networks - Secure Device Identity", IEEE 802.1AR-2018, | |||
| DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, | DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, | |||
| <https://ieeexplore.ieee.org/document/8423794>. | <https://ieeexplore.ieee.org/document/8423794>. | |||
| [ISO.20543-2019] | [ISO.20543-2019] | |||
| International Organization for Standardization (ISO), | International Organization for Standardization (ISO), | |||
| "Information technology -- Security techniques -- Test and | "Information technology -- Security techniques -- Test and | |||
| skipping to change at page 64, line 5 ¶ | skipping to change at page 64, line 34 ¶ | |||
| -- The EKUs for the CA and RA are reused from CMC as defined in | -- The EKUs for the CA and RA are reused from CMC as defined in | |||
| -- [RFC6402] | -- [RFC6402] | |||
| -- | -- | |||
| -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } | -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } | |||
| -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } | -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } | |||
| id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } | id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } | |||
| END | END | |||
| Appendix B. History of changes | Appendix B. History of Changes | |||
| Note: This appendix will be deleted in the final version of the | Note: This appendix will be deleted in the final version of the | |||
| document. | document. | |||
| From version 17 -> 18: | ||||
| * Addressed comments from AD Evaluation (see thread "AD Review of | ||||
| draft-ietf-lamps-cmp-updates-17") | ||||
| * Added Section 2.8 to clarify on the usage of GeneralizedTime (see | ||||
| thread "draft-ietf-lamps-cmp-updates: fractional seconds") | ||||
| * Updated Section 3.4 introducing the path segment 'p' to indicate | ||||
| the following arbitrary label according to the discussion during | ||||
| IETF 113 (see thread "/.well-known/brski reference to brski- | ||||
| registry") | ||||
| * Capitalized all headlines | ||||
| From version 16 -> 17: | From version 16 -> 17: | |||
| * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors | * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors | |||
| granted BCP78 rights to the IETF Trust | granted BCP78 rights to the IETF Trust | |||
| * Removed note on usage of language tags in UTF8String due to | * Removed note on usage of language tags in UTF8String due to | |||
| reference to references to outdated/historic RFCs | reference to references to outdated/historic RFCs | |||
| * Resolved some nits reported by I-D nit checker tool | * Resolved some nits reported by I-D nit checker tool | |||
| From version 15 -> 16: | From version 15 -> 16: | |||
| skipping to change at page 67, line 4 ¶ | skipping to change at page 67, line 48 ¶ | |||
| "Mail regarding draft-ietf-lamps-cmp-updates"). | "Mail regarding draft-ietf-lamps-cmp-updates"). | |||
| * Added Section 2.4 to refer to draft-ietf-lamps-crmf-update-algs | * Added Section 2.4 to refer to draft-ietf-lamps-crmf-update-algs | |||
| for the update of id-PasswordBasedMac for PKI message protection | for the update of id-PasswordBasedMac for PKI message protection | |||
| using passwords or shared secrets. | using passwords or shared secrets. | |||
| * Updated Section 2.6 to introduce the protocol version number 3 to | * Updated Section 2.6 to introduce the protocol version number 3 to | |||
| properly indicate support of EnvelopedData instead of | properly indicate support of EnvelopedData instead of | |||
| EncryptedValue in case a transaction requires use of EnvelopedData | EncryptedValue in case a transaction requires use of EnvelopedData | |||
| (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). | (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). | |||
| * Update Section 2.14 to make the minimal changes to the respective | * Update Section 2.14 to make the minimal changes to the respective | |||
| section in CMP more explicit. | section in CMP more explicit. | |||
| * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol | * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol | |||
| version in Section 7 Version Negotiation. | version in Section 7 Version Negotiation. | |||
| * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- | * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- | |||
| regCtrl-rsaKeyLen for registration at IANA. | regCtrl-rsaKeyLen for registration at IANA. | |||
| * Added Section 2.20 to update the general rules of interpretation | * Added Section 2.20 to update the general rules of interpretation | |||
| in Appendix D.1 regarding the new cmp2021 version. | in Appendix D.1 regarding the new cmp2021 version. | |||
| * Added Section 2.21 to update the Algorithm Use Profile in | * Added Section 2.21 to update the Algorithm Use Profile in | |||
| Appendix D.2 with the reference to the new CMP Algorithms document | Appendix D.2 with the reference to the new CMP Algorithms document | |||
| as decided at IETF 108. | as decided at IETF 108. | |||
| * Updates Section 3.1 to delete the description of a discovery | * Updates Section 3.1 to delete the description of a discovery | |||
| mechanism as decided at IETF 108. | mechanism as decided at IETF 108. | |||
| * Various changes and corrections in wording. | * Various changes and corrections in wording. | |||
| From version 05 -> 06: | From version 05 -> 06: | |||
| * Added the update of Appendix D.2 with the reference to the new CMP | * Added the update of Appendix D.2 with the reference to the new CMP | |||
| Algorithms document as decided in IETF 108 | Algorithms document as decided in IETF 108 | |||
| * Updated the IANA considerations to register new OIDs for id- | * Updated the IANA considerations to register new OIDs for id- | |||
| regCtrl-algId and d-regCtrl-rsaKeyLen. | regCtrl-algId and d-regCtrl-rsaKeyLen. | |||
| * Minor changes and corrections | * Minor changes and corrections | |||
| From version 04 -> 05: | From version 04 -> 05: | |||
| * Added Section 2.10 and Section 2.11 to clarify the usage of these | * Added Section 2.11 and Section 2.12 to clarify the usage of these | |||
| general messages types with EC curves (see thread | general messages types with EC curves (see thread | |||
| "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue | "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue | |||
| in CMP headers") | in CMP headers") | |||
| * Split former section 2.7 on adding 'CA Certificates', 'Root CA | * Split former section 2.7 on adding 'CA Certificates', 'Root CA | |||
| Certificates Update', and 'Certificate Request Template' in three | Certificates Update', and 'Certificate Request Template' in three | |||
| separate sections for easier readability | separate sections for easier readability | |||
| * Changed in Section 2.14 the ASN.1 syntax of CertReqTemplateValue | * Changed in Section 2.15 the ASN.1 syntax of CertReqTemplateValue | |||
| from using rsaKeyLen to usage of controls as specified in CRMF | from using rsaKeyLen to usage of controls as specified in CRMF | |||
| Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and | Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and | |||
| rsaKeyLen") | rsaKeyLen") | |||
| * Updated the IANA considerations in Section 2.24 to introduce new | * Updated the IANA considerations in Section 2.25 to introduce new | |||
| OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread | OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread | |||
| "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") | "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") | |||
| * Updated the IANA Considerations in and the Appendixes to introduce | * Updated the IANA Considerations in and the Appendixes to introduce | |||
| new OID for the updates ASN.1 modules (see thread "I-D Action: | new OID for the updates ASN.1 modules (see thread "I-D Action: | |||
| draft-ietf-lamps-cmp-updates-04.txt") | draft-ietf-lamps-cmp-updates-04.txt") | |||
| * Removed EncryptedValue from and added Controls to the list of | * Removed EncryptedValue from and added Controls to the list of | |||
| types imported from CRMF [RFC4211] in ASN.1 modules (see thread | types imported from CRMF [RFC4211] in ASN.1 modules (see thread | |||
| "draft-ietf-lamps-cmp-updates and the ASN.1 modules") | "draft-ietf-lamps-cmp-updates and the ASN.1 modules") | |||
| * Moved declaration of Rand out of the comment in ASN.1 modules (see | * Moved declaration of Rand out of the comment in ASN.1 modules (see | |||
| thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") | thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") | |||
| * Minor changes and corrections | * Minor changes and corrections | |||
| From version 03 -> 04: | From version 03 -> 04: | |||
| * Added Section 2.7 to introduce three new id-it IDs for uses in | * Added Section 2.7 to introduce three new id-it IDs for uses in | |||
| general messages as discussed (see thread "draft-ietf-lamps-cmp- | general messages as discussed (see thread "draft-ietf-lamps-cmp- | |||
| updates add section to introduce id-it-caCerts, id-it- | updates add section to introduce id-it-caCerts, id-it- | |||
| rootCaKeyUpdate, and id-it-certReqTemplate") | rootCaKeyUpdate, and id-it-certReqTemplate") | |||
| * Added the new id-it IDs and the /.well-known/cmp to the IANA | * Added the new id-it IDs and the /.well-known/cmp to the IANA | |||
| Considerations of [RFC4210] in Section 2.9 | Considerations of [RFC4210] in Section 2.9 | |||
| * Updated the IANA Considerations of [RFC4210] in Section 2.25 | * Updated the IANA Considerations of [RFC4210] in Section 2.26 | |||
| * Some changes in wording on Section 3 due to review comments from | * Some changes in wording on Section 3 due to review comments from | |||
| Martin Peylo | Martin Peylo | |||
| From version 02 -> 03: | From version 02 -> 03: | |||
| * Added a ToDo on aligning with the CMP Algorithms draft that will | * Added a ToDo on aligning with the CMP Algorithms draft that will | |||
| be set up as decided in IETF 108 | be set up as decided in IETF 108 | |||
| * Updated section on Encrypted Values in Section 2.7 to add the | * Updated section on Encrypted Values in Section 2.7 to add the | |||
| AsymmetricKey Package structure to transport a newly generated | AsymmetricKey Package structure to transport a newly generated | |||
| private key as decided in IETF 108 | private key as decided in IETF 108 | |||
| * Updated the IANA Considerations of [RFC4210] in Section 2.25 | * Updated the IANA Considerations of [RFC4210] in Section 2.26 | |||
| * Added the pre-registered OID in Section 2.25 and the ASN.1 module | * Added the pre-registered OID in Section 2.26 and the ASN.1 module | |||
| * Added Section 3 to document the changes to RFC 6712 [RFC6712] | * Added Section 3 to document the changes to RFC 6712 [RFC6712] | |||
| regarding URI discovery and using the path-prefix of '/.well- | regarding URI discovery and using the path-prefix of '/.well- | |||
| known/' as discussed in IETF 108 | known/' as discussed in IETF 108 | |||
| * Updated the IANA Considerations section | * Updated the IANA Considerations section | |||
| * Added a complete updated ASN.1 module in 1988 syntax to update | * Added a complete updated ASN.1 module in 1988 syntax to update | |||
| Appendix F of [RFC4210] and a complete updated ASN.1 module in | Appendix F of [RFC4210] and a complete updated ASN.1 module in | |||
| 2002 syntax to update Section 9 of [RFC5912] | 2002 syntax to update Section 9 of [RFC5912] | |||
| * Minor changes in wording | * Minor changes in wording | |||
| From version 01 -> 02: | From version 01 -> 02: | |||
| * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 | * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 | |||
| * Changed from symmetric key-encryption to password-based key | * Changed from symmetric key-encryption to password-based key | |||
| management technique in Section 2.7 as discussed with Russ and Jim | management technique in Section 2.7 as discussed with Russ and Jim | |||
| on the mailing list | on the mailing list | |||
| * Defined the attribute containing the key identifier for the | * Defined the attribute containing the key identifier for the | |||
| revocation passphrase in Section 2.25 | revocation passphrase in Section 2.26 | |||
| * Moved the change history to the Appendix | * Moved the change history to the Appendix | |||
| From version 00 -> 01: | From version 00 -> 01: | |||
| * Minor changes in wording | * Minor changes in wording | |||
| From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- | From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- | |||
| updates-00: | updates-00: | |||
| * Changes required to reflect WG adoption | * Changes required to reflect WG adoption | |||
| End of changes. 89 change blocks. | ||||
| 163 lines changed or deleted | 221 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/ | ||||