Hi Roman, Thanks for your review and comments. Please find my response below: >** RFC6712 chose to formally “update” RFC4210. Would such symmetry be appropriate in this document for RFC4210 and [I-D.ietf-lamps-cmp-updates]? <M.S.> I will change the draft to update the RFC4210.
> == 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? <M.S.> This is auto generated text from the XML format of the draft I submitted. > == Unused Reference: 'RFC5280' is defined on line 432, but no explicit > reference was found in the text <M.S.> I will update the draft to add the reference for CRL. >-- Editorial. There are extra spaces between the reference and punctuation. <M.S.> I will fix that. >** Section 4. >What is “CMP-Level metadata”? CMP-Level Metadata is the metadata used in CMP messages for example message type or if it's a request or a response etc. >Should this text be added to the following text bullet: <M.S.> I had this text initially in the draft but it was removed based on comments from reviewers in the ACE WG. >Section 3.7 seems to allow for these over CoAP. Should similar guidance be provided? <M.S.> Section 5.1.3 of RFC 4210 gives some guidance regarding protection of PKI messages and I assume it covers the announcement messages too. Thanks Mohit On Mon, May 8, 2023 at 12:02 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_groups_iesg_statements_handling-2Dballot-2Dpositions_&d=DwIDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=7ijT-lNR3AYdO0EKaS1okVJbYegF7wYZCIgvimVi0WlsJfP4FTxi4siyvnKKgx_u&s=BEK6aj1f--zSVKAg-KqROTUJOMk2txpoQMCcAK7p7X4&e= > > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dace-2Dcmpv2-2Dcoap-2Dtransport_&d=DwIDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=7ijT-lNR3AYdO0EKaS1okVJbYegF7wYZCIgvimVi0WlsJfP4FTxi4siyvnKKgx_u&s=5l659rbFaKFBHHA5Hodw9AjYimCv1NpmQa_mkFxun2A&e= > > > > ---------------------------------------------------------------------- > 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
