Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-cmpv2-coap-transport-09: (with COMMENT)

[Mohit Sahni <[e-mail]>]

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 <
[e-mail]> 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?
>
>
>
>