[Rats] Re: AD comments on draft-ietf-rats-msg-wrap

[Laurence Lundblade <[e-mail]>]

> On Sep 22, 2025, at 11:06 AM, Thomas Fossati <[e-mail]> wrote:
> 
> Hi Laurence!

Hi. Sorry to be disruptive...


> On Mon, 22 Sept 2025 at 18:34, Laurence Lundblade <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> On Sep 22, 2025, at 8:34 AM, Thomas Fossati <[e-mail]> wrote:
>> 
>> Section 3.1:  Record CMWs can only be JSON or CBOR?  No other conceptual message representations are possible?
>> 
>> 
>> Yes.  CMWs only have CBOR and JSON representations.  There was an
>> attempt to define an ASN.1 CMW (see [1]), but the working group was
>> not particularly enthusiastic about it, so we did not pursue it
>> further.
>> 
>> [3] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/wiki/CMW-in-ASN.1
>> 
>> 
>> I am enthusiastic about ASN.1 support. I think it will be needed in the long run. The principle is:
>> - JSON because it is widely used
>> - CBOR because it is efficient, modern and compact
>> - ASN.1 because so many security environments are ASN.1 only (certifications and such)
>> - Absolutely no other encodings because this isn’t let 1,000 flowers bloom; just what is necessary
>> 
>> I also think it is important that it not diverge in semantics from CBOR and JSON. Said another way, we don’t have to discuss semantics. They are already defined. We just need the encoding.
>> 
>> I know Mike O and his project is not enthusiastic about this, but we can do it without them. We have enough expertise in the group without them. We also really do not want any ASN.1 defined by other projects to have divergent semantics from the CBOR and JSON semantics.
>> 
>> If there is urgency to get CMW done sooner, rather than later and ASN.1 would be too much of a delay, I understand, but I prefer the idea of taking care of all the encoding at once and in one document.
> 
> We discussed this a while ago, but I would like to restate the reasons
> why I believe we should not add the ASN.1 CMW to this document:
> (1) We do not yet have the buy-in from the "natural" stakeholders,
> i.e., Mike O. and the PKIX crew.

I think this is a non-issue:

A) We have enough ASN.1 expertise to do the job without them.

B) We will not, MUST not, change the CMW semantics for Mike O and the PKIX team. It would be very bad to have the CMW semantics different depending on the encoding. Mike O and the PKIX have to live with the CMW semantics now defined. 


> (2) We need the current CMW feature set in more than one place: aTLS,
> aCSR, Arm CCA attestation, device assignment and more, and we need it
> now.

I understand and maybe that is the overriding reason.


> In case we manage to unlock (1), we could quickly put together a
> separate document that updates CMW.
> I would be more than happy to help draft such a document.

There is some effort saving both for us writing documents and those reading documents if it is all done in one place.

LL