--- 1/draft-ietf-lamps-lightweight-cmp-profile-11.txt 2022-05-13 05:13:14.492477503 -0700 +++ 2/draft-ietf-lamps-lightweight-cmp-profile-12.txt 2022-05-13 05:13:14.680482245 -0700 @@ -1,19 +1,19 @@ LAMPS Working Group H. Brockhaus, Ed. Internet-Draft D. von Oheimb Intended status: Standards Track S. Fries -Expires: 17 October 2022 Siemens - 15 April 2022 +Expires: 14 November 2022 Siemens + 13 May 2022 Lightweight Certificate Management Protocol (CMP) Profile - draft-ietf-lamps-lightweight-cmp-profile-11 + draft-ietf-lamps-lightweight-cmp-profile-12 Abstract This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 17 October 2022. + This Internet-Draft will expire on 14 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -81,21 +81,21 @@ 3.6.4. PKIStatusInfo and Error Messages . . . . . . . . . . 23 4. PKI Management Operations . . . . . . . . . . . . . . . . . . 25 4.1. Enrolling End Entities . . . . . . . . . . . . . . . . . 27 4.1.1. Enrolling an End Entity to a New PKI . . . . . . . . 28 4.1.2. Enrolling an End Entity to a Known PKI . . . . . . . 34 4.1.3. Updating a Valid Certificate . . . . . . . . . . . . 35 4.1.4. Enrolling an End Entity Using a PKCS#10 Request . . . 36 4.1.5. Using MAC-Based Protection for Enrollment . . . . . . 38 4.1.6. Adding Central Key Pair Generation to Enrollment . . 39 4.1.6.1. Using Key Agreement Key Management Technique . . 45 - 4.1.6.2. Using Key Transport Key Managemen Technique . . . 46 + 4.1.6.2. Using Key Transport Key Management Technique . . 46 4.1.6.3. Using Password-Based Key Management Technique . . 47 4.2. Revoking a Certificate . . . . . . . . . . . . . . . . . 48 4.3. Support Messages . . . . . . . . . . . . . . . . . . . . 50 4.3.1. Get CA Certificates . . . . . . . . . . . . . . . . . 53 4.3.2. Get Root CA Certificate Update . . . . . . . . . . . 53 4.3.3. Get Certificate Request Template . . . . . . . . . . 55 4.3.4. CRL Update Retrieval . . . . . . . . . . . . . . . . 57 4.4. Handling Delayed Delivery . . . . . . . . . . . . . . . . 59 5. PKI Management Entity Operations . . . . . . . . . . . . . . 64 5.1. Responding to Requests . . . . . . . . . . . . . . . . . 64 @@ -111,21 +111,21 @@ 5.2.2.2. Batching Messages . . . . . . . . . . . . . . . . 71 5.2.3. Replacing Protection . . . . . . . . . . . . . . . . 73 5.2.3.1. Not Changing Proof-of-Possession . . . . . . . . 73 5.2.3.2. Using raVerified . . . . . . . . . . . . . . . . 74 5.3. Acting on Behalf of other PKI Entities . . . . . . . . . 74 5.3.1. Requesting a Certificate . . . . . . . . . . . . . . 75 5.3.2. Revoking a Certificate . . . . . . . . . . . . . . . 75 6. CMP Message Transfer Mechanisms . . . . . . . . . . . . . . . 76 6.1. HTTP Transfer . . . . . . . . . . . . . . . . . . . . . . 77 6.2. CoAP Transfer . . . . . . . . . . . . . . . . . . . . . . 79 - 6.3. Piggybacking on other Reliable Transfer . . . . . . . . . 81 + 6.3. Piggybacking on Other Reliable Transfer . . . . . . . . . 81 6.4. Offline Transfer . . . . . . . . . . . . . . . . . . . . 81 6.4.1. File-Based Transfer . . . . . . . . . . . . . . . . . 82 6.4.2. Other Asynchronous Transfer Protocols . . . . . . . . 82 7. Conformance Requirements . . . . . . . . . . . . . . . . . . 82 7.1. PKI Management Operations . . . . . . . . . . . . . . . . 82 7.2. Message Transfer . . . . . . . . . . . . . . . . . . . . 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 @@ -1773,20 +1773,26 @@ implementation which PKI management entity will act as Key Generation Authority (KGA) and perform the key generation. This PKI management entity MUST use a certificate containing the additional extended key usage extension id-kp-cmKGA in order to be accepted by the EE as a legitimate key generation authority. As described in Section 5.3.1, the KGA can use one of the PKI management operations described in the sections above to request the certificate for this key pair on behalf of the EE. + Note: When performing central key generation for a certificate + update, the KGA cannot use the old EE credentials for protection. + Therefore, the PKI management operation described in Section 4.1.2 + SHOULD be used instead of Section 4.1.3 to request a certificate for + the newly generated key pair on behalf of the EE. + Generally speaking, in machine-to-machine scenarios it is strongly preferable to generate public-private key pairs locally at the EE. Together with proof-of-possession of the private key in the certificate request, this is advisable to make sure that the entity identified in the newly issued certificate is the only entity that knows the private key. Reasons for central key generation may include the following: * Lack of sufficient initial entropy. @@ -2083,21 +2089,21 @@ -- MUST contain the rKeyId choice rKeyId REQUIRED subjectKeyIdentifier REQUIRED -- MUST contain the same value as the senderKID in the -- respective request message header encryptedKey REQUIRED -- MUST be the encrypted content-encryption key -4.1.6.2. Using Key Transport Key Managemen Technique +4.1.6.2. Using Key Transport Key Management Technique This variant can be applied in combination with the PKI management operations specified in Section 4.1.1 to Section 4.1.3 using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST allow for the key usage "keyEncipherment" and not for "keyAgreement". Therefore, the related key pair MUST be used for encipherment of the content-encryption key. For this key management technique, the KeyTransRecipientInfo structure MUST be used in the contentInfo field. @@ -2616,46 +2622,47 @@ Note: If the EE does not want to request a specific CRL it MAY use instead a general message with OID id-it-currentCrl as specified in RFC 4210 Section 5.3.19.6 [RFC4210]. The message sequence for this PKI management operation is as given above, with the following specific content: 1 the infoType OID to use is id-it-crlStatusList in the request and id-it-crls in the response - 2 the infoValue of the request MUST be present and contain a - CRLStatus structure + 2 the infoValue of the request MUST be present and contain exactly + one CRLStatus structure - 3 if present, the infoValue of the response MUST contain a CRL + 3 if present, the infoValue of the response MUST contain exactly one + CRL Detailed Description of infoValue Field of genm: CRLSource REQUIRED -- MUST contain exactly one CRLSource structure -- MUST contain the dpn choice of type DistributionPointName if -- the CRL distribution point name is available -- Otherwise, MUST contain the issuer choice identifying the CA -- that issues the CRL. It MUST contain the issuer DN in the -- directoryName field of a GeneralName element. thisUpdate OPTIONAL -- SHOULD contain the thisUpdate field of the latest CRL form -- the issuer specified in the given dpn or issuer field, -- in case such a CRL is already known by the EE Detailed Description of infoValue Field of genp: infoValue OPTIONAL -- MUST be absent if no CRL to be returned is available - -- MUST contain one CRL update from the referenced source, if a - -- thisUpdate value was not given or a more recent CRL is - -- available + -- MUST contain exactly one CRL update from the referenced + -- source, if a thisUpdate value was not given or a more recent + -- CRL is available 4.4. Handling Delayed Delivery This is a variant of all PKI management operations described in this document. It is initiated in case a PKI management entity cannot respond to a request message in a timely manner, typically due to offline or asynchronous upstream communication, or due to delays in handling the request. The polling mechanism has been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by [I-D.ietf-lamps-cmp-updates]. @@ -3134,21 +3141,21 @@ extraCerts REQUIRED -- As described in Section 3.3 5.2.2.1. Adding Protection to a Request Message This variant means that a PKI management entity forwards a CMP message while authentically indicating successful validation and approval of a request message without changing the original message. - By adding a protection using its own CMP protecting key the PKI + By adding a protection using its own CMP protection key the PKI management entity provides a proof of verifying and approving the message as described above. Thus, the PKI management entity acts as an actual Registration Authority (RA), which implements important security functionality of the PKI. Applying an additional protection is specifically relevant when forwarding a message that requests a certificate update or central key generation. This is because the original protection of the EE must be preserved while adding an indication of approval by the PKI management entity. The PKI management entity wrapping the original request message in a @@ -3256,21 +3263,21 @@ 5 <- nested <- 6 handle nested 5.2.3. Replacing Protection The following two alternatives can be used by any PKI management entity forwarding a CMP message with or without changes while providing its own protection and in this way asserting approval of the message. - By replacing the existing protection using its own CMP protecting key + By replacing the existing protection using its own CMP protection key the PKI management entity provides a proof of verifying and approving the message as described above. Thus, the PKI management entity acts as an actual Registration Authority (RA), which implements important security functionality of the PKI. Before replacing the existing protection by a new protection, the PKI management entity MUST verify the protection provided and approve its content, including any modifications that it may perform. It MUST also check that the sender, as authenticated by the message protection, is authorized for the given operation. @@ -3621,21 +3628,21 @@ In case a PKI management entity receives an unexpected CoAP status code from upstream, it MUST respond downstream with an error message as described in Section 3.6 using a failInfo bit corresponding to the status code, e.g., systemFailure. Like for HTTP transfer , to offer a second line of defense or to provide hop-by-hop privacy protection, DTLS MAY be utilized as described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. -6.3. Piggybacking on other Reliable Transfer +6.3. Piggybacking on Other Reliable Transfer CMP messages MAY also be transfer on some other reliable protocol, e.g., EAP or MQTT. Connection, delay, and error handling mechanisms similar to those specified for HTTP in Section 6.1 need to be implemented. A more detailed specification is out of scope of this document and would need to be given for instance in the scope of the transfer protocol used. @@ -3695,21 +3702,21 @@ certificate management operation towards the CA not using CMP. Section 5.2 describes different options how an RA can forward a CMP message using CMP. Section 5.3 offers the option that an RA operates on behalf on an EE and therefore takes the role of the EE in Section 4. +==========+=============================+========+========+========+ | ID | PKI Management Operations | EE | RA | CA | | | and Variants | | | | +==========+=============================+========+========+========+ - | Generic | Generic Aspects of PKI | MUST | MAY | MUST | + | Generic | Generic Aspects of PKI | MUST | MUST | MUST | | | Messages and PKI | | | | | | Management Operations, | | | | | | Section 3 | | | | +----------+-----------------------------+--------+--------+--------+ | IR | Enrolling an End Entity | MUST | MAY | MUST | | | to a New PKI, | | | | | | Section 4.1.1 | | | | +----------+-----------------------------+--------+--------+--------+ | CR | Enrolling an End Entity | MAY | MAY | MAY | | | to a Known PKI, | | | | @@ -3846,21 +3853,21 @@ +=========+=======================+========+========+========+ | ID | Message Transfer Type | EE | RA | CA | +=========+=======================+========+========+========+ | HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD | | | Section 6.1 | | | | +---------+-----------------------+--------+--------+--------+ | CoAP | CoAP Transfer, | MAY | MAY | MAY | | | Section 6.2 | | | | +---------+-----------------------+--------+--------+--------+ - | Piggyb | Piggybacking on other | MAY | MAY | MAY | + | Piggyb | Piggybacking on Other | MAY | MAY | MAY | | | Reliable Transfer, | | | | | | Section 6.3 | | | | +---------+-----------------------+--------+--------+--------+ | Offline | Offline Transfer, | MAY | MAY | MAY | | | Section 6.4 | | | | +---------+-----------------------+--------+--------+--------+ Table 4: Level of Support for Message Transfer Types 8. IANA Considerations @@ -3965,23 +3972,23 @@ 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, . [I-D.ietf-lamps-cmp-algorithms] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, "Certificate Management Protocol (CMP) Algorithms", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp- - algorithms-12, 6 April 2022, + algorithms-13, 13 May 2022, . + cmp-algorithms-13>. [I-D.ietf-lamps-cmp-updates] Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Management Protocol (CMP) Updates", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -4053,23 +4060,23 @@ Oheimb, D. V., Fries, S., Brockhaus, H., and E. Lear, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", Work in Progress, Internet-Draft, draft-ietf-anima-brski- ae-01, 6 April 2022, . [I-D.ietf-anima-brski-prm] Fries, S., Werner, T., Lear, E., and M. C. Richardson, "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in - Progress, Internet-Draft, draft-ietf-anima-brski-prm-02, 4 - March 2022, . + Progress, Internet-Draft, draft-ietf-anima-brski-prm-03, + 29 April 2022, . [I-D.ietf-netconf-sztp-csr] Watsen, K., Housley, R., and S. Turner, "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Work in Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, 2 March 2022, . [IEC.62443-3-3] @@ -4248,20 +4255,29 @@ INTEGER 2048 } } } Appendix B. History of Changes Note: This appendix will be deleted in the final version of the document. + From version 11 -> 12: + + * Added a note to Section 4.1.6 to clarify the combination of + central key generation with certificate update + * Updated Section 4.3.4 for clarification that only one CRL per + round-trip is requested + * Updated Section 7.1 to fix a wrong change from the last update in + the first two rows of Table 3 + From version 10 -> 11: * Updated Section 3.2, 3.5, and 3.6.4 to define more clearly signature-based protection as the default and the exception for not protecting error messages as mentioned at IETF 113 * Streamlined headlines in Section 4.1 * Updates Section 6.1 and Section 6.2 regarding new well-known path segment for profile labels as discussed during IETF 113 * Updated Section 7.1. on the support of PKI management operations required for EEs, RAs, and CAs as mentioned at IETF 113