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

[Roman Danyliw via Datatracker <[e-mail]>]

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?