[Rats] Re: Mohamed Boucadair's Discuss on draft-ietf-rats-msg-wrap-21: (with DISCUSS and COMMENT)

[Thomas Fossati <[e-mail]>]

Hi Med, thanks for the review and comments.

Your suggestions have been addressed in this PR [1].

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

See inline.

On Tue, 2 Dec 2025 at 09:23, Mohamed Boucadair via Datatracker
<[e-mail]> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Hi Henk, Ned, Thomas, Hannes, and Dionna,
>
> Thank you for the effort put into this specification.
>
> I trust the CDDL and ASN modules were validated.

yes :-)

> The document is well-written. Please find below some few DISCUSS points, mainly
> about references.
>
> # RFC 9334 is normative
>
> ## The concepts manipulated in this draft can’t be understood without RFC9334.
> This is actually ACKed in Section 2.

I think it is possible to implement CMW without understanding RFC9334.
Clearly, that would be a pity and not something I would recommend, but
strictly speaking, the technical skills required are an understanding
of CBOR, JSON, JWS, COSE and X.509.

That said, the idea of adding RFC9334 to the downref registry has been
discussed more than once in RATS.  Therefore, we are happy to use CMW
as a pretext to mkae the downref request.

> ## Note that this will be a downref, though. Per RFC3967, I’m afraid that we
> fall under the following:
>
>    For Standards Track or BCP documents requiring normative reference to
>    documents of lower maturity, the normal IETF Last Call procedure will
>    be issued, with the need for the downward reference explicitly
>    documented in the Last Call itself.

My understanding is that Section 2 of RFC 8067 (which updates RFC3967)
 relaxes this requirement, making it at the discretion of the IESG.

> # DER Encoding
>
> CURRENT:
>    The DER-encoded CMW is the value of the OCTET STRING for the
>    extnValue field of the extension.
>
> Missing normative reference for DER. Maybe X.690 : Information technology -
> ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical
> Encoding Rules (CER) and Distinguished Encoding Rules (DER)?

ack

> # Normative References, again
>
> CURRENT:
>    This section provides an ASN.1 module [X.680] for the CMW extension,
>    following the conventions established in [RFC5912] and [RFC6268].
>
> I guess both 5912 and 6269 should be listed as normative.

ack

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # JSON/CBOR encoding and Mapping
>
> As both encoding are specifically provided in the spec, are there any
> deviations/implications if an implementation decide to follow the rules such as
> in rfc8949#section-3.4.5.2 for mapping the two?
>
> Maybe worth to add a note?

Apologies, I don't see how those tags would interact with CMW.

> # To ensure extensibility with interop, I guess “can add” language should be
> better strengthened (e.g., “is recommended to add” or the like)
>
> CURRENT:
>    Future specifications that extend the RATS Conceptual Messages set
>    can add new values to the cm-type using the process defined in
>    Section 10.4.

ack

> # Recursion Limit
>
> CURRENT:
>    Since the Collection CMW is recursive (a Collection CMW is itself a
>    CMW), implementations MAY limit the allowed depth of nesting.
>
> Can that be controlled? Can we ask an implem to expose the nesting depth it
> supports or it actually imposes?

Perhaps an API that uses CMW could add "max-cmw-depth" as a
discoverable attribute, allowing applications to advertise their own
limits.
Or, a protocol using CMW could require a minimum depth from its users.
However, it'd be up to them to specify this.

> # Further highlight this is an example
>
> OLD:
>    func CMWTypeDemux(b []byte) CMWType {
>
> NEW:
>    func example-CMWTypeDemux(b []byte) CMWType {

ack

> #  These two MUSTs are redundant
>
> CURRENT:
>    The CMW extension MUST have the following syntax:
>
>    CMW ::= CHOICE {
>        json UTF8String,
>        cbor OCTET STRING
>    }
>
>    The CMW MUST include the serialized CMW object in either JSON or CBOR
>    format, utilizing the appropriate CHOICE entry.

ack

> # Unfolding
>
> CURRENT:
>    with the following wire representation:
>
>    =============== NOTE: '\' line wrapping per RFC 8792 ================
>
> Please add 8792 to the list of references as this is needed to unfold the
> example.

ack

> # Nits
>
> ## Expand RATS in the title.
>
> ## Please help readers to find where to locate for Passport and
> Background-check models: Pointing to Section 5.1 and 5.2 of 9334 in the text
> would be helpful.

ack

> ## Section 4.2
>
> OLD:
>    The protected header MUST include the signature algorithm identifier.
>    The protected header MUST include the content type application/
>    cmw+json.
>
> NEW:
>    The protected header MUST include the signature algorithm identifier and
>    the content type application/cmw+json.

ack

Again, thanks very much!

>
> Cheers,
> Med
>
>
>