[secdir] draft-ietf-rats-msg-wrap-18 ietf last call Secdir review

[Benjamin Schwartz via Datatracker <[e-mail]>]

Document: draft-ietf-rats-msg-wrap
Title: RATS Conceptual Messages Wrapper (CMW)
Reviewer: Benjamin Schwartz
Review result: Has Nits

Clear document describing some serialization formats.

Notes:

Section 3.1:

* The "ind" field is defined as a 32-bit bitfield of types.  This constraint on
the range of expressible message types seems hard to justify.  In the common
case, a short list of small integers would be almost as compact (in CBOR), and
in the extreme case (32 message types), the proportional savings of using a
bitfield is presumably minimal compared to the messages themselves.  This seems
like a case of trying to save 1 byte, at the cost of considerably reduced
flexibility for extensions (especially experimental or private extensions). 
And in some cases, the bitfield representation is actually _less_ compact. *
Also, the description says "Only four values are registered", but the
definition of `cm-type` shows 5 values.

Section 3.4:

* It seems like this text is recommending sending JSON or CBOR in a shared
container, with the recipient disambiguating them based on the first byte.
  - It's not clear what the motivating use case is for this algorithm.
  - This is a risky design.  Parsers developed in JSON-only or CBOR-only
  ecosystems may sensibly omit the unused format, leading to misbehaviors when
  they are used with other format. - The proposed disambiguation is different
  from the one proposed in the CBOR specification (see
  https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4.6-4,
  https://www.rfc-editor.org/rfc/rfc9277.html#section-2.2) - Unless there is a
  compelling reason, it would seem safer to treat JSON and CBOR consistently as
  distinct media types, distinguished by an indicator in the upper layer (as is
  done in Section 4.4 for X.509).

Section 10.5
* The IANA registry is given as "expert review", but the instructions to the
expert effectively make the policy equivalent to Standards Action (or perhaps
even stricter!).  IMHO it should be changed to Standards Action.  (A
non-bitfield representation would allow a much more relaxed registration
policy.)