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

[Thomas Fossati <[e-mail]>]

Hi Ben,

Thanks very much for your review and comments.

On Mon, 6 Oct 2025 at 22:01, Benjamin Schwartz via Datatracker
<[e-mail]> wrote:
>
> 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. *

This design is based on the assumption that there will only be a
limited number of conceptual RATS messages.

I'd be surprised if we ended up with more than triple the number of
currently registered messages.  Therefore, 32 should be more than
enough. [ Famous last words :-) ]

> Also, the description says "Only four values are registered", but the
> definition of `cm-type` shows 5 values.

Yes, thanks.  We spotted that too and fixed it in the editor's copy [1]

[1] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/247

> 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.

I can see now how that could be interpreted that way, and that's
certainly not how it's supposed to work (at least not in the common
case), so we need to clarify that.

The split in the JSON/CBOR decoding path is expected to happen via
media type/content format (§10.6 and §10.7, respectively), or via the
container context of the embedded CMW, i.e., the CWT/JWT claims (§10.1
and §10.2) or the X.509 extension (§10.8).

Once the CMW has been dispatched to the intended decoder, however,
there is still a look-ahead step to distinguish between an array or
object (on the JSON path) and a record, map or tag (on the CBOR path).

Would it be helpful to separate the CMWTypeDemux function into two,
one for JSON and one for CBOR?  Or would a clarification in prose
suffice?

Regarding the following observation:

> [...] 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)

I am not sure I understand what you mean.  CMW demux is based on the
jump table described in Appendix B of RFC8949.

> 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.)

Is this because of the limited codepoint space?  If so, we don't think
there will be an uncontrolled proliferation of conceptual messages
unless the RATS architecture changes dramatically.

cheers, thanks!