[COSE] Re: Example EDN in draft-ietf-cose-merkle-tree-proofs-17

[Orie <[e-mail]>]

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 <[e-mail]> please check PR : )

Regards,

OS

On Mon, Oct 20, 2025 at 11:33 AM Carsten Bormann <[e-mail]> wrote:

> On 2025-10-19, at 16:49, Orie <[e-mail]> 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
>
>
>