Re: [Rats] Initiating WGLC for draft-ietf-rats-msg-wrap-03

[Thomas Fossati <[e-mail]>]

Hi Carl, thanks a lot for the feedback.

On Thu, 8 Feb 2024 at 12:16, Carl Wallace <[e-mail]> wrote:
> In section 5, it may be worth calling out that the encoded CMWCollection is encoded as an OCTET STRING as the extnValue field of this extension. Section 4.2 in RFC5280 makes this point but I’ve seen the outer OCTET STRING left out in a couple of attestation-related contexts. The pseudo code about removing “the ASN.1 OCTET STRING” in Section 3.3. could further this misimpression since there are two OCTET STRING layers wrapping a CBOR value. Maybe add something like: “The DER encoded CMWCollection is the value of the octet string for the extnValue field of the extension”.

Awesome. Tracked here:
https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/64

> The security considerations section says that “messages themselves and their encoding ensure security protection.” This is not true for UCCS, which is part of the referenced EAT media type spec.

You are of course right. Tracked here (alongside another security
consideration):
https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/63

> I think this came up relative to the collections draft a while back but I forget how it was handled (and did not go looking just now). How would one encode artifacts that use different encoding types, i.e., a CBOR evidence and a JSON result? The collection concept is analogous to the submodules part of EAT, and that addresses the various nesting possibilities.

Yes, Dionna started that conversation here:
https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/55 and
we are trying to converge on some sort of "tunnelling" design

cheers!