Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol
draft-ietf-ace-cmpv2-coap-transport-10

# John Scudder, RTG AD, comments for draft-ietf-ace-cmpv2-coap-transport-09
CC @jgscudder

Thanks for this document. I have one minor comment below, which I hope may be helpful.

## COMMENTS

### Section 2.6

In the second paragraph below,

   Alternatively, an EE MAY periodically poll for the current status of
   the CA via the "PKI Information Request" message, see section 6.5 of
   [RFC4210].  If supported, EEs may also use "Support Messages" defined
   in section 4.3 of Lightweight CMP Profile
   [I-D.ietf-lamps-lightweight-cmp-profile] to get information about the
   CA status.

   These mechanisms will help constrained devices, that are acting as
   EEs, to conserve resources by eliminating the need to create an
   endpoint for receiving notifications from RA or CA.  It will also
   simplify the implementation of a CoAP-to-HTTP proxy.

is it right that "these mechanisms" refers to the two mechanisms in the immediately-preceding paragraph? If so, this isn't clear from how you've structured the text. One possible rewrite is,

   Two alternatives are first, an EE MAY periodically poll for the
   current status of the CA via the "PKI Information Request" message,
   see section 6.5 of [RFC4210], or second, if supported, EEs may also
   use "Support Messages" defined in section 4.3 of Lightweight CMP
   Profile [I-D.ietf-lamps-lightweight-cmp-profile] to get information
   about the CA status. These mechanisms will help constrained devices,
   that are acting as EEs, to conserve resources by eliminating the need
   to create an endpoint for receiving notifications from RA or CA.  It
   will also simplify the implementation of a CoAP-to-HTTP proxy.

Or at a minimum, just eliminate the paragraph break between the two paragraphs (i.e., merge them into one, even if no other rewrite). 

I also wonder why the first alternative is given as a MAY but the second, as a "may".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

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?

Thank you for this document -- it's short, simple and clear.

Thanks for working on this specification. My review did not notice any transport related issues.

However, I have one observation-

  It seems the word "server" has been used in three ways - 1) CMP server, 2) server and 3) pre-configured/configured server. I would be great if 2) and 3) could be described better based on their role. Right now, this is a bit confusing, for example, when only 2) used and it refers to a CMP server.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Daniel Migault for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non blocking)

## Reviews outside of ACE ?

The shepherd's write-up and the mail archive do not mention any review by CORE WG of this document. I understand that CoAP is only a 'transport', but a quick review would have been beneficial.

## idnits issues

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ace-cmpv2-coap-transport-09.txt founds two important issues: wrong BCP14 template and unused reference.

## Section 2.6

The URI in this section uses "<profileLabel>", is it the same as "<name>" in section 2.1 ? If so, may I suggest to use the same term ?

## Section 4

Is "MAY" the right verb to be used in `If confidentiality is desired, CoAP over DTLS [RFC9147] MAY be used to provide confidentiality` ? I would have guessed a "SHOULD", or are there alternatives to CoAP over DTLS ?

# GEN AD review of draft-ietf-ace-cmpv2-coap-transport-09

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ihMGS0Wl8sdlJlzkSZU-hlm7wRE).

## Comments

### Boilerplate

