[auth48] Re: [EXTERNAL] [AD] [C557] Cluster-Wide AUTH48 Questions: draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942) and draft-ietf-scitt-architecture-22 (RFC-to-be 9943)

[Orie <[e-mail]>]

On Fri, Jun 5, 2026 at 6:20 PM Megan Ferguson <
[e-mail]> wrote:

> Henk, Antoine, and Orie, (and *AD),
>
> [*AD - please note that this document has had several updates to code.
> Please review/approve all changes to code highlighted in the AUTH48 diff
> below.]
>
> After some forensic email searching / editing work, I *think* the version
> posted below encompasses all the desired changes we’ve received to date.
> Please review *extra* carefully and let us know if anything is missing
> and/or updated incorrectly.
>
> Going forward, **please base any edits of the linked edited XML version**
> (see below).
>
> Some known clean up:
>
> We were unsure if the following changes that do not currently appear in
> the current XML file were intentionally removed or if they should be
> reinstated:
>
> 1) See the following in Figure 6:
>
> >>> In Figure 6.
> >>>
> >>> The other in Figure 2, where the value of 394 (receipts) ought to be
> an array:
> >>>
> >>>      / receipts / 394 : {
> >>>        << ... >>
> >>>       }
> >>>
> >>>
> >>> Should be:
> >>>
> >>>      / receipts / 394 : {         [ << ... >> ]
> >>>       }
>
>
> Current:
>     / receipts / 394 : [
>       <</ cose-sign1 / 18([
>
>
Current appears correct.


>
> 2) We believe that the use of # in the EDN (it was switched to “/" at one
> point) is intentional (so that an ending delimiter is not necessary).
> Please review and confirm.  Related author communication summarized below
> for convenience:
> > Finally, several EDN snippets (Figures 2, 6 and 9) incorrectly use #
> comment, when the correct EDN syntax is / comment /. For example:
> > / algorithm / 1 : -7,  # ES256
> >
> >
> > Should be:
> >
> > / algorithm / 1 : -7,  / ES256 /
>
> However, later:
>
> > Furthermore, the EDN is currently broken. An EDN comment that starts
> with a "/" must also end with a "/". Alternatively, at the end of a line a
> comment that starts with a "#" does not require an ending delimiter. I'd
> prefer using "#" when there is a comment at the end of a line.
>
>
I don't have a strong preference, if switching to "/" instead of "#" helps,
that's fine.

Note that "#" is valid for:
https://datatracker.ietf.org/doc/html/draft-ietf-cbor-edn-literals-25#section-2.2


>
>
> 3) Please review the use of commas in the CDDL and let us know if any
> further changes are desired:
>
> > Currently, all CDDL definitions use comma inconsistently. This not
> "wrong" but really bad style. In my opinion, we should get rid of all
> commas.
>
>
@Henk Birkholz <[e-mail]> said he prefers to remove the
commas, lets go with his recommendation.


>
>
> 4) Regarding the follow up questions we had sent April 14, we have made
> some related updates.  Please review and confirm the following:
>
> -edited our previously suggested sentence to the Terminology section to
> remove “to-be-signed bytes”.
> -added a sentence to the Terminology section regarding the term “claim”.
> -updated the reference to RFC 9052 to instead point to STD 96 to match the
> previously accepted additional sentence to the Terminology section.
> -made the update described in (5) below.
> -still have the question described in (6) below.
>
> Other than these issues, we believe all of our concerns from that mail
> have been resolved.
>

Thank you!!!


>
> 5) Regarding this question/answer pair from April 14:
>
> <!--[rfced] This sentence doesn't seem to parse.  Please rephrase.
>
> Original:
> First the verifier applies the inclusion proof to a possible entry
> (set member) bytes.
>
> -->
>
> <!--[authors] We think the current sentence with the comma parses
> correctly.
> —>
>
> This text still does not parse for us… Please review and approve our
> further update to the first sentence of Section 4.2.


> Previous:
>
>    Similar to COSE Key Type Parameters [IANA.cose_header-parameters],
>    for example EC2 keys (1: 2) require and give meaning to specific
>    parameters, such as -1 (crv), -2 (x), -3 (y), -4 (d).
> Current:
>    As is the case for COSE Key Type Parameters
>    [IANA.cose_header-parameters], EC2 keys (1: 2) require and give
>    meaning to specific parameters, such as -1 (crv), -2 (x), -3 (y), and
>    -4 (d).  RFC9162_SHA256 (395: 1) supports both (-1) inclusion and
>    (-2) consistency proofs.
>
> 6) Regarding the following query/response from April 14:
>
> <!--[rfced] This sentence doesn't seem to parse.  Please rephrase.
>
> Original:
> First the verifier applies the inclusion proof to a possible entry
> (set member) bytes.
>
> -->
> <!--[authors] We think the current sentence with the comma parses
> correctly.
> -->
>
> Can you let us know how “(set member) bytes" relates to the sentence?  If
> you remove the parenthetical, it would read as:
>
> First the verifier applies the inclusion proof to a possible entry bytes.
>

Perhaps:

The sentence needs its adjacent context to parse well:

OLD:

   The inclusion proof and signature are verified in order.  First, the
   verifier applies the inclusion proof to a possible entry (set member)
   bytes.  If this process fails, the inclusion proof may have been
   tampered with.  If this process succeeds, the result is a Merkle Tree
   root, which is then attached as the COSE_Sign1 payload.  Second, the
   verifier checks the signature of the COSE_Sign1.  If the resulting
   signature can be verified, the Receipt has proved inclusion of the
   entry in the VDS.  If the resulting signature cannot be verified, the
   signature may have been tampered with.

NEW

Verification of the inclusion proof and signature occurs in two sequential
steps:

- Inclusion Proof Verification: The verifier applies the inclusion proof to
the bytes of a candidate entry. If this fails, the proof is invalid. If it
succeeds, the resulting Merkle tree root becomes the COSE_Sign1 payload.

- Signature Verification: The verifier checks the COSE_Sign1 signature.
Successful verification confirms the entry's inclusion in the VDS;
otherwise, the signature is invalid.




>
> Again, apologies for any confusion in the crossed mails/versions, but
> please review more carefully than usual and let us know if we’ve bundled
> anything here.
>
>
Thank you!


