Roman Danyliw has entered the following ballot position for draft-ietf-ace-cmpv2-coap-transport-09: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Valery Smyslov for the SECDIR review. ** RFC6712 chose to formally “update” RFC4210. Would such symmetry be appropriate in this document for RFC4210 and [I-D.ietf-lamps-cmp-updates]? ** Idnits returned the following actionable feedback: == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unused Reference: 'RFC5280' is defined on line 432, but no explicit reference was found in the text ** Section 1. This document specifies the use of CoAP over UDP as a transport medium for the CMP version 2 [RFC4210] , CMP version 3 [I-D.ietf-lamps-cmp-updates] designated as CMP in this document and Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] . -- Editorial. There are extra spaces between the reference and punctuation. -- What does it mean for “CMP version 3” to be “designated as CMP in this document”? Are all statements which use “CMP” only referring to a particular version of CMP, specifically, [I-D.ietf-lamps-cmp-updates]? ** Section 4. Since the Proxy may have access to the CMP-Level metadata and control over the flow of CMP messages therefore proper role based access control should be in place. What is “CMP-Level metadata”? ** Section 4. -- RFC6712 provides the following caution to motivate the use of TLS: CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business critical information. Should this text be added to the following text bullet: The CMP protocol does not provide confidentiality of the CMP payloads. If confidentiality is desired, CoAP over DTLS [RFC9147] MAY be used to provide confidentiality for the CMP payloads, although it cannot conceal that the CMP protocol is used within the DTLS layer. -- RFC6712 also provides the following caution about unprotected HTTP Announcement messages: 4. If no measures to authenticate and protect the HTTP responses to pushed Announcement messages are in place, their information regarding the Announcement's processing state may not be trusted. In that case, the overall design of the PKI system must not depend on the Announcements being reliably received and processed by their destination. Section 3.7 seems to allow for these over CoAP. Should similar guidance be provided? _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