This document uses the RFC2119 keywords "SHOULD", "NOT RECOMMENDED",
"OPTIONAL", "SHOULD NOT", "SHALL", "MAY", "RECOMMENDED", "SHALL NOT", "MUST
NOT", "MUST", and "REQUIRED", but does not contain the recommended RFC8174
boilerplate. (It contains some text with a similar beginning.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Section 4, paragraph 0
```
  4.  Security Considerations
```
Why is this a list of bullets instead of just regular text?

### Uncited references

Uncited references: `[RFC5280]`.

### Outdated references

Document references `draft-ietf-lamps-lightweight-cmp-profile-13`, but `-21` is
the latest available revision.

### Grammar/style

#### Section 2.3, paragraph 1
```
ional and potentially large fields. Thus a CMP message can be much larger tha
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thanks for this document.

I have some minor comments/suggestions that may improve this document:

Minor level comments:

(1) p 2, sec 2.1.  CoAP URI Format

       coap://www.example.com/.well-known/cmp
       coap://www.example.com/.well-known/cmp/<operation>
       coap://www.example.com/.well-known/cmp/p/<name>
       coap://www.example.com/.well-known/cmp/p/<name>/<operation>

Presumably the goal here is to keep the URLs reasonable short, is that worth stating at all?


(2) p 3, sec 2.3.  CoAP Request Format

                                        If the CoAP request is
   successful then the server MUST return a Success 2.xx response code
   otherwise server MUST return an appropriate Client Error 4.xx or
   Server Error 5.xx response code.

Noting that this is using RFC 2911 language, is this requirement specific to CMP over CoAP, or is this just restating CoAP behaviour.


(3) p 4, sec 2.4.  CoAP Block-Wise Transfer Mode

   A CMP PKIMesssage consists of a header, body, protection, and
   extraCerts structures which may contain many optional and potentially
   large fields.  Thus a CMP message can be much larger than the Maximum
   Transmission Unit (MTU) of the outgoing interface of the device.  The
   EEs and RAs or CAs, MUST use the Block-Wise transfer mode [RFC7959]
   to transfer such large messages instead of relying on IP
   fragmentation.
   If a CoAP-to-HTTP proxy is in the path between EEs and CA or EEs and
   RA then, if the server supports, it MUST use the chunked transfer
   encoding [RFC9112] to send data over the HTTP transport.  The proxy
   MUST try to reduce the number of packets sent by using an optimal
   chunk length for the HTTP transport.

It wasn't entirely obvious to me as to what entity "the server" is referring to in this paragraph.  Perhaps worth being more specific?


(4) p 4, sec 2.6.  Announcement PKIMessage

   If the server supports CMP Announcements messages, then it MUST send
   appropriate Success 2.xx response code, otherwise it MUST send an
   appropriate Client Error 4.xx or Server Error 5.xx response code.

I found this text very slightly confusing.  E.g., the first part of the sentence is about supporting announcement messages, and the second part is about response codes.  I presume that this is about replying to the register messages, but perhaps this could be made a bit clearer.


(5) p 4, sec 2.6.  Announcement PKIMessage

     A client on receiving a 2.xx success
   response without the Observe option [RFC7641] MAY try after some time
   to register again for announcements from the CMP server.  Since
   server can remove the EE from the list of observers for announcement
   messages, an EE SHOULD periodically re-register itself for
   announcement messages.

Would it be helpful to define or give guidance as what sort of period is recommended here (e.g., once per day, or once per year)?


(6) p 5, sec 3.  Proxy Support

   The CoAP-to-HTTP proxy can either be located closer to the EEs or
   closer to the RA or CA.  The proxy MAY support service discovery and
   resource discovery as described in section 2.2.  The CoAP-to-HTTP
   proxy MUST function as a reverse proxy, only permitting connections
   to a limited set of pre-configured servers.

Given the RFC 2119 MUST, is there a definition or reference as to what is meant by reverse proxy?


(7) p 5, sec 3.  Proxy Support

     It is out of scope of
   this document on how a reverse proxy can route CoAP client requests
   to one of the configured servers.  Some recommended mechanisms are as
   follows:

Perhaps: "It is out of scope of this document to specify how a reverse ..."


(8) p 5, sec 4.  Security Considerations

   *  If PKIProtection is used, the PKIHeader and PKIBody of the CMP
      protocol are cryptographically protected against malicious
      modifications.  As such, UDP can be used without compromising the
      security of the CMP protocol.  Security Considerations for CoAP
      are defined in [RFC7252].

Possibly a question for the SEC ADs, but would "without compromising the integrity of " be better than "without compromising the security" (given CMP does not provide confidentiality, as stated below)?



Nit level comments:

(9) p 4, sec 2.6.  Announcement PKIMessage

     If
   for some reason server cannot add the client to its list of observers
   for the announcements, it can omit the Observe option [RFC7641] in
   the response to the client.

Suggest: "reason server" => "reason, the server"


(10) p 5, sec 3.  Proxy Support

   This section provides guidance on using a CoAP-to-HTTP proxy between
   EEs and RAs or CAs in order to avoid changes to the existing PKI
   implementation.  Since the CMP payload is same over CoAP and HTTP
   transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be
   implemented based on section 10 of [RFC7252].

Suggest: is same => is the same.  I also suggest starting a new paragraph from "Since the".


(11) p 6, sec 4.  Security Considerations

   *  Implementations SHOULD use the available datagram size and avoid
      small datagrams containing partial CMP PKIMessage data in order to
      reduce memory usage for packet buffering.

Perhaps "avoid small datagrams" => "avoid sending small datagrams"?


(12) p 6, sec 4.  Security Considerations

   *  A CoAP-to-HTTP proxy can also protect the PKI entities by handling
      UDP and CoAP messages.  Proxy can mitigate attacks like denial of
      service attacks, replay attacks and resource-exhaustion attacks by
      enforcing basic checks like validating that the ASN.1 syntax is
      compliant to CMP messages and validating the PKIMessage protection
      before sending them to PKI entities.

Suggest "Proxy can" => "The proxy can"