--- 1/draft-ietf-lamps-lightweight-cmp-profile-07.txt 2021-11-19 10:13:11.320897809 -0800 +++ 2/draft-ietf-lamps-lightweight-cmp-profile-08.txt 2021-11-19 10:13:11.496902243 -0800 @@ -1,19 +1,19 @@ LAMPS Working Group H. Brockhaus, Ed. -Internet-Draft S. Fries -Intended status: Standards Track D. von Oheimb -Expires: 28 April 2022 Siemens - 25 October 2021 +Internet-Draft D. von Oheimb +Intended status: Standards Track S. Fries +Expires: 23 May 2022 Siemens + 19 November 2021 Lightweight Certificate Management Protocol (CMP) Profile - draft-ietf-lamps-lightweight-cmp-profile-07 + draft-ietf-lamps-lightweight-cmp-profile-08 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,35 +30,35 @@ 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 28 April 2022. + This Internet-Draft will expire on 23 May 2022. Copyright Notice Copyright (c) 2021 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 and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 1.3. Special requirements of industrial and IoT scenarios . . 5 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 1.6. Compatibility with existing CMP profiles . . . . . . . . 7 @@ -105,51 +105,51 @@ 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56 4.3.2. Get root CA certificate update . . . . . . . . . . . 56 4.3.3. Get certificate request template . . . . . . . . . . 58 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62 5. PKI management entity operations . . . . . . . . . . . . . . 66 5.1. Responding to requests . . . . . . . . . . . . . . . . . 66 5.1.1. Responding to a certificate request . . . . . . . . . 67 - 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 68 + 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 67 5.1.3. Responding to a confirmation message . . . . . . . . 68 - 5.1.4. Responding to a revocation request . . . . . . . . . 69 + 5.1.4. Responding to a revocation request . . . . . . . . . 68 5.1.5. Responding to a support message . . . . . . . . . . . 69 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69 5.2.1. Not changing protection . . . . . . . . . . . . . . . 71 - 5.2.2. Adding protection and batching of messages . . . . . 72 + 5.2.2. Adding protection and batching of messages . . . . . 71 5.2.2.1. Adding protection to a request message . . . . . 72 - 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 74 + 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 73 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75 - 5.2.3.1. Not changing any included proof-of-possession . . 76 + 5.2.3.1. Not changing any included proof-of-possession . . 75 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76 - 5.3. Acting on behalf of other PKI entities . . . . . . . . . 77 + 5.3. Acting on behalf of other PKI entities . . . . . . . . . 76 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77 - 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 78 + 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 77 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81 6.3. Piggybacking on other reliable transfer . . . . . . . . . 83 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83 6.4.2. Other asynchronous transfer protocols . . . . . . . . 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 84 10.2. Informative References . . . . . . . . . . . . . . . . . 86 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89 Appendix B. History of changes . . . . . . . . . . . . . . . . . 91 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 1. Introduction [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms], when available. This document specifies PKI management operations supporting machine- to-machine and IoT use cases. Its focus is to maximize automation @@ -409,21 +409,21 @@ For the sake of interoperability and robustness, implementations should, as far as security is not affected, adhere to Postel's law: "Be conservative in what you do, be liberal in what you accept from others" (often reworded as: "Be conservative in what you send, be liberal in what you receive"). When in Section 3, Section 4, and Section 5 a field of the ASN.1 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly - specified, it SHOULD not be used by the sending entity. The + specified, it SHOULD NOT be used by the sending entity. The receiving entity MUST NOT require its absence and if present MUST gracefully handle its presence. 1.8. Structure of this document Section 2 introduces the general PKI architecture and approach to certificate management that is assumed in this document. Then it lists the PKI management operations specified in this document, partitioning them into mandatory, recommended, and optional ones. @@ -808,21 +808,21 @@ -- the hashAlg field -- MUST be 2 to indicate CMP v2 in all other cases -- For details on version negotiation see RFC-CMP-Updates sender REQUIRED -- SHOULD contain a name representing the originator of the -- message; otherwise, the NULL-DN (a zero-length -- SEQUENCE OF RelativeDistinguishedNames) MUST be used -- SHOULD be the subject of the CMP protection certificate, i.e., -- the certificate corresponding to the private key used to sign -- the message - -- In a multi-hop scenario, the receiving entity SHOULD not rely + -- In a multi-hop scenario, the receiving entity SHOULD NOT rely -- on the correctness of the sender field. recipient REQUIRED -- SHOULD be the name of the intended recipient; otherwise, the -- NULL-DN MUST be used -- In the first message of a PKI management operation: -- SHOULD be the subject DN of the CA the PKI management -- operation is requested from -- In all other messages: -- SHOULD contain the value of the sender field of the previous -- message in the same PKI management operation @@ -977,22 +977,22 @@ Authorization of PKI management operations: * Each EE or RA MUST have sufficient information to be able to authorize the PKI management entity for performing the upstream PKI management operation. Note: This may be achieved for example by using the cmcRA extended key usage in server certificates, by local configuration such as specific name patterns for subject DN or SAN portions that may - identify an RA, and/or by having a dedicated PKI Infrastructure - root CA usable only for authenticating PKI management entities. + identify an RA, and/or by having a dedicated root CA usable only + for authenticating PKI management entities. * Each PKI management entity MUST have sufficient information to be able to authorize the downstream PKI entity requesting the PKI management operation. Note: For authorizing an RA the same examples apply as above. The authorization of EEs can be very specific to the application domain and may involve information from configuration or inventory database. It may involve, e.g., the issuer information of the EE certificate, specific contents of the CMP protection certificate @@ -1119,21 +1119,21 @@ * timeout occurred while waiting for a response, * rejection of a newly issued certificate while implicit confirmation has been granted. Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated. In case they expect a further message from the EE, a connection interruption or timeout will occur. Then they also MUST regard the current PKI - management operation as terminated with failure and MUST not attempt + management operation as terminated with failure and MUST NOT attempt to send an error message downstream. 3.6.2. Reporting error conditions downstream In case the PKI management entity detects an error condition, e.g., rejecting the request due to policy decision, in the body of an ir, cr, p10cr, kur, or rr message received from downstream, it SHOULD report the error in the specific response message, i.e., an ip, cp, kup, or rp with "rejection" status, as described in Section 4.1.1 and Section 4.2. This can also happen in case of polling. @@ -1323,22 +1323,22 @@ | waiting for pkiConf*) | | | | | | | | received | | | | pkiConf | | +-----------------+-----------------+-----------------+ | v end *) in case of a delayed delivery of pkiConf responses the same - polling mechanism is initiated as for rp or genp messages, by sending - an error message with status "waiting". + polling mechanism is initiated as for rp or genp messages, by + sending an error message with status "waiting". Note: All CMP messages belonging to the same PKI management operation MUST have the same transactionID because the message receiver identifies the elements of the operation in this way. This section is aligned with CMP [RFC4210], CMP Updates [I-D.ietf-lamps-cmp-updates], and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. Guidelines as well as an algorithm use profile for this document are @@ -1401,22 +1401,22 @@ certificate request message as described in Section 3.1. In case the EE receives a CA certificate in the caPubs field for installation as a new trust anchor, it MUST properly authenticate the message and authorize the sender as trusted source of the new trust anchor. This authorization is typically indicated using shared secret information for protecting an initialization response (ir) message. Authorization can also be signature-based using a certificate issued by another PKI that is explicitly authorized for this purpose. A certificate received in caPubs MUST NOT be accepted - as trust anchor if the CMP message has been protected using a - certificate issued by this same CA or one of its subordinate CAs. + as a trust anchor if it is the root CA certificate of the certificate + used for protecting the message. 4.1.1. Requesting a certificate from a new PKI with signature-based protection This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e.g., a manufacturer-issued IDevID certificate [IEEE.802.1AR_2018], to authenticate itself to the new PKI. Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) @@ -1462,21 +1462,21 @@ For this PKI management operation, the EE MUST include exactly one CertReqMsg in the ir. If more certificates are required, further requests MUST be sent using separate PKI management operation. If the EE wants to omit sending a certificate confirmation message after receiving the ip, e.g., to reduce the number of protocol messages exchanged in this PKI management operation, it MUST request this by including the implicitConfirm extension in the header of the ir message, see Section 3.1. - If the EE did not request implicit confirmation or timplicit + If the EE did not request implicit confirmation or implicit confirmation was not granted by the PKI management entity, certificate confirmation MUST be performed as follows. If the EE successfully received the certificate, it MUST send a certConf message in due time. On receiving a valid certConf message, the PKI management entity MUST respond with a pkiConf message. If the PKI management entity does not receive the expected certConf message in time it MUST handle this like a rejection by the EE. In case of rejection the PKI management entity SHALL terminate the PKI management operation, and the PKI MAY revoke the newly issued certificate. @@ -2172,35 +2172,36 @@ The detailed description of the KeyAgreeRecipientInfo structure looks like this: kari REQUIRED -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section -- 6.2.2 [RFC5652] version REQUIRED -- MUST be 3 originator REQUIRED - -- MUST contain the originatorKey choice - algorithm REQUIRED - -- MUST be the algorithm identifier of the key agreement - -- algorithm - -- The algorithm type MUST be a KM_KA_ALG as specified in - -- RFC-CMP-Alg Section 4.1 - publicKey REQUIRED - -- MUST be the ephemeral public key of the sending party + -- MUST contain the subjectKeyIdentifier of the certificate, + -- and thereby identifies the sender's public key. + -- MUST contain the same value as the senderKID in the + -- message header ukm RECOMMENDED -- MUST be used when 1-pass ECMQV is used -- SHOULD be present to ensure uniqueness of the key - -- encryption key, see [RFC8419] + -- encryption key keyEncryptionAlgorithm REQUIRED - -- MUST be the algorithm identifier of the key wrap algorithm + -- MUST be the algorithm identifier of the key agreement + -- algorithm + -- The algorithm type MUST be a KM_KA_ALG as specified in + -- RFC-CMP-Alg Section 4.1 + -- The parameters field of the key agreement algorithm MUST + -- contains the key wrap algorithm -- The algorithm type MUST be a KM_KW_ALG as specified in -- RFC-CMP-Alg Section 4.3 recipientEncryptedKeys REQUIRED -- MUST contain exactly one RecipientEncryptedKey element rid REQUIRED -- MUST contain the rKeyId choice rKeyId REQUIRED subjectKeyIdentifier REQUIRED @@ -2255,21 +2256,21 @@ CMP messages. The shared secret information used for the MAC-based protection MUST also be used for the encryption of the content- encryption key but with a different salt value applied in the key derivation algorithm. For this key management technique, the PasswordRecipientInfo structure MUST be used in the contentInfo field. Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique. For centrally generated key pairs, the entropy of the - shared secret information SHALL not be less than the security + shared secret information SHALL NOT be less than the security strength of the centrally generated key pair. Further guidance is available in Section 8. The PasswordRecipientInfo structure included into the EnvelopedData structure is specified in CMS Section 6.2.4 [RFC5652]. The detailed description of the PasswordRecipientInfo structure looks like this: pwri REQUIRED @@ -2517,72 +2518,70 @@ -- MUST be a sequence of CMPCertificate 4.3.2. Get root CA certificate update This PKI management operation can be used by an EE to request an updated root CA Certificate as described in Section 4.4 of RFC 4210 [RFC4210]. An EE requests an update of a root CA certificate from the PKI management entity by sending a general message with OID id-it- - oldTrustAnchor, which SHOULD include this root CA certificate in the + rootCaCert, which SHOULD include the old root CA certificate in the message body, as specified in CMP Updates - [I-D.ietf-lamps-cmp-updates]. Optionally, the trust anchor MAY be - provided as public key only. The PKI management entity responds with - a general response with the same OID that either contains the update - of the root CA certificate consisting of up to three certificates, or - with no content in case no update is available. + [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds + with a general response with OID id-it-rootCaKeyUpdate that either + contains the update of the root CA certificate consisting of up to + three certificates, or with no content in case no update is + available. - Note: This mechanism can also be used in case the trust anchor to be - updated is not provided as a self-signed certificate, but, e.g., as a - certificate issued by a different CA. + Note: This mechanism may also be used to update trusted non-root + certificates, i.e., trusted intermediate CA or issuing CA + certificates. The newWithNew certificate is the new root CA certificate and is REQUIRED to be present if available. The newWithOld certificate is REQUIRED to be present in the response message because it is needed for the receiving entity trusting the old root CA certificate to gain trust in the new root CA certificate. The oldWithNew certificate is OPTIONAL because it is only needed in rare scenarios where entities do not already trust the old root CA. No specific prerequisites apply in addition to those specified in Section 3.4. 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-oldTrustAnchor in the request and - id-it-trustAnchorUpdate in the response + 1 the infoType OID to use is id-it-rootCaCert in the request and id- + it-rootCaKeyUpdate in the response - 2 the infoValue of the request MUST be an OldTrustAnchor structure - referencing the trust anchor the update is requested for + 2 the infoValue of the request SHOULD contain the root CA + certificate the update is requested for 3 if present, the infoValue of the response MUST be a - TrustAnchorUpdate structure + RootCaKeyUpdateContent structure The infoValue field of the general request containing the id-it- - oldTrustAnchor OID looks like this: + rootCaCert OID looks like this: infoValue RECOMMENDED - -- MUST contain an OldTrustAnchor structure referencing the - -- trust anchor to be updated - -- SHOULD be the root CA certificate, if available - -- MAY be the publicKey of the trust anchor otherwise + -- MUST contain the root CA certificate to be updated, if + -- available The infoValue field of the general response containing the id-it- - trustAnchorUpdate OID looks like this: + rootCaKeyUpdate OID looks like this: infoValue OPTIONAL -- MUST be absent if no update of the root CA certificate is -- available -- MUST be present if an update of the root CA certificate - -- is available and MUST be of type TrustAnchorUpdate + -- is available and MUST be of type RootCaKeyUpdateContent newWithNew REQUIRED -- MUST be present if infoValue is present -- MUST contain the new root CA certificate newWithOld REQUIRED -- MUST be present if infoValue is present -- MUST contain a certificate containing the new public -- root CA key signed with the old private root CA key oldWithNew OPTIONAL -- MAY be present if infoValue is present -- MUST contain a certificate containing the old public @@ -3807,38 +3807,38 @@ We thank the various reviewers of this document. 10. References 10.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-03, 1 - October 2021, . + 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-07, 22 August 2021, + algorithms-08, 17 November 2021, . + cmp-algorithms-08>. [I-D.ietf-lamps-cmp-updates] - Brockhaus, H. and D. V. Oheimb, "Certificate Management - Protocol (CMP) Updates", Work in Progress, Internet-Draft, - draft-ietf-lamps-cmp-updates-12, 9 July 2021, - . + Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate + Management Protocol (CMP) Updates", Work in Progress, + Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25 + October 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . @@ -3907,23 +3907,23 @@ Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, 25 October 2021, . [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-09, - 22 October 2021, . + Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-11, + 8 November 2021, . [IEC.62443-3-3] IEC, "Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels", IEC 62443-3-3, August 2013, . [IEEE.802.1AR_2018] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR-2018, @@ -4095,20 +4095,29 @@ } } } Appendix B. History of changes Note: This appendix will be deleted in the final version of the document. + From version 07 -> 08: + + * Updates Section 4.1.6.1. regarding content of the originator and + keyEncryptionAlgorithm fields (see thread "AD review of draft- + ietf-lamps-cmp-algorithms-07") + * Rolled back part of the changes on root CA certificate updates in + Section 4.3.2 (see thread "Allocation of OIDs for CRL update + retrieval (draft-ietf-lamps-cmp-updates-13)") + From version 06 -> 07: * Added references to [draft-ietf-netconf-sztp-csr] in new Section 1.5 and Section 4.1.4 * Added reference to [I-D.ietf-anima-brski-async-enroll] in new Section 1.5 and Section 4.1.1 * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as the PUSH use case is continued to be discussed in this draft after the split of BRSKI-AE * Improved note regarding UNISIG Subset-137 in Section 1.6 @@ -4322,18 +4330,19 @@ document. * Further minor changes in wording. Authors' Addresses Hendrik Brockhaus (editor) Siemens AG Email: hendrik.brockhaus@siemens.com - Steffen Fries - Siemens AG - - Email: steffen.fries@siemens.com David von Oheimb Siemens AG Email: david.von.oheimb@siemens.com + + Steffen Fries + Siemens AG + + Email: steffen.fries@siemens.com