On Tue, Apr 14, 2026 at 4:52 PM Megan Ferguson < [email protected]> wrote:
> Hi Antoine and *AD (*Paul), > > [*Paul - Would you please review and approve the removal of text from > Section 6 of RFC-to-be 9942? ] > Approved, Paul > > 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://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 > 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-auth48rfcdiff.html (side by > side) > https://www.rfc-editor.org/authors/rfc9942-lastdiff.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 > > The AUTH48 status page for this cluster is available here: > 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 < > [email protected]> 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 <[email protected]> > > Sent: Thursday, April 2, 2026 00:49 > > To: [email protected] <[email protected]>; [email protected] > <[email protected]>; Antoine Delignat-Lavaud <[email protected]>; > Cedric Fournet <[email protected]>; Yogesh Deshpande < > [email protected]>; [email protected] < > [email protected]> > > Cc: [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; Amaury Chamayou < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; Deb Cooley < > [email protected]>; [email protected]< > [email protected]> > > 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 [email protected]. Learn > why this is important at 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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553309579%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=BEMci6OfL5PwzztpX4JpQtB1gKX4yEnsBuOXvAJmTwg%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553327877%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=m4tRpd6pjr5tO%2B%2FxxVXfWAOobMvDGWKHbWqDWAZOWDU%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553339109%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=X9KN1jk63P85deLwDu5Zn%2FtLS2J%2FA0AbonenQHI24jU%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553350788%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WCVFuHzaXGy%2FxmWePdm6DCv2jw1uE4BFfZ%2BPyAnwOiw%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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553361604%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=uK1hrAkeePihIHgw%2FDnGf7R1zf%2BLJhb%2FY9co%2BgBj7lo%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553372201%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=cYOOFAV6kKh4hMVtHz0qVHTD%2Be%2FDgJ1zNxlKcJTpdO4%3D&reserved=0 > (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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553382734%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=hEm3zEs91PBazSF9YLZnFD82LemP8Q1J%2BacGVjN3f1I%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-auth48rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553396029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=PTRFADvRDJe1FhL1TnIjsBHL04jZACcXcCb8SqsE2UI%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553407227%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=XpSShZQWMlot5zq7nqg%2FmSIv8K77ZEdoa7ZlrLq%2B2bI%3D&reserved=0 > > > > Further cluster information is viewable here: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcluster_info.php%3Fcid%3DC557&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553417872%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Ku1swl4fILD7lks9Y9OpooqkKiYIqJXCCtqc4T8oH7s%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553428979%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8Do%2FMKuUT9lQ5hXI7arle0cEmbN2on30S6hLMxz2SCQ%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcose%2Fcose.xhtml%23verifiable-data-structure-algorithms&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553439320%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=peszo%2FliTMdQcllR9kp0X8WlB2pev%2BxXpIAy9z2dUW0%3D&reserved=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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553449866%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Epf1BfxrqHHq3FkK5qyw3CfDRe6qQIe81PZ74nOmYSI%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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553460392%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tg%2BJPo1CG62ZIYMDyDvLsxqOxW2lWfKiF6yDpFZrPP4%3D&reserved=0 > > > > > 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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553471056%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=CKv2AtVBfctgovXV%2FCJjNXPHE0wpJ8zW7flPkJKxGrQ%3D&reserved=0 > ). > > > > > > 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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553481767%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2Fbjdwcbs1pjBBLbsXh1%2BCP9vE75siNSS%2FfcPS%2Be%2F%2FWQ%3D&reserved=0 > ). > > > > > > * 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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553492225%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=apS9Ox6c965cCnx%2FCT2m4bCRqQRBCHReDsYbMwO0Yrg%3D&reserved=0 > >. > > > > > > * 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 > > > > > > * [email protected] (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). > > > > > > * [email protected], which is a new archival mailing > list > > > to preserve AUTH48 conversations; it is not an active discussion > > > list: > > > > > > * More info: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553502648%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=SEUxfElDDreIFE%2BudV1VCNoZZ7SAp%2BmAV83qGqsrNHg%3D&reserved=0 > > > > > > * The archive itself: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553512992%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2FByb01rgSJzCuTiS8fzfUDyv0b%2B8yH5gYZ%2BTL5SmrOI%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, > > > [email protected] 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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553523769%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8L4%2BFROdDzMLUBfXfCudJ9xpITVp5ciRDBfKOz8ebno%3D&reserved=0 > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553534066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=dICTM2ShQaVdfUEFKWiLhGqhsZ6UMlLKaxE6dVVZ0%2Fg%3D&reserved=0 > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553545438%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=6pAp7h7pRzOMqIFXAIqCu602ITwJpxFDKm6mouB%2FmOU%3D&reserved=0 > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553557404%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=idQA0xpR7Al64yb%2Bl6ULCzcFNbT5IdVGPP16wJELM8c%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%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553568093%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Sb01XFtAyZeMzQPdOd0A9GMYkU62lYmtSMiHdBhkivo%3D&reserved=0 > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553578768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=PJ3fdWj6nUBaAVGBqzV297yvuwovoT6mwyyhu18xeM0%3D&reserved=0 > (side by side) > > > > > > Diff of the XML: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-xmldiff1.html&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553589702%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=guMtXRPuCvo%2BYoEqtiBNJUgOw9E6mCPZYV7uXvlQWlM%3D&reserved=0 > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft.com%7C415043c71d32495b76e908de90496347%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639106842553600842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=VFhMjLtWaSGuWm4fzSgGs0GdcCvx9apXmNQE9ErROFQ%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> > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