>
>   The files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9942.txt
>    https://www.rfc-editor.org/authors/rfc9942.pdf
>    https://www.rfc-editor.org/authors/rfc9942.html
>    https://www.rfc-editor.org/authors/rfc9942.xml
>
>   The diff files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9942-diff.html (comprehensive)
>    https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html (side by side)
>
>    https://www.rfc-editor.org/authors/rfc9942-auth48diff.html (AUTH48
> changes only)
>    https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html (side by
> side)
>
>    https://www.rfc-editor.org/authors/rfc9942-lastdiff.html (last version
> to this)
>    https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html (side by
> side)
>
>   The Final Review page for this document is viewable at:
>
>
> Thank you.
>
> Megan Ferguson
> RFC Production Center
>
> > On Jun 4, 2026, at 8:39 AM, Henk Birkholz <[e-mail]>
> wrote:
> >
> > +1
> >
> > this aligns with Carsten's input from April!
> >
> > On 04.06.2026 16:36, Antoine Delignat-Lavaud wrote:
> >> Hi Megan,
> >> From our review we believe that all the changes I submitted in my
> previous XML are already in the Editor's XML https://auth48-
> transition.rfc-editor.org/authors/rfc9942.xml <https://auth48-
> transition.rfc-editor.org/authors/rfc9942.xml> so no further action is
> required from my submission.
> >> However, I agree that we should take the EDN changes from Orie in his
> email below (https://github.com/cose-wg/draft-ietf-cose-merkle-tree-
> proofs/blob/dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml <
> https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/blob/
> dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml>) before
> closing the AUTH48 process.
> >> Best,
> >> Antoine
> >> ------------------------------------------------------------------------
> >> *From:* Orie <[e-mail]>
> >> *Sent:* Thursday, June 4, 2026 13:55
> >> *To:* Megan Ferguson <[e-mail]>
> >> *Cc:* Henk Birkholz <[e-mail]>; Antoine Delignat-
> Lavaud <[e-mail]>; [e-mail] <[e-mail]>;
> Cedric Fournet <[e-mail]>; Yogesh Deshpande <
> [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <rfc-editor@rfc-
> editor.org>; [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>;
> Amaury Chamayou <[e-mail]>; [e-mail]
> <scitt- [e-mail]>; [e-mail] <[e-mail]>; Deb
> Cooley <[e-mail]>; [e-mail]
> <auth48archive@rfc- editor.org>
> >> *Subject:* Re: [EXTERNAL] [AD] [C557] Cluster-Wide AUTH48 Questions:
> draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942) and draft-ietf-
> scitt-architecture-22 (RFC-to-be 9943)
> >> Hi,
> >> I've corrected the broken examples here: https://github.com/cose-wg/
> draft-ietf-cose-merkle-tree-proofs/blob/
> dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml <https://
> github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/blob/
> dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml>
> >> Let me know if there is anything else I can help with.
> >> Regards,
> >> OS
> >> On Thu, Apr 23, 2026 at 5:42 PM Megan Ferguson <[e-mail]-
> editor.org <mailto:[e-mail]>> wrote:
> >>    Hi Henk and Antoine,
> >>    Note that Antoine had submitted an XML file that we were wanting to
> >>    confirm was the intended file - we can fold the change described in
> >>    #1 of your message into that file once we receive confirmation it
> >>    was the intended file (or into a new XML file if Antoine sends it
> >>    (see our message sent 17 April for details)).
> >>    The change to fold in:
> >>    Old:
> >>    The following definition from [RFC8610] is provided:
> >>    New:
> >>    Figure 1 defines how Receipts are included in a COSE_Sign1 data item:
> >>    (We have updated our current file with the change in the meantime,
> >>    but making sure this is flagged and not lost in the mix.)
> >>    With regard to #2, as these updates to code may be beyond editorial,
> >>    we would prefer if the authors made these changes directly in the
> >>    XML file (available at the link below but with coordination with
> >>    Antoine’s XML version in mind).  These changes have NOT been made.
> >>    For #3, glad you were happy with the change :)
> >>    Below are links to our current versions of the file (not updated
> >>    with Antoine’s changes until we hear back on the above issue):
> >>       The files have been posted here (please refresh):
> >>    https://www.rfc-editor.org/authors/rfc9942.txt <https://www.rfc-
> >>    editor.org/authors/rfc9942.txt>
> >>    https://www.rfc-editor.org/authors/rfc9942.pdf <https://www.rfc-
> >>    editor.org/authors/rfc9942.pdf>
> >>    https://www.rfc-editor.org/authors/rfc9942.html <https://www.rfc-
> >>    editor.org/authors/rfc9942.html>
> >>    https://www.rfc-editor.org/authors/rfc9942.xml <https://www.rfc-
> >>    editor.org/authors/rfc9942.xml>
> >>       The files have been posted here (please refresh):
> >>    https://www.rfc-editor.org/authors/rfc9942-diff.html <https://
> >>    www.rfc-editor.org/authors/rfc9942-diff.html>
> >>    https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html <https://
> >>    www.rfc-editor.org/authors/rfc9942-rfcdiff.html> (side by side)
> >>    https://www.rfc-editor.org/authors/rfc9942-auth48diff.html <https://
> >>    www.rfc-editor.org/authors/rfc9942-auth48diff.html>
> >>    https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html
> >>    <https://www.rfc-editor.org/authors/rfc9942-
> >>    auth48rfcdiff.html> (side by side)
> >>    https://www.rfc-editor.org/authors/rfc9942-lastdiff.html <https://
> >>    www.rfc-editor.org/authors/rfc9942-lastdiff.html>
> >>    https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html
> >>    <https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html> (side
> >>    by side)
> >>    The AUTH48 status page for this document is available here:
> >>    https://www.rfc-editor.org/auth48/rfc9942 <https://www.rfc-
> >>    editor.org/auth48/rfc9942>
> >>    The AUTH48 status page for this cluster is available here:
> >>    https://www.rfc-editor.org/auth48/C557 <https://www.rfc-editor.org/
> >>    auth48/C557>
> >>    Thank you.
> >>    Megan Ferguson
> >>    RFC Production Center
> >>     > On Apr 23, 2026, at 9:06 AM, Henk Birkholz
> >>    <[e-mail]> wrote:
> >>     >
> >>     > Hi Megan,
> >>     >
> >>     > from here on I am referring the the approved part (left) of this
> >>    link:
> >>     >
> >>     >> https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html
> >>    <https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html>
> >>     >
> >>     >
> >>     > (1) Introducing CDDL definitions
> >>     >
> >>     > "The following definition from [RFC8610] is provided:"
> >>     >
> >>     > is obviously wrong. Not sure where that happened on the way. Also
> >>    we should not use the passive here.
> >>     >
> >>     > This should say, e.g. "Figure 1 defines how Receipts are included
> >>    in a COSE_Sign1 data item:"
> >>     >
> >>     > The CDDL reference is already introduced somewhere above.
> >>     >
> >>     > (2) END in general
> >>     >
> >>     > Currently, all CDDL definitions use comma inconsistently. This
> >>    not "wrong" but really bad style. In my opinion, we should get rid
> >>    of all commas.
> >>     >
> >>     > Furthermore, the EDN is currently broken. An EDN comment that
> >>    starts with a "/" must also end with a "/". Alternatively, at the
> >>    end of a line a comment that starts with a "#" does not require an
> >>    ending delimiter. I'd prefer using "#" when there is a comment at
> >>    the end of a line.
> >>     >
> >>     > (3) In the EDN Figure 1
> >>     >
> >>     > The change from "{" to "[" is a nice catch. Thanks!
> >>     >
> >>     >
> >>     > Viele Grüße,
> >>     >
> >>     > Henk
> >>     >
> >>     >
> >>     > On 17.04.2026 20:16, Megan Ferguson wrote:
> >>     >> Hi Antoine,
> >>     >> Thanks for your reply.
> >>     >> I want to confirm that the XML attached is the one you were
> >>    meaning to send?
> >>     >> Asking because:
> >>     >> -Looks like the most recent changes we applied (sent 14 April)
> >>    were not included (e.g., the alphabetizing of the Terminology
> >>    section, etc.).
> >>     >> -Some other changes from previous versions seem to be reverted
> >>    (e.g., = /6.18(COSE_Sign1) has been changed back to
> #6.18(COSE_Sign1).
> >>     >> -We don’t see responses or action taken on our questions sent 14
> >>    April.
> >>     >> -There don’t seem to be new changes (most all of the things that
> >>    appear to have been changed have been touched before).
> >>     >> You can see a diff between the most recent version we had sent
> >>    on 14 April and the file you just sent at:
> >>     >> https://www.rfc-editor.org/authors/rfc9942question2-diff.html
> >>    <https://www.rfc-editor.org/authors/rfc9942question2-diff.html>
> >>     >> A diff between our 2nd-to-last version and the file you just
> >>    sent is viewable here:
> >>     >> https://www.rfc-editor.org/authors/rfc9942question1-diff.html
> >>    <https://www.rfc-editor.org/authors/rfc9942question1-diff.html>
> >>     >> Please let us know which of the following ways forward would
> >>    work best:
> >>     >> 1) This XML was sent in error, a new one will be submitted by
> >>    the authors.
> >>     >> 2) The mail just got crossed, the authors want the changes in
> >>    the RPC’s most recent version plus the updates (mostly revisions)
> >>    that were in the attached XML file (i.e., I can update our files to
> >>    include the changes highlighted in the second diff above). Note: if
> >>    this is the case, can you please also overtly respond to the
> >>    questions from 14 April so that we can close them out?
> >>     >> 3) The authors reject the changes in the RPC’s most recent
> >>    version and prefer the version in the most recent XML file instead.
> >>    Please also reply overtly to the questions so we can close them out.
> >>     >> Thanks!
> >>     >> Megan Ferguson
> >>     >> RFC Production Center
> >>     >>> On Apr 17, 2026, at 7:31 AM, Antoine Delignat-Lavaud
> >>    <[e-mail] <mailto:[e-mail]>> wrote:
> >>     >>>
> >>     >>> Dear Megan,
> >>     >>>
> >>     >>> Please find attached our latest corrections in XML. This
> >>    addresses all remaining editor comments and also corrects a few
> >>    additional editorial mistakes we found.
> >>     >>>
> >>     >>> I will send a separate update for 9943.
> >>     >>>
> >>     >>> Best,
> >>     >>> Antoine
> >>     >>> (on behalf of the authors)From: Megan Ferguson
> >>    <[e-mail] <mailto:
> [e-mail]>>
> >>     >>> Sent: Thursday, April 16, 2026 19:43
> >>     >>> To: Antoine Delignat-Lavaud <[e-mail]
> >>    <mailto:[e-mail]>>
> >>     >>> Cc: [e-mail]
> >>    <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>;
> >>    [e-mail]<[e-mail]>; Cedric
> >>    Fournet <[e-mail] <mailto:[e-mail]>>;
> >>    Yogesh Deshpande <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail] <mailto:cose-
> >>    [e-mail]> <[e-mail] <mailto:[e-mail]>>; cose-
> >>    [e-mail] <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>; Amaury Chamayou
> >>    <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]> <[e-mail] <mailto:scitt-
> >>    [e-mail]>>; [e-mail] <mailto:scitt-
> >>    [e-mail]> <[e-mail] <mailto:scitt-
> >>    [e-mail]>>; Deb Cooley <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>
> >>     >>> Subject: Re: [EXTERNAL] [AD] [C557] Cluster-Wide AUTH48
> >>    Questions: draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942)
> >>    and draft-ietf-scitt-architecture-22 (RFC-to-be 9943)
> >>     >>>  Hi Antoine,
> >>     >>>
> >>     >>> No problem!  Thanks for letting us know and we will wait to
> >>    hear from you.
> >>     >>>
> >>     >>> Megan Ferguson
> >>     >>> RFC Production Center
> >>     >>>
> >>     >>>> On Apr 16, 2026, at 11:05 AM, Antoine Delignat-Lavaud
> >>    <[e-mail] <mailto:[e-mail]>> wrote:
> >>     >>>>
> >>     >>>> Hi Megan,
> >>     >>>>
> >>     >>>> Many thanks for the extra feedback.
> >>     >>>>
> >>     >>>> We have a number of changes we are preparing following the
> >>    latest round of feedback that we will submit tomorrow. To avoid
> >>    conflicts we request that you hold off on further editing until we
> >>    have submitted the revisions.
> >>     >>>>
> >>     >>>> Best,
> >>     >>>> Antoine
> >>     >>>>
> >>     >>>> -----Original Message-----
> >>     >>>> From: Megan Ferguson <[e-mail]
> >>    <mailto:[e-mail]>>
> >>     >>>> Sent: 14 April 2026 21:52
> >>     >>>> To: Antoine Delignat-Lavaud <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>
> >>     >>>> Cc: [e-mail] <mailto:[e-mail]>;
> >>    [e-mail]; Cedric Fournet <[e-mail]
> >>    <mailto:[e-mail]>>; Yogesh Deshpande
> >>    <[e-mail] <mailto:[e-mail]>>;
> >>    [e-mail] <mailto:[e-mail]>; rfc-
> >>    [e-mail] <mailto:[e-mail]>; cose-
> >>    [e-mail] <mailto:[e-mail]>; [e-mail]
> >>    <mailto:[e-mail]>; [e-mail]
> >>    <mailto:[e-mail]>; Amaury Chamayou
> >>    <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>; [e-mail] <mailto:scitt-
> >>    [e-mail]>; Deb Cooley <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>
> >>     >>>> Subject: [EXTERNAL] Re: [AD] [C557] Cluster-Wide AUTH48
> >>    Questions: draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942)
> >>    and draft-ietf-scitt-architecture-22 (RFC-to-be 9943)
> >>     >>>>
> >>     >>>> Hi Antoine and *AD (*Paul),
> >>     >>>>
> >>     >>>> [*Paul - Would you please review and approve the removal of
> >>    text from Section 6 of RFC-to-be 9942?  ]
> >>     >>>>
> >>     >>>> Thank you for the updated file!
> >>     >>>>
> >>     >>>> We had some follow-up questions/comments for you to review:
> >>     >>>>
> >>     >>>> 1) We had asked about text additions to the Terminology
> section:
> >>     >>>>
> >>     >>>> a) Regarding the addition of the following to the Terminology
> >>    section:
> >>     >>>>
> >>     >>>>   The terms "header", "payload", and "to-be-signed bytes" are
> >>    defined
> >>     >>>>   in [STD96].
> >>     >>>>
> >>     >>>> We have updated to use the following (as to-be-signed bytes
> >>    does not appear in this document):
> >>     >>>>
> >>     >>>>   The terms “header" and "payload" are defined in [STD96].
> >>     >>>>
> >>     >>>> Note also that we ended up having to change the following
> >>    citation to RFC 9052, which is part of [STD96], and have updated the
> >>    References section to list STD 96 normatively and RFC 9052 only
> >>    within STD 96:
> >>     >>>>
> >>     >>>> Original:
> >>     >>>> A COSE Single Signer Data Object, as defined in [RFC9052],
> >>    containing the header parameters necessary to convey one or more VDP
> >>    for an associated VDS.
> >>     >>>>
> >>     >>>> Current:
> >>     >>>> A COSE Single Signer Data Object, as defined in RFC 9052
> >>    [STD96], containing the header parameters necessary to convey one or
> >>    more VDP for an associated VDS.
> >>     >>>>
> >>     >>>> Please let us know any objections/concerns.
> >>     >>>>
> >>     >>>> b) Please let us know if the following should also be added to
> >>    the Terminology section:
> >>     >>>>
> >>     >>>> The term "claim" is defined in [RFC8392].
> >>     >>>>
> >>     >>>> Note that RFC 8392 is already referenced.
> >>     >>>>
> >>     >>>> 2) Regarding the following query:
> >>     >>>>
> >>     >>>> <!--[rfced] This sentence doesn't parse.  Please let us know
> >>    how to
> >>     >>>>     update.
> >>     >>>>
> >>     >>>> Original:
> >>     >>>> ...such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256
> >>    (TBD_1 (requested assignment 395) : 1) supports both (-1) inclusion
> >>    and (-2) consistency proofs.
> >>     >>>> -->
> >>     >>>>
> >>     >>>> <!-- [authors] We have updated the sentence as follows for
> >>    clarity:
> >>     >>>>
> >>     >>>> ...for example EC2 keys (1: 2) require and give meaning to
> >>    specific parameters, such as -1 (crv), -2 (x), -3 (y), -4 (d).
> >>    RFC9162_SHA256 (395: 1) supports both (-1) inclusion and (-2)
> >>    consistency proofs.
> >>     >>>>
> >>     >>>> Please let us know if you have any further suggestions. —>
> >>     >>>>
> >>     >>>> [rfced] We believe the meaning of the text is that Proofs are
> >>    similar to COSE Key Type Parameters because for both of them, EC2
> >>    keys (1: 2) require and give meaning to specific parameters.  An
> >>    example of that being -1 (crv), -2 (x), -3 (y), and -4 (d).
> >>     >>>>
> >>     >>>> We have updated the text to fit the above; please see our
> >>    updates and let us know if the current text conveys your intended
> >>    meaning.
> >>     >>>>
> >>     >>>>
> >>     >>>> 3) Regarding the following query:
> >>     >>>>
> >>     >>>> <!--[rfced] This sentence doesn't seem to parse.  Please
> rephrase.
> >>     >>>>
> >>     >>>> Original:
> >>     >>>> First the verifier applies the inclusion proof to a possible
> >>    entry (set member) bytes.
> >>     >>>>
> >>     >>>> -->
> >>     >>>> <!--[authors] We think the current sentence with the comma
> >>    parses correctly.
> >>     >>>> -->
> >>     >>>>
> >>     >>>> Can you let us know how “(set member) bytes" relates to the
> >>    sentence?
> >>     >>>>
> >>     >>>>
> >>     >>>> The files below have been updated with all other requests.
> >>     >>>>
> >>     >>>> Please review carefully as we do not make changes once the
> >>    document is published as an RFC.
> >>     >>>>
> >>     >>>>  The files have been posted here (please refresh):
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966148880%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r4DIPKy4A51NEYLSt37ZLKv5EDL%2FxygdFTVBJ7s%2FZYw%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.txt>
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966204186%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pF2Gd6Z6KsnvuMW6qbx8YPx33lbGRBjjAHFmCN8MsX8%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.pdf>
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966258528%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FXaX%2BNva2Zt30IYNDPJzbCoqtKvwvNlCShmWv73AF3Q%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.html>
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966292714%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zlkgpxcvnhQPTm61ibjbUEPFbH1pK1VcxnwBeCCb1CQ%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.xml>
> >>     >>>>
> >>     >>>>  The diff files have been posted here (please refresh):
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966319736%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cMdRSjokKj8NkfdX6fRqq4%2F0rG%2BRARw3IirM%2FM40C8A%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-diff.html>
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966339679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QdufwmRO4W9ZXPP75%2BP%2BBE2EuUBkgpaCai8Mke7TXHY%3D&reserved=0(side
> <https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html> by side)
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    auth48diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966357832%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=h6OFjLIsSG0HRpnWtdVa425KYVLM1DIrPO6p6bzxErs%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-auth48diff.html>
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    auth48rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966377508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3%2BQy1%2BemdWPDD9FsVSeXNRYm3loUGcbJG5mKaxvPHKI%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html> (side by
> side)
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    lastdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966397952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Nz9zBQ5BinChOSCBs8AK8J2LmsGiNNJatNre%2F%2BEaiyg%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-lastdiff.html>
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    lastrfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966417496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fmDfferopj6deReTsUs6CH%2FB7xdQYzkey%2F8aZkM9Qn0%3D&reserved=0(side
> <https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html> by side)
> >>     >>>>
> >>     >>>> The AUTH48 status page for this document is available here:
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966436825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lmpG%2FPq5DZSUPpCVw5smdEnURPpul%2BA7qk8ZpxUfZtA%3D&reserved=0
> <https://www.rfc-editor.org/auth48/rfc9942>
> >>     >>>>
> >>     >>>> The AUTH48 status page for this cluster is available here:
> >>     >>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauth48%2FC557&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966458747%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Za8iNKgbsahg2gNR2ip3ZzD2uD4xj1Y82qR2BT3C3fA%3D&reserved=0
> <https://www.rfc-editor.org/auth48/C557>
> >>     >>>>
> >>     >>>> Thank you.
> >>     >>>>
> >>     >>>> Megan Ferguson
> >>     >>>> RFC Production Center
> >>     >>>>
> >>     >>>>
> >>     >>>>
> >>     >>>>> On Apr 14, 2026, at 8:52 AM, Antoine Delignat-Lavaud
> >>    <[e-mail] <mailto:[e-mail]>> wrote:
> >>     >>>>>
> >>     >>>>> Hi Megan,
> >>     >>>>>
> >>     >>>>> Many thanks for the updates. We have taken an additional pass
> >>    on the remaining questions and addressed them in further updates
> >>    that we have batched in the attached XML.
> >>     >>>>>
> >>     >>>>> We agree about the issues in Figure 2 and 6 that you pointed
> >>    out. In addition to the attached fix, we believe the fix for 394/
> >>    receipts format also requires a corresponding change to 9943 that I
> >>    will submit separately on the AUTH48 thread for 9943.
> >>     >>>>>
> >>     >>>>> Best,
> >>     >>>>> AntoineFrom: Megan Ferguson <[e-mail]
> >>    <mailto:[e-mail]>>
> >>     >>>>> Sent: Thursday, April 2, 2026 00:49
> >>     >>>>> To: [e-mail] <mailto:[e-mail]> <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>     >>>>> <[e-mail]>; Antoine Delignat-Lavaud
> >>     >>>>> <[e-mail] <mailto:[e-mail]>>; Cedric
> >>    Fournet <[e-mail] <mailto:[e-mail]>>;
> Yogesh
> >>     >>>>> Deshpande <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>
> >>     >>>>> <[e-mail] <mailto:[e-mail]>>
> >>     >>>>> Cc: [e-mail] <mailto:rfc-editor@rfc-
> >>    editor.org> <[e-mail] <mailto:rfc-editor@rfc-
> >>    editor.org>>;
> >>     >>>>> [e-mail] <mailto:[e-mail]> <cose-
> >>    [e-mail] <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>
> >>     >>>>> <[e-mail] <mailto:[e-mail]>>;
> >>    [e-mail] <mailto:[e-mail]>
> >>     >>>>> <[e-mail] <mailto:[e-mail]>>;
> >>    [e-mail] <mailto:[e-mail]>
> >>     >>>>> <[e-mail] <mailto:[e-mail]>>;
> >>    Amaury Chamayou
> >>     >>>>> <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>
> >>     >>>>> <[e-mail] <mailto:[e-mail]>>; scitt-
> >>    [e-mail] <mailto:[e-mail]> <scitt-
> >>    [e-mail] <mailto:[e-mail]>>;
> >>     >>>>> Deb Cooley <[e-mail] <mailto:[e-mail]
> >>;
> >>     >>>>> [e-mail] <mailto:auth48archive@rfc-
> >>    editor.org><[e-mail] <mailto:auth48archive@rfc-
> >>    editor.org>>
> >>     >>>>> Subject: [EXTERNAL] [C557] Cluster-Wide AUTH48 Questions:
> >>     >>>>> draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942) and
> >>     >>>>> draft-ietf-scitt-architecture-22 (RFC-to-be 9943)  [You don't
> >>    often
> >>     >>>>> get email from [e-mail]
> >>    <mailto:[e-mail]>. Learn why this is
> >>     >>>>> important at https://aka.ms/LearnAboutSenderIdentification
> >>    <https://aka.ms/LearnAboutSenderIdentification> ]
> >>     >>>>>
> >>     >>>>> Cédric,
> >>     >>>>>
> >>     >>>>> Thank you for your reply and guidance regarding the cluster-
> >>    wide questions for both RFCs-to-be 9942 and 9943.  We have
> >>    implemented the majority of these changes as requested.
> >>     >>>>>
> >>     >>>>> Note that we have replied to our original cluster-wide mail
> >>    in order to ensure all participants from both documents see that the
> >>    responses have been received.  See the thread with subject line "Re:
> >>    [EXTERNAL] Re: AUTH48: RFC-to-be 9942 <draft-ietf-cose-merkle-tree-
> >>    proofs-18> for your review” for full response from Cédric).
> >>     >>>>>
> >>     >>>>> Some follow up questions/comments related to the cluster-wide
> >>     >>>>> questions exist below (marked with [rfced]).  We believe the
> >>     >>>>> follow-ups impact RFC-to-be 9942 only.  (Note that resolved
> >>    issues
> >>     >>>>> have been removed.)
> >>     >>>>>
> >>     >>>>> Note that further document-specific questions for RFC-to-be
> >>    9942 also exist; we have copied them at the end of this message for
> >>    your convenience.
> >>     >>>>>
> >>     >>>>>
> >>     >>>>>> 1) We had a number of questions related to the consistent
> >>    use of terminology throughout the cluster:
> >>     >>>>>>
> >>     >>>>>> b) Should the following similar forms be made uniform in
> >>    prose?  If so, please let us know which is preferred:
> >>     >>>>>>
> >>     >>>>>> COSE Header Parameter vs. COSE header parameter (see also
> other
> >>     >>>>>> header parameter instances without COSE)
> >>     >>>>>> Note: RFCs 9052/9053 use lowercase header parameter and
> >>    quotes for names (e.g., "alg" header parameter).  All uses of COSE
> >>    Header Parameter are in titles.
> >>     >>>>>> Yes, please use "COSE header parameter" outside of titles.
> >>     >>>>>
> >>     >>>>> [rfced] (Affects RFC-to-be 9942 only) We didn’t see a reply
> >>    to the second part of this question regarding putting parameter
> >>    names in double quotes.  We have updated the new header parameter
> >>    names to appear in lowercase with double quotes around them (e.g.,
> >>    “receipts” header parameter) to match RFC 9052/9053.  Please review
> >>    and let us know any objections.
> >>     >>>>>
> >>     >>>>>> Receipt vs. receipt
> >>     >>>>>> Note: RFC 9052 includes a single instance of the term
> >>    receipt that seems to be used in the general sense.
> >>     >>>>>> We would prefer to stay with "Receipt" to make it clear the
> >>    terminology definition applies, except in CBOR/CDDL labels, where
> >>    the prevailing convention is lowercase (therefore "receipt(s)”).
> >>     >>>>>
> >>     >>>>> [rfced] (We believe this affects RFC-to-be 9942 only - please
> >>    let us know if updates to RFC-to-be 9943 are also necessary) Please
> >>    let us know if/where any updates (preferably using Old/New) need to
> >>    be made related to CBOR/CDDL labels with regard to the term Receipt
> >>    vs. receipt.
> >>     >>>>>>
> >>     >>>>>> In addition, a reviewer has caught two mistakes.
> >>     >>>>>>
> >>     >>>>>> One in the examples of Figures 2 and 6, in which the
> >>    inclusion path should be an array to match the schema:
> >>     >>>>>>
> >>     >>>>>>              / inclusion / -1 : [
> >>     >>>>>>                <<[
> >>     >>>>>>                  / size / 6, / leaf / 5,
> >>     >>>>>>                  / inclusion path /
> >>     >>>>>>                  h'9352f974...4ffa7ce0',
> >>     >>>>>>                  h'54806f32...f007ea06'
> >>     >>>>>>                ]>>
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Should be:
> >>     >>>>>>
> >>     >>>>>>              / inclusion / -1 : [
> >>     >>>>>>                <<[
> >>     >>>>>>                  / size / 6, / leaf / 5,
> >>     >>>>>>                  / inclusion path /
> >>     >>>>>>                  [ h'9352f974...4ffa7ce0',
> >>     >>>>>>                    h'54806f32...f007ea06' ]
> >>     >>>>>>                ]>>
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> In figure 2. And:
> >>     >>>>>>
> >>     >>>>>>        / inclusion / -1 : [
> >>     >>>>>>          <<[
> >>     >>>>>>            / size / 20, / leaf / 17,
> >>     >>>>>>            / inclusion path /
> >>     >>>>>>            h'fc9f050f...221c92cb',
> >>     >>>>>>            h'bd0136ad...6b28cf21',
> >>     >>>>>>            h'd68af9d6...93b1632b'
> >>     >>>>>>          ]>>
> >>     >>>>>>        ],
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Should be:
> >>     >>>>>>
> >>     >>>>>>        / inclusion / -1 : [
> >>     >>>>>>          <<[
> >>     >>>>>>            / size / 20, / leaf / 17,
> >>     >>>>>>            / inclusion path /
> >>     >>>>>>            [ h'fc9f050f...221c92cb',
> >>     >>>>>>              h'bd0136ad...6b28cf21',
> >>     >>>>>>              h'd68af9d6...93b1632b' ]
> >>     >>>>>>          ]>>
> >>     >>>>>>        ],
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> In Figure 6.
> >>     >>>>>>
> >>     >>>>>> The other in Figure 2, where the value of 394 (receipts)
> >>    ought to be an array:
> >>     >>>>>>
> >>     >>>>>>      / receipts / 394 : {
> >>     >>>>>>        << ... >>
> >>     >>>>>>       }
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Should be:
> >>     >>>>>>
> >>     >>>>>>      / receipts / 394 : {         [ << ... >> ]
> >>     >>>>>>       }
> >>     >>>>>>
> >>     >>>>> [rfced] (RFC-to-be 9942 only) Please review any updates to
> >>    code carefully as indentation or spacing may (accidentally) be
> >>    affected when copying and pasting.  We recommend using the rfcdiff
> >>    file to view whitespace changes.
> >>     >>>>>
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>>    • In Section 4.2
> >>     >>>>>>
> >>     >>>>>> This document establishes a registry of verifiable data
> >>    structure
> >>     >>>>>> algorithm proofs, see Table 2 for details
> >>     >>>>>>
> >>     >>>>>> Should say:
> >>     >>>>>>
> >>     >>>>>> This document establishes a registry of verifiable data
> >>    structure
> >>     >>>>>> algorithm proofs, see Table 3 for details
> >>     >>>>>
> >>     >>>>> [rfced] (RFC-to-be 9942 only) Note that we have left this as
> >>    a pointer to the section (8.2.2.2) to match a similar sentence in
> >>    Section 4.1.  Please let us know if you would prefer them to both be
> >>    updated to point to the Tables themselves (i.e., Table 2 in Section
> >>    4.1 and Table 3 in Section 4.2).
> >>     >>>>>>
> >>     >>>>>> In addition, there are a couple of inconsistencies across
> >>    the CDDL snippets:
> >>     >>>>>>
> >>     >>>>>>    • There is a mix of cose.label/cose.value(s) and cose-
> >>    label/cose-value(s). Using the latter consistently would be
> preferable.
> >>     >>>>>
> >>     >>>>>>    • There is a mix of CDDL using comma-terminated lines
> >>    (eg. Signed_Consistency_Proof) and non comma-terminated (eg.
> >>    Signed_Inclusion_Proof). They are both valid CDDL, but using the
> >>    convention adopted in RFC9052 (comma termination) consistently would
> >>    be preferable.
> >>     >>>>>>
> >>     >>>>>> Finally, several EDN snippets (Figures 2, 6 and 9)
> >>    incorrectly use # comment, when the correct EDN syntax is /
> >>    comment /. For example:
> >>     >>>>>> / algorithm / 1 : -7,  # ES256
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Should be:
> >>     >>>>>>
> >>     >>>>>> / algorithm / 1 : -7,  / ES256 /
> >>     >>>>>
> >>     >>>>> [rfced] (RFC-to-be 9942 only) Again, please carefully review
> >>    any updates we’ve made to code to ensure they appear as desired.
> >>     >>>>>
> >>     >>>>> One further question that arose for RFC-to-be 9942 in the
> >>    following:
> >>     >>>>>
> >>     >>>>> Current:
> >>     >>>>> This is the value used to identify the Verifiable Data
> >>    Structure Proof
> >>     >>>>> Type.
> >>     >>>>>
> >>     >>>>> Should this be read as VDS Proof Type or VDP Proof Type or
> >>    VDP type (overlap of Proof)?
> >>     >>>>>
> >>     >>>>> Please review our updates in the files posted below carefully
> >>    as we do not make updates once the documents are published as RFCs.
> >>     >>>>>
> >>     >>>>>  The files have been posted here (please refresh):
> >>     >>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966479166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0%2FnaMibmODHDM7p6EpYNrEypDp9UdF8qiSUB%2BQ4sQ%2F8%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.txt>
> >>     >>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966498461%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d564yTKBqQuoqsWadwv7a8GAU0pwZ7Wead%2FVucNDhMI%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.pdf>
> >>     >>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966516633%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sCcYHCSCfNE5rhigAlBiYqDw%2Bnzw2CrhNvsXPFzMyFk%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.html>
> >>     >>>>>
> >>     >>>>> https://www/ <https://www/>.
> >>     >>>>> rfc-editor.org <http://rfc-editor.org/
> >>     >%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%40microsof
> >>     >>>>> t.com <http://t.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd01
> >>     >>>>>
> >>
> 1db47%7C1%7C0%7C639117967933259962%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> >>     >>>>>
> >>
> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> >>     >>>>>
> >>
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=mghfteDzbnRINFD04bWLb2867ZMSS6BlI%2FpgS
> >>     >>>>> mGlQLE%3D&reserved=0
> >>     >>>>>
> >>     >>>>>  The diff files have been posted here (please refresh):
> >>     >>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966534675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VVqmlCj9P4atZzeQ87%2FBjqGgwXb96rj9Air9B7Q2L8w%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-diff.html>
> >>     >>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966551383%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wIeTYi90zSS9cANvolYbIOnCcjvnAsOzYrqraYGY5BE%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html> (side by side)
> >>     >>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    auth48diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966570928%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=70TQXtKhS9scGNPiA1IYy6Axi72aB4WiwG3ILX4x4%2B0%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-auth48diff.html>
> >>     >>>>>
> >>     >>>>> https://www/ <https://www/>.
> >>     >>>>> rfc-editor.org <http://rfc-editor.org/>%2Fauthors%2Frfc9942-
> >>    auth48rfcdiff.html&data=05%7C02%7Ca
> >>     >>>>> ntdl%40microsoft.com <http://40microsoft.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f1
> >>     >>>>>
> >>
> 41af91ab2d7cd011db47%7C1%7C0%7C639117967933344410%7CUnknown%7CTWFpbGZs
> >>     >>>>>
> >>
> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
> >>     >>>>>
> >>
> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NJnco6RugvGf9mCQrMTvIBm7
> >>     >>>>> 5rSWW3SESirynUFJheU%3D&reserved=0 (side by side)
> >>     >>>>>
> >>     >>>>> Note - please see the thread for RFC-to-be 9943 to view any
> >>    changes related to these cluster-wide questions as we have combined
> >>    the updates with those in response to the document-specific
> >>    questions we received.
> >>     >>>>>
> >>     >>>>> The document-specific questions for RFC-to-be 9942 are copied
> >>    below.  We will await your response to the follow-up questions and
> >>    document-specific questions for each document in this cluster before
> >>    moving forward in the publication process.
> >>     >>>>>
> >>     >>>>> The AUTH48 status page for RFC-to-be 9942 is viewable here:
> >>     >>>>>
> >>     >>>>> https://www/ <https://www/>.
> >>     >>>>> rfc-editor.org <http://rfc-editor.org/
> >>     >%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft.com
> >>    <http://40microsoft.com/>
> >>     >>>>>
> >>
> %7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47
> >>     >>>>>
> >>
> %7C1%7C0%7C639117967933364597%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> >>     >>>>>
> >>
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> >>     >>>>>
> >>
> %3D%3D%7C0%7C%7C%7C&sdata=YV6LHK1h8WupPZed0nA9YLZ0Bns%2FNri2KLJYpyZ7TO
> >>     >>>>> A%3D&reserved=0
> >>     >>>>>
> >>     >>>>> Further cluster information is viewable here:
> >>     >>>>>
> >>     >>>>> https://www/ <https://www/>.
> >>     >>>>> rfc-editor.org <http://rfc-editor.org/
> >>     >%2Fcluster_info.php%3Fcid%3DC557&data=05%7C02%7Cantdl%40
> >>     >>>>> microsoft.com <http://microsoft.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91a
> >>     >>>>>
> >>
> b2d7cd011db47%7C1%7C0%7C639117967933385568%7CUnknown%7CTWFpbGZsb3d8eyJ
> >>     >>>>>
> >>
> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
> >>     >>>>>
> >>
> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ztnb%2B8Pf7wdXY2UJZKlKxohciQVfn
> >>     >>>>> kvLyBAlZ2iYklI%3D&reserved=0
> >>     >>>>>
> >>     >>>>> Thank you.
> >>     >>>>>
> >>     >>>>> Megan Ferguson
> >>     >>>>> RFC Production Center
> >>     >>>>>
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9942
> >>     >>>>>> <draft-ietf-cose-merkle-tree-proofs-18> for your review
> >>     >>>>>>
> >>     >>>>>> Authors,
> >>     >>>>>>
> >>     >>>>>> While reviewing this document during AUTH48, please resolve
> >>    (as necessary) the following questions, which are also in the source
> >>    file.
> >>     >>>>>>
> >>     >>>>>> 1) <!-- [rfced] Please note that the title of the document
> >>    has been
> >>     >>>>>>     updated as follows:
> >>     >>>>>>
> >>     >>>>>> a) We have flipped the abbreviation and expansion for COSE
> >>    to match
> >>     >>>>>> similar uses in past RFC titles.
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> COSE (CBOR Object Signing and Encryption) Receipts
> >>     >>>>>>
> >>     >>>>>> Current:
> >>     >>>>>> CBOR Object Signing and Encryption (COSE) Receipts
> >>     >>>>>>
> >>     >>>>>> b) We have updated the "short title" (in the running header
> >>    of the
> >>     >>>>>> PDF
> >>     >>>>>> version) as follows:
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> COSE (CBOR Object Signing and Encryption) Receipts
> >>     >>>>>>
> >>     >>>>>> Current:
> >>     >>>>>> COSE Receipts
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those
> >>    that appear
> >>     >>>>>> in the title) for use on
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
> >>     >%2Fsearch&data=05%7C02%7Cantdl%40microsoft.com
> >>    <http://40microsoft.com/>%7Cdcf
> >>     >>>>>>
> >>    e6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1
> >>     >>>>>>
> >>    %7C0%7C639117967933405199%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> >>     >>>>>>
> >>    RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> >>     >>>>>>
> >>    %3D%3D%7C0%7C%7C%7C&sdata=zV3VFSc1LzeIRrm6mMfeThcuBArpvyasrJtWSg7o2B
> >>     >>>>>> 4%3D&reserved=0. -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 3) <!--[rfced] We had the following questions related to the
> >>    Terminology
> >>     >>>>>>     section:
> >>     >>>>>>
> >>     >>>>>> a) Would you like the terms to be alphabetized for the ease
> >>    of the
> >>     >>>>>> reader?
> >>     >>>>>>
> >>     >>>>>> b) The Terminology section of draft-ietf-scitt-architecture
> >>    has a
> >>     >>>>>> sentence introducing terms from [STD96] in its Terminology
> >>    section
> >>     >>>>>> (see below) that are also used in this document.
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>>   The terms "header", "payload", and "to-be-signed bytes"
> >>    are defined
> >>     >>>>>>   in [STD96].
> >>     >>>>>>
> >>     >>>>>> Should this sentence (or something similar as "to-be-signed
> >>    bytes"
> >>     >>>>>> is not used in this document) be added along with a
> >>    reference to [STD96]?
> >>     >>>>>> (Same goes for the sentence in the companion document about
> the
> >>     >>>>>> definition of "claim".)
> >>     >>>>>>
> >>     >>>>>> If so, please let us know how/where to add as well as if the
> >>     >>>>>> reference entry would be normative or informative.
> >>     >>>>>>
> >>     >>>>>> c) We note that this document uses the following terms that
> are
> >>     >>>>>> defined in the Terminology section of
> >>     >>>>>> draft-ietf-scitt-architecture-22.  Should any pointers/
> >>    citations be
> >>     >>>>>> added to direct the reader to Section 3 of that document?
> >>     >>>>>>
> >>     >>>>>> envelope
> >>     >>>>>> non-equivocation
> >>     >>>>>> statement
> >>     >>>>>> transparency service
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> d) Please see our cluster-wide questions related to
> >>    discrepancies
> >>     >>>>>> between the definitions that appear in both documents in this
> >>     >>>>>> cluster and variances in their appearance (e.g.,
> >>    capitalization).
> >>     >>>>>>
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 4) <!--[rfced] This sentence doesn't parse.  Please let us
> >>    know how to
> >>     >>>>>>     update.
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> ...such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256
> >>    (TBD_1
> >>     >>>>>> (requested assignment 395) : 1) supports both (-1) inclusion
> and
> >>     >>>>>> (-2) consistency proofs.
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 5) <!--[rfced] Please note that Figure 1 exceeds our
> >>    character limit in
> >>     >>>>>>     three places (line 319 is 5 characters over the
> >>    character limit).
> >>     >>>>>>     Please review how these lines could be broken to fit
> >>    within the
> >>     >>>>>>     69 character limit associated with sourcecode.
> >>     >>>>>>        -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 6) <!--[rfced] We had two questions related to this
> >>    document's use of the
> >>     >>>>>>     term "SHA256":
> >>     >>>>>>
> >>     >>>>>> a) We note that the EDN provided in Section 4.3 uses RFC9162
> >>    SHA-256
> >>     >>>>>> while other uses of this term in prose use RFC9162_SHA256.
>    Please
> >>     >>>>>> confirm that this is as intended.
> >>     >>>>>>
> >>     >>>>>> b) We see both SHA256 and sha-256 in running text.  Should
> >>    these be
> >>     >>>>>> made uniform as SHA256?
> >>     >>>>>>
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 7) <!-- [rfced] We note that [RFC9162] uses "leaf_index"
> >>    rather than
> >>     >>>>>>     "leaf-index".  Please review and let us know if updates
> >>    should be
> >>     >>>>>>     made.
> >>     >>>>>>
> >>     >>>>>> Current:
> >>     >>>>>>  The term leaf-index is used for alignment with the use
> >>    established in
> >>     >>>>>>  Section 2.1.3.2 of [RFC9162].
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 8) <!-- [rfced] We note that [RFC9162] uses "Merkle Tree
> >>    Hash" rather
> >>     >>>>>>     than "Merkle tree hash".  Please note that there is
> >>    inconsistency
> >>     >>>>>>     in this document related to Merkle Tree vs. Merkle tree
> >>    as well.
> >>     >>>>>>
> >>     >>>>>> Current:
> >>     >>>>>>  The payload of an RFC9162_SHA256 inclusion proof signature
> >>    is the
> >>     >>>>>>  Merkle tree hash as defined in [RFC9162].
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 9) <!--[rfced] This sentence doesn't seem to parse.  Please
> >>    rephrase.
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> First the verifier applies the inclusion proof to a possible
> >>    entry
> >>     >>>>>> (set member) bytes.
> >>     >>>>>>
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 10) <!--[rfced] Please review this text for clarity
> >>    (particularly for a
> >>     >>>>>>     missing verb after which?).
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> If this process succeeds, the result is a Merkle root, which
> >>    in the
> >>     >>>>>> attached as the COSE Sign1 payload.
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 11) <!--[rfced] The following may require clarification:
> >>     >>>>>>
> >>     >>>>>> Current:
> >>     >>>>>>  The privacy considerations section of [RFC9162] and
> >>    [RFC9053] apply to
> >>     >>>>>>  this document.
> >>     >>>>>>
> >>     >>>>>> RFCs 9162 and 9053 do not have sections explicitly named
> >>    "Privacy
> >>     >>>>>> Considerations". RFC 9053 doesn't appear to contain the term
> >>     >>>>>> "privacy" at all.  Please review.
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 12) <!--[rfced] We had the following questions/comments
> >>    related to the
> >>     >>>>>>     IANA Considerations section:
> >>     >>>>>>
> >>     >>>>>> a) For clarity, we have updated the IANA Considerations
> >>    section by
> >>     >>>>>> breaking Section 8.2.2 up into subsections for each of the
> two
> >>     >>>>>> registries.  Please review this reorganization as well as any
> >>     >>>>>> pointers to it throughout the text to ensure we have
> correctly
> >>     >>>>>> maintained your intent.
> >>     >>>>>>
> >>     >>>>>> b) Please note that we have updated Tables 2 and 3 to
> >>    include the
> >>     >>>>>> Change Controller column as appears at the corresponding IANA
> >>     >>>>>> registries.  Please let us know any concerns.
> >>     >>>>>>
> >>     >>>>>> c) Note: Any updates to Section 2 and/or Tables 1-3 that
> >>    have been
> >>     >>>>>> made or resulting from author replies to our separate
> >>    terminology or
> >>     >>>>>> abbreviation queries that would impact the information
> actually
> >>     >>>>>> registered at
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.iana.org <http://w.iana.org/
> >>     >%2Fassignments%2Fcose%2Fcose.xhtml%23verifiable-data-struc
> >>     >>>>>> ture-algorithms&data=05%7C02%7Cantdl%40microsoft.com
> >>    <http://40microsoft.com/>%7Cdcfe6dabd4f64
> >>     >>>>>>
> >>    1837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639
> >>     >>>>>>
> >>    117967933424805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> >>     >>>>>>
> >>    OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> >>     >>>>>>
> >>    %7C%7C%7C&sdata=sNzsRJzHbjTjioaKB48QaDOvdF1srGfB44dnkmboAZQ%3D&reser
> >>     >>>>>> ved=0 will be communicate to IANA by the RPC once AUTH48
> >>     >>>>>> completes.-->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 13)  <!--[rfced] We had the following questions/comments
> >>    related to
> >>     >>>>>>      abbreviations used throughout the document.
> >>     >>>>>>
> >>     >>>>>> a) FYI - We have added expansions for abbreviations upon
> >>    first use
> >>     >>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide").  Please
> >>    review each
> >>     >>>>>> expansion in the document carefully to ensure correctness.
> >>     >>>>>>
> >>     >>>>>> b) We would like to update to use an abbreviation (instead
> >>    of its
> >>     >>>>>> expanded form) after first use in accordance with the
> >>    guidance at
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
> >>     >%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7Cantdl%
> 40microsoft.com <http://40microsoft.com/>%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639117967933442934%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FlAcTamXBVIZ7jGzQY4qfDlIYV8uIpEEdZIesb25l2I%3D&reserved=0
> for the following abbreviations.  Please let us know any objections.
> >>     >>>>>>
> >>     >>>>>> VDS
> >>     >>>>>> VDP
> >>     >>>>>>
> >>     >>>>>> *Note: In the meantime, we have updated all uses in prose to
> be
> >>     >>>>>> capitalized for these two terms.  Please review the use of
> >>     >>>>>> "verifiable data structure" (in quotes): may this instance be
> >>     >>>>>> changed to VDS as well?
> >>     >>>>>>
> >>     >>>>>> **Note: We also see "verifiable data structure algorithm
> >>    proofs".
> >>     >>>>>> Could this be made "VDP algorithms"?
> >>     >>>>>>
> >>     >>>>>> c) Things get a bit messy when we look at the expansion of
> >>    VDP if
> >>     >>>>>> the expansion of "P" is plural "proofs".
> >>     >>>>>>
> >>     >>>>>> For example, in the following:
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> This document describes how to convey VDS and associated VDP
> >>    types
> >>     >>>>>> in unified COSE envelopes.
> >>     >>>>>>
> >>     >>>>>> If we were to expand this, we'd get "verifiable data
> structure
> >>     >>>>>> proofs types" (with the double plurals).
> >>     >>>>>>
> >>     >>>>>> However, sometimes the -s on proof disappears when this was
> >>    expanded
> >>     >>>>>> in the text.
> >>     >>>>>>
> >>     >>>>>> For example:
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> ..defining the integers used to identify verifiable data
> >>    structure
> >>     >>>>>> proof types...
> >>     >>>>>>
> >>     >>>>>> and
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> A data structure which supports one or more Verifiable Data
> >>     >>>>>> Structure Proof Types.
> >>     >>>>>>
> >>     >>>>>> It's also a bit strange for it to be plural here:
> >>     >>>>>>
> >>     >>>>>> Original:
> >>     >>>>>> The combination of representations of various VDS and VDP can
> >>     >>>>>> significantly increase the burden for implementers and create
> >>     >>>>>> interoperability challenges for transparency services.
> >>     >>>>>>
> >>     >>>>>> Where we will have to make it "various VDSs and VDP" (the
> reader
> >>     >>>>>> will likely expect VDPs).
> >>     >>>>>>
> >>     >>>>>> Is it possible to update to use Verifiable Data Structure
> Proofs
> >>     >>>>>> (VDPs)?
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 14)  <!-- [rfced] See a list below of terms enclosed in <tt>
> >>    in this
> >>     >>>>>>      document.  Some of these terms appear both with and
> >>    without <tt>
> >>     >>>>>>      (alg, receipts, vdp, vds).  Please review to ensure the
> >>    usage of
> >>     >>>>>>      <tt> is correct and consistent.  Let us know if any
> >>    updates are
> >>     >>>>>>      needed.
> >>     >>>>>>
> >>     >>>>>> <tt>alg</tt>
> >>     >>>>>> <tt>exp</tt>
> >>     >>>>>> <tt>iat</tt>
> >>     >>>>>> <tt>leaf-index</tt>
> >>     >>>>>> <tt>nbf</tt>
> >>     >>>>>> <tt>receipts</tt>
> >>     >>>>>> <tt>tree-size</tt>
> >>     >>>>>> <tt>vdp</tt>
> >>     >>>>>> <tt>vds</tt>
> >>     >>>>>>
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> 15) <!-- [rfced] Please review the "Inclusive Language"
> >>    portion of the
> >>     >>>>>>     online Style Guide
> >>     >>>>>>     <https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org
> %2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966586519%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tzAyeyC%2FeawpZPNfUdI7pVhtQPABSjeyi5dYraqXUls%3D&reserved=0
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>>
> >>     >>>>>>     and let us know if any changes are needed.  Updates of
> this
> >>     >>>>>>     nature typically result in more precise language, which
> is
> >>     >>>>>>     helpful for readers.
> >>     >>>>>>
> >>     >>>>>> Note that our script did not flag any words in particular,
> >>    but this
> >>     >>>>>> should still be reviewed as a best practice.
> >>     >>>>>>
> >>     >>>>>> -->
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Thank you.
> >>     >>>>>>
> >>     >>>>>> Megan Ferguson
> >>     >>>>>> RFC Production Center
> >>     >>>>>>
> >>     >>>>>> *****IMPORTANT*****
> >>     >>>>>>
> >>     >>>>>> Updated 2026/03/06
> >>     >>>>>>
> >>     >>>>>> RFC Author(s):
> >>     >>>>>> --------------
> >>     >>>>>>
> >>     >>>>>> Instructions for Completing AUTH48
> >>     >>>>>>
> >>     >>>>>> Your document has now entered AUTH48.  Once it has been
> >>    reviewed and
> >>     >>>>>> approved by you and all coauthors, it will be published as
> >>    an RFC.
> >>     >>>>>> If an author is no longer available, there are several
> remedies
> >>     >>>>>> available as listed in the FAQ (https://
> >>    nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Ffaq%2F&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966606408%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ENkUmQhVN2%2BVtjmREbe8CMWw%2FiWsJCeDWo0iP3q1Vq4%3D&reserved=0
> <https://www.rfc-editor.org/faq/>).
> >>     >>>>>>
> >>     >>>>>> You and you coauthors are responsible for engaging other
> parties
> >>     >>>>>> (e.g., Contributors or Working Group) as necessary before
> >>    providing
> >>     >>>>>> your approval.
> >>     >>>>>>
> >>     >>>>>> Planning your review
> >>     >>>>>> ---------------------
> >>     >>>>>>
> >>     >>>>>> Please review the following aspects of your document:
> >>     >>>>>>
> >>     >>>>>> *  RFC Editor questions
> >>     >>>>>>
> >>     >>>>>>   Please review and resolve any questions raised by the RFC
> >>    Editor
> >>     >>>>>>   that have been included in the XML file as comments marked
> as
> >>     >>>>>>   follows:
> >>     >>>>>>
> >>     >>>>>>   <!-- [rfced] ... -->
> >>     >>>>>>
> >>     >>>>>>   These questions will also be sent in a subsequent email.
> >>     >>>>>>
> >>     >>>>>> *  Changes submitted by coauthors
> >>     >>>>>>
> >>     >>>>>>   Please ensure that you review any changes submitted by your
> >>     >>>>>>   coauthors.  We assume that if you do not speak up that you
> >>     >>>>>>   agree to changes submitted by your coauthors.
> >>     >>>>>>
> >>     >>>>>> *  Content
> >>     >>>>>>
> >>     >>>>>>   Please review the full content of the document, as this
> cannot
> >>     >>>>>>   change once the RFC is published.  Please pay particular
> >>    attention to:
> >>     >>>>>>   - IANA considerations updates (if applicable)
> >>     >>>>>>   - contact information
> >>     >>>>>>   - references
> >>     >>>>>>
> >>     >>>>>> *  Copyright notices and legends
> >>     >>>>>>
> >>     >>>>>>   Please review the copyright notice and legends as defined
> in
> >>     >>>>>>   RFC 5378 and the Trust Legal Provisions
> >>     >>>>>>   (TLP – https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-
> >>    info&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966628254%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Z0WNOkjOgJdxMtVxG2cgsEE2c%2FAjGytSkjla8uMYEw%3D&reserved=0
> <https://trustee.ietf.org/license-info>).
> >>     >>>>>>
> >>     >>>>>> *  Semantic markup
> >>     >>>>>>
> >>     >>>>>>   Please review the markup in the XML file to ensure that
> >>    elements of
> >>     >>>>>>   content are correctly tagged.  For example, ensure that
> >>    <sourcecode>
> >>     >>>>>>   and <artwork> are set correctly.  See details at
> >>     >>>>>>   <https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-
> >>    vocabulary&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966649096%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mq4RGj9NfnNfN%2Flk70qyMfIVYxvhd0WRavHU5MyTHYE%3D&reserved=0
> <https://authors.ietf.org/rfcxml-vocabulary>>.
> >>     >>>>>>
> >>     >>>>>> *  Formatted output
> >>     >>>>>>
> >>     >>>>>>   Please review the PDF, HTML, and TXT files to ensure that
> the
> >>     >>>>>>   formatted output, as generated from the markup in the XML
> >>    file, is
> >>     >>>>>>   reasonable.  Please note that the TXT will have formatting
> >>     >>>>>>   limitations compared to the PDF and HTML.
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Submitting changes
> >>     >>>>>> ------------------
> >>     >>>>>>
> >>     >>>>>> To submit changes, please reply to this email using ‘REPLY
> >>    ALL’ as
> >>     >>>>>> all the parties CCed on this message need to see your
> >>    changes. The
> >>     >>>>>> parties
> >>     >>>>>> include:
> >>     >>>>>>
> >>     >>>>>>   *  your coauthors
> >>     >>>>>>
> >>     >>>>>>   * [e-mail] <mailto:rfc-editor@rfc-
> >>    editor.org> (the RPC team)
> >>     >>>>>>
> >>     >>>>>>   *  other document participants, depending on the stream
> (e.g.,
> >>     >>>>>>      IETF Stream participants are your working group chairs,
> the
> >>     >>>>>>      responsible ADs, and the document shepherd).
> >>     >>>>>>
> >>     >>>>>>   * [e-mail] <mailto:auth48archive@rfc-
> >>    editor.org>, which is a new archival mailing list
> >>     >>>>>>      to preserve AUTH48 conversations; it is not an active
> >>    discussion
> >>     >>>>>>      list:
> >>     >>>>>>
> >>     >>>>>>     *  More info:
> >>     >>>>>>
> >>     >>>>>> https://ma/ <https://ma/>
> >>     >>>>>> ilarchive.ietf.org <http://ilarchive.ietf.org/
> >>     >%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxI
> >>     >>>>>> Ae6P8O4Zc&data=05%7C02%7Cantdl%40microsoft.com
> >>    <http://40microsoft.com/>%7Cdcfe6dabd4f641837df
> >>     >>>>>>
> >>    808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639117967
> >>     >>>>>>
> >>    933523144%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> >>     >>>>>>
> >>    AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> >>     >>>>>>
> >>    %7C&sdata=AO1dwmJfnFANnE0FZEedZD4KJ7nG3d0wQQ0LtYNOZdA%3D&reserved=0
> >>     >>>>>>
> >>     >>>>>>     *  The archive itself:
> >>     >>>>>>
> >>     >>>>>> https://ma/ <https://ma/>
> >>     >>>>>> ilarchive.ietf.org <http://ilarchive.ietf.org/
> >>     >%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7
> >>     >>>>>> Cantdl%40microsoft.com <http://40microsoft.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf
> >>     >>>>>>
> >>    86f141af91ab2d7cd011db47%7C1%7C0%7C639117967933540368%7CUnknown%7CTW
> >>     >>>>>>
> >>    FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> >>     >>>>>>
> >>    IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=49r8yM4AczDKOe
> >>     >>>>>> uU53PknXmrIVsu%2BPIkfgzt13FjSu4%3D&reserved=0
> >>     >>>>>>
> >>     >>>>>>     *  Note: If only absolutely necessary, you may
> >>    temporarily opt out
> >>     >>>>>>        of the archiving of messages (e.g., to discuss a
> >>    sensitive matter).
> >>     >>>>>>        If needed, please add a note at the top of the
> >>    message that you
> >>     >>>>>>        have dropped the address. When the discussion is
> >>    concluded,
> >>     >>>>>> [e-mail] <mailto:auth48archive@rfc-
> >>    editor.org> will be re-added to the CC list and
> >>     >>>>>>        its addition will be noted at the top of the message.
> >>     >>>>>>
> >>     >>>>>> You may submit your changes in one of two ways:
> >>     >>>>>>
> >>     >>>>>> An update to the provided XML file
> >>     >>>>>> — OR —
> >>     >>>>>> An explicit list of changes in this format
> >>     >>>>>>
> >>     >>>>>> Section # (or indicate Global)
> >>     >>>>>>
> >>     >>>>>> OLD:
> >>     >>>>>> old text
> >>     >>>>>>
> >>     >>>>>> NEW:
> >>     >>>>>> new text
> >>     >>>>>>
> >>     >>>>>> You do not need to reply with both an updated XML file and an
> >>     >>>>>> explicit list of changes, as either form is sufficient.
> >>     >>>>>>
> >>     >>>>>> We will ask a stream manager to review and approve any
> >>    changes that
> >>     >>>>>> seem beyond editorial in nature, e.g., addition of new text,
> >>     >>>>>> deletion of text, and technical changes.  Information about
> >>    stream
> >>     >>>>>> managers can be found in the FAQ.  Editorial changes do not
> >>    require approval from a stream manager.
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Approving for publication
> >>     >>>>>> --------------------------
> >>     >>>>>>
> >>     >>>>>> To approve your RFC for publication, please reply to this
> email
> >>     >>>>>> stating that you approve this RFC for publication.  Please
> use
> >>     >>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to
> >>    see your approval.
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Files
> >>     >>>>>> -----
> >>     >>>>>>
> >>     >>>>>> The files are available here:
> >>     >>>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966673791%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wE17aWJCxEFrgMjER9Re7ALRq8TJ9Wtw6G4g4i%2B%2FaTU%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.xml>
> >>     >>>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966696945%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U16XsgfdOvDTgsuxJvWKEaAjvy00xIzc%2FB1EkcFubmE%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.html>
> >>     >>>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-
> >>    editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%
> 40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966717085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Eg0m5dTLAddo8oatk2UbMAA99XWKGA8TpPrgX51DuaE%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942.pdf>
> >>     >>>>>>
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
> >>     >%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%40micr
> >>     >>>>>> osoft.com <http://osoft.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2
> >>     >>>>>>
> >>    d7cd011db47%7C1%7C0%7C639117967933610534%7CUnknown%7CTWFpbGZsb3d8eyJ
> >>     >>>>>>
> >>    FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> >>     >>>>>>
> >>    pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0Xs8fRQn%2F9s%2FKR4KKOb3t3s
> >>     >>>>>> MkwrQeOsS50MxigL29u4%3D&reserved=0
> >>     >>>>>>
> >>     >>>>>> Diff file of the text:
> >>     >>>>>> https://nam06.safelinks.protection.outlook.com/?
> >>    url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
> >>    diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966736976%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZJ73QiU002PuLoS5cEM84LopcvrhxZklzKdZLd1l6Ws%3D&reserved=0
> <https://www.rfc-editor.org/authors/rfc9942-diff.html>
> >>     >>>>>>
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
> >>     >%2Fauthors%2Frfc9942-rfcdiff.html&data=05%7C02%7Cant
> >>     >>>>>> dl%40microsoft.com <http://40microsoft.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f1
> >>     >>>>>>
> >>    41af91ab2d7cd011db47%7C1%7C0%7C639117967933637548%7CUnknown%7CTWFpbG
> >>     >>>>>>
> >>    Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
> >>     >>>>>>
> >>    FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4JkPMy%2FiIdR3z4AO
> >>     >>>>>> xDm9Z%2FFakeBp9aglNClQjCRfQc8%3D&reserved=0 (side by side)
> >>     >>>>>>
> >>     >>>>>> Diff of the XML:
> >>     >>>>>>
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
> >>     >%2Fauthors%2Frfc9942-xmldiff1.html&data=05%7C02%7Can
> >>     >>>>>> tdl%40microsoft.com <http://40microsoft.com/
> >>     >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f
> >>     >>>>>>
> >>    141af91ab2d7cd011db47%7C1%7C0%7C639117967933653396%7CUnknown%7CTWFpb
> >>     >>>>>>
> >>    GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> >>     >>>>>>
> >>    kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y3%2FCQOq%2FC4kWF
> >>     >>>>>> %2BOKUOXlf2g4DRYowG4BNqUSl9xehWI%3D&reserved=0
> >>     >>>>>>
> >>     >>>>>>
> >>     >>>>>> Tracking progress
> >>     >>>>>> -----------------
> >>     >>>>>>
> >>     >>>>>> The details of the AUTH48 status of your document are here:
> >>     >>>>>>
> >>     >>>>>> https://ww/ <https://ww/>
> >>     >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
> >>     >%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft
> >>     >>>>>>
> .com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd0
> >>     >>>>>>
> >>    11db47%7C1%7C0%7C639117967933672481%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> >>     >>>>>>
> >>    eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> >>     >>>>>>
> >>    IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=znCCRuGuMv8k2jGpXl1kM3BP2OMX32kE
> >>     >>>>>> KcPjcdcsu84%3D&reserved=0
> >>     >>>>>>
> >>     >>>>>> Please let us know if you have any questions.
> >>     >>>>>>
> >>     >>>>>> Thank you for your cooperation,
> >>     >>>>>>
> >>     >>>>>> RFC Editor
> >>     >>>>>>
> >>     >>>>>> --------------------------------------
> >>     >>>>>> RFC9942 (draft-ietf-cose-merkle-tree-proofs-18)
> >>     >>>>>>
> >>     >>>>>> Title            : COSE (CBOR Object Signing and Encryption)
> >>    Receipts
> >>     >>>>>> Author(s)        : O. Steele, H. Birkholz, A. Delignat-
> >>    Lavaud, C. Fournet
> >>     >>>>>> WG Chair(s)      : Ivaylo Petrov, Michael B. Jones
> >>     >>>>>>
> >>     >>>>>> Area Director(s) : Deb Cooley, Paul Wouters
> >>     >>>>> <rfc9942.xml>
> >>     >>>>
> >>     >>>
> >>     >>> <rfc9942.xml>
> >>     >
> >
>
>