After checking with Henk, I believe no cut operator is necessary in the COSE Receipts CDDL, because it contains no optional labels. I have closed #102, and opened https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/pull/103, which is a pure consistency update, without any semantic impact.
Thank you, Amaury ________________________________ From: Amaury Chamayou <[email protected]> Sent: 01 December 2025 14:23 To: Orie <[email protected]>; Rohan Mahy <[email protected]> Cc: Carsten Bormann <[email protected]>; Henk Birkholz <[email protected]>; cose <[email protected]> Subject: Re: [EXTERNAL] [COSE] Re: Example EDN in draft-ietf-cose-merkle-tree-proofs-17 Considering the description of cut (https://www.rfc-editor.org/rfc/rfc8610#section-3.5.4) and the examples given, it's not obvious that the cut operator is necessary here since there are no optional values. If alg was optional, there would be a risk that * cose.label would allow an alg with an alternative and incompatible type, but not in this case? Still, in case I missed something, here's the change: https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/pull/102 RFC9052 doesn't seem to use cut, even for optional labels: https://www.rfc-editor.org/rfc/rfc9052.html#name-key-objects COSE_Key = { 1 => tstr / int, ; kty ? 2 => bstr, ; kid ? 3 => tstr / int, ; alg ? 4 => [+ (tstr / int) ], ; key_ops ? 5 => bstr, ; Base IV * label => values } So this bit of CDDL would seemingly allow a COSE_Key with labels 2 to 5 set to basically any value, according to https://www.rfc-editor.org/rfc/rfc8610#section-3.5.4, which seems unlikely to be the intent. Amaury ________________________________ From: Orie <[email protected]> Sent: 18 November 2025 18:21 To: Rohan Mahy <[email protected]> Cc: Carsten Bormann <[email protected]>; Henk Birkholz <[email protected]>; cose <[email protected]> Subject: [EXTERNAL] [COSE] Re: Example EDN in draft-ietf-cose-merkle-tree-proofs-17 I don't know... I just know that it validated the files in the PR. It would be excellent if someone could test this against their receipt implementation if they have one in CBOR that is not RFC9162_SHA256. Regards, OS On Sat, Nov 15, 2025 at 6:08 PM Rohan Mahy <[email protected]<mailto:[email protected]>> wrote: Hi Orie, In the CDDL, don't you want a cut (^) in front of the => operator for each of the name/value pairs with an explicit integer map key? Also, it seems weird to use the plural cose-values for a single value (there is a quanitifer allowing multiple pairs of cose-label/cose-values). thanks, -rohan On Sat, 15 Nov 2025, 22:45 Orie, <[email protected]<mailto:[email protected]>> wrote: Hi, I have addressed the kid issue: https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/pull/99 I think I fixed the CDDL issues, by interpreting the wizardry present in https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/ @Henk Birkholz<mailto:[email protected]> please check PR : ) Regards, OS On Mon, Oct 20, 2025 at 11:33 AM Carsten Bormann <[email protected]<mailto:[email protected]>> wrote: On 2025-10-19, at 16:49, Orie <[email protected]<mailto:[email protected]>> wrote: > > I was looking at > https://www.ietf.org/archive/id/draft-ietf-cose-merkle-tree-proofs-17.txt > > And I notice that kid is shown here as a base64url encoded string. > > This seems like an unfortunate choice, and it would be better if it was just > h'abcd...ef' instead. > > Should we make an adjustment to the EDN to address this? > > I filled > https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/issues/98 to > track this. I was hoping to do a quick validation of the EDN and the CDDL. That appears to be a bit more work than I thought, so I won’t complete it today. The CDDL for Receipt has a mandatory endless recursion (fix this). verifiable-proofs has two different rules, so you can’t simply use all the CDDL at once (nobody promises you can do that, but it is good practice); this also leads to a bit of redundant CDDL. The key identifiers in the usage figure are labeled “key” in the comments, while they are “kid” parameters as per RFC 9052 (it’s a comment, but please fix this). The key identifiers given are text strings, while the CDDL definition in Section 3.1 says they need to be byte strings (must be fixed). Replacing / key / 4 : "vCl7UcS0ZZY99VpRthDc-0iUjLdfLtnmFqLJ2-Tt8N4", by / kid / 4 : b64'vCl7UcS0ZZY99VpRthDc-0iUjLdfLtnmFqLJ2-Tt8N4', would already work, but maybe $ edn-abnf -e "b64'vCl7UcS0ZZY99VpRthDc-0iUjLdfLtnmFqLJ2-Tt8N4'" h'BC297B51C4B465963DF55A51B610DCFB48948CB75F2ED9E616A2C9DBE4EDF0DE' / kid / 4 : h'BC297B51...E4EDF0DE', …would indeed work best. Grüße, Carsten _______________________________________________ COSE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
