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]> 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]> 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 <[email protected]> please check PR : ) >> >> Regards, >> >> OS >> >> On Mon, Oct 20, 2025 at 11:33 AM Carsten Bormann <[email protected]> wrote: >> >>> On 2025-10-19, at 16:49, Orie <[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] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
