Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
From: Megan Ferguson <mferguson@staff.rfc-editor.org>
In-Reply-To: 
 <PA1PR83MB0749D2E1A468025250F484F6B2202@PA1PR83MB0749.EURPRD83.prod.outlook.com>
Date: Fri, 17 Apr 2026 12:16:46 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC4967BC-C46C-400D-8897-3449D0BB02E3@staff.rfc-editor.org>
References: <DAFEFEC1-CA27-4E89-9C1A-B910E9E7AAA4@staff.rfc-editor.org>
 <PA1PR83MB0749096BA99F350428B89062B2252@PA1PR83MB0749.EURPRD83.prod.outlook.com>
 <B3B191DA-68F5-4487-8765-E0180E561699@staff.rfc-editor.org>
 <PA1PR83MB0749D7A8CA65FA5DD9E3CF68B2232@PA1PR83MB0749.EURPRD83.prod.outlook.com>
 <D3FE8D44-6C94-456A-AD1C-571763DAAC1F@staff.rfc-editor.org>
 <PA1PR83MB0749D2E1A468025250F484F6B2202@PA1PR83MB0749.EURPRD83.prod.outlook.com>
To: Antoine Delignat-Lavaud <antdl@microsoft.com>
Message-ID-Hash: DGUNHKMMGQOB3B7LIR4S5Z6RBJKZ4DOL
CC: "paul.wouters@aiven.io" <paul.wouters@aiven.io>,
 "orie@or13.io" <orie@or13.io>,
 "henk.birkholz@ietf.contact" <henk.birkholz@ietf.contact>,
 Cedric Fournet <fournet@microsoft.com>,
 Yogesh Deshpande <yogesh.deshpande@arm.com>,
 "stevenlasker@hotmail.com" <stevenlasker@hotmail.com>,
 "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>,
 "cose-ads@ietf.org" <cose-ads@ietf.org>,
 "cose-chairs@ietf.org" <cose-chairs@ietf.org>,
 "ivaylopetrov@google.com" <ivaylopetrov@google.com>,
 Amaury Chamayou <Amaury.Chamayou@microsoft.com>,
 "scitt-ads@ietf.org" <scitt-ads@ietf.org>,
 "scitt-chairs@ietf.org" <scitt-chairs@ietf.org>,
 Deb Cooley <debcooley1@gmail.com>,
 "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_=5BEXTERNAL=5D_=5BAD=5D_=5BC557=5D_Cluster-Wide?=
 =?utf-8?q?_AUTH48_Questions=3A_draft-ietf-cose-merkle-tree-proofs-18_=28RFC?=
 =?utf-8?q?-to-be_9942=29_and_draft-ietf-scitt-architecture-22_=28RFC-to-be_?=
 =?utf-8?q?9943=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/zr9HNRLIBwwAV5uxBMqDmEBPUDM>

Hi Antoine,

Thanks for your reply. =20

I want to confirm that the XML attached is the one you were meaning to =
send? =20

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., =3D =
/6.18(COSE_Sign1) has been changed back to #6.18(COSE_Sign1).

-We don=E2=80=99t see responses or action taken on our questions sent 14 =
April.

-There don=E2=80=99t 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

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

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=E2=80=99s 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? =20

3) The authors reject the changes in the RPC=E2=80=99s 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=E2=80=AFAM, Antoine Delignat-Lavaud =
<antdl@microsoft.com> wrote:
>=20
> Dear Megan,
>=20
> Please find attached our latest corrections in XML. This addresses all =
remaining editor comments and also corrects a few additional editorial =
mistakes we found.
>=20
> I will send a separate update for 9943.
>=20
> Best,
> Antoine
> (on behalf of the authors)From: Megan Ferguson =
<mferguson@staff.rfc-editor.org>
> Sent: Thursday, April 16, 2026 19:43
> To: Antoine Delignat-Lavaud <antdl@microsoft.com>
> Cc: paul.wouters@aiven.io <paul.wouters@aiven.io>; orie@or13.io =
<orie@or13.io>; henk.birkholz@ietf.contact<henk.birkholz@ietf.contact>; =
Cedric Fournet <fournet@microsoft.com>; Yogesh Deshpande =
<yogesh.deshpande@arm.com>; stevenlasker@hotmail.com =
<stevenlasker@hotmail.com>; rfc-editor@rfc-editor.org =
<rfc-editor@rfc-editor.org>; cose-ads@ietf.org <cose-ads@ietf.org>; =
cose-chairs@ietf.org <cose-chairs@ietf.org>; ivaylopetrov@google.com =
<ivaylopetrov@google.com>; Amaury Chamayou =
<Amaury.Chamayou@microsoft.com>; scitt-ads@ietf.org =
<scitt-ads@ietf.org>; scitt-chairs@ietf.org <scitt-chairs@ietf.org>; Deb =
Cooley <debcooley1@gmail.com>; auth48archive@rfc-editor.org =
<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 Antoine,
>=20
> No problem!  Thanks for letting us know and we will wait to hear from =
you.
>=20
> Megan Ferguson
> RFC Production Center
>=20
> > On Apr 16, 2026, at 11:05=E2=80=AFAM, Antoine Delignat-Lavaud =
<antdl@microsoft.com> wrote:
> >=20
> > Hi Megan,
> >=20
> > Many thanks for the extra feedback.
> >=20
> > 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.
> >=20
> > Best,
> > Antoine
> >=20
> > -----Original Message-----
> > From: Megan Ferguson <mferguson@staff.rfc-editor.org>
> > Sent: 14 April 2026 21:52
> > To: Antoine Delignat-Lavaud <antdl@microsoft.com>; =
paul.wouters@aiven.io
> > Cc: orie@or13.io; henk.birkholz@ietf.contact; Cedric Fournet =
<fournet@microsoft.com>; Yogesh Deshpande <yogesh.deshpande@arm.com>; =
stevenlasker@hotmail.com; rfc-editor@rfc-editor.org; cose-ads@ietf.org; =
cose-chairs@ietf.org; ivaylopetrov@google.com; Amaury Chamayou =
<Amaury.Chamayou@microsoft.com>; scitt-ads@ietf.org; =
scitt-chairs@ietf.org; Deb Cooley <debcooley1@gmail.com>; =
auth48archive@rfc-editor.org
> > 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)
> >=20
> > Hi Antoine and *AD (*Paul),
> >=20
> > [*Paul - Would you please review and approve the removal of text =
from Section 6 of RFC-to-be 9942?  ]
> >=20
> > Thank you for the updated file!
> >=20
> > We had some follow-up questions/comments for you to review:
> >=20
> > 1) We had asked about text additions to the Terminology section:
> >=20
> > a) Regarding the addition of the following to the Terminology =
section:
> >=20
> >   The terms "header", "payload", and "to-be-signed bytes" are =
defined
> >   in [STD96].
> >=20
> > We have updated to use the following (as to-be-signed bytes does not =
appear in this document):
> >=20
> >   The terms =E2=80=9Cheader" and "payload" are defined in [STD96].
> >=20
> > 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:
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > Please let us know any objections/concerns.
> >=20
> > b) Please let us know if the following should also be added to the =
Terminology section:
> >=20
> > The term "claim" is defined in [RFC8392].
> >=20
> > Note that RFC 8392 is already referenced.
> >=20
> > 2) Regarding the following query:
> >=20
> > <!--[rfced] This sentence doesn't parse.  Please let us know how to
> >     update.
> >=20
> > 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.
> > -->
> >=20
> > <!-- [authors] We have updated the sentence as follows for clarity:
> >=20
> > ...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.
> >=20
> > Please let us know if you have any further suggestions. =E2=80=94>
> >=20
> > [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).
> >=20
> > 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.
> >=20
> >=20
> > 3) Regarding the following query:
> >=20
> > <!--[rfced] This sentence doesn't seem to parse.  Please rephrase.
> >=20
> > Original:
> > First the verifier applies the inclusion proof to a possible entry =
(set member) bytes.
> >=20
> > -->
> > <!--[authors] We think the current sentence with the comma parses =
correctly.
> > -->
> >=20
> > Can you let us know how =E2=80=9C(set member) bytes" relates to the =
sentence?
> >=20
> >=20
> > The files below have been updated with all other requests.
> >=20
> > Please review carefully as we do not make changes once the document =
is published as an RFC.
> >=20
> >  The files have been posted here (please refresh):
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.txt&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966148880%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3Dr4DIPKy4A51NEYLSt37ZLKv5EDL%2FxygdFTVBJ7s%2FZYw%3D&reserv=
ed=3D0
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.pdf&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966204186%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3DpF2Gd6Z6KsnvuMW6qbx8YPx33lbGRBjjAHFmCN8MsX8%3D&reserved=3D=
0
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.html&data=3D05%7C02%7Cantdl%40microsoft.c=
om%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7=
C1%7C0%7C639119618966258528%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW=
UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0=
%7C%7C%7C&sdata=3D%2FXaX%2BNva2Zt30IYNDPJzbCoqtKvwvNlCShmWv73AF3Q%3D&reser=
ved=3D0
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.xml&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966292714%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3DzlkgpxcvnhQPTm61ibjbUEPFbH1pK1VcxnwBeCCb1CQ%3D&reserved=3D=
0
> >=20
> >  The diff files have been posted here (please refresh):
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-diff.html&data=3D05%7C02%7Cantdl%40micros=
oft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011d=
b47%7C1%7C0%7C639119618966319736%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO=
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3=
D%7C0%7C%7C%7C&sdata=3DcMdRSjokKj8NkfdX6fRqq4%2F0rG%2BRARw3IirM%2FM40C8A%3=
D&reserved=3D0
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-rfcdiff.html&data=3D05%7C02%7Cantdl%40mic=
rosoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd0=
11db47%7C1%7C0%7C639119618966339679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG=
kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3=
D%3D%7C0%7C%7C%7C&sdata=3DQdufwmRO4W9ZXPP75%2BP%2BBE2EuUBkgpaCai8Mke7TXHY%=
3D&reserved=3D0(side by side)
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-auth48diff.html&data=3D05%7C02%7Cantdl%40=
microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7=
cd011db47%7C1%7C0%7C639119618966357832%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1=
hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf=
Q%3D%3D%7C0%7C%7C%7C&sdata=3Dh6OFjLIsSG0HRpnWtdVa425KYVLM1DIrPO6p6bzxErs%3=
D&reserved=3D0
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-auth48rfcdiff.html&data=3D05%7C02%7Cantdl=
%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab=
2d7cd011db47%7C1%7C0%7C639119618966377508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0=
eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj=
oyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D3%2BQy1%2BemdWPDD9FsVSeXNRYm3loUGcbJG5mKax=
vPHKI%3D&reserved=3D0 (side by side)
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-lastdiff.html&data=3D05%7C02%7Cantdl%40mi=
crosoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd=
011db47%7C1%7C0%7C639119618966397952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc=
GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%=
3D%3D%7C0%7C%7C%7C&sdata=3DNz9zBQ5BinChOSCBs8AK8J2LmsGiNNJatNre%2F%2BEaiyg=
%3D&reserved=3D0
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-lastrfcdiff.html&data=3D05%7C02%7Cantdl%4=
0microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d=
7cd011db47%7C1%7C0%7C639119618966417496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU=
1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy=
fQ%3D%3D%7C0%7C%7C%7C&sdata=3DfmDfferopj6deReTsUs6CH%2FB7xdQYzkey%2F8aZkM9=
Qn0%3D&reserved=3D0(side by side)
> >=20
> > The AUTH48 status page for this document is available here:
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauth48%2Frfc9942&data=3D05%7C02%7Cantdl%40microsoft.com%7C0=
50d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0=
%7C639119618966436825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi=
OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C=
%7C&sdata=3DlmpG%2FPq5DZSUPpCVw5smdEnURPpul%2BA7qk8ZpxUfZtA%3D&reserved=3D=
0
> >=20
> > The AUTH48 status page for this cluster is available here:
> >   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauth48%2FC557&data=3D05%7C02%7Cantdl%40microsoft.com%7C050d=
698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C=
639119618966458747%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI=
wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C=
&sdata=3DZa8iNKgbsahg2gNR2ip3ZzD2uD4xj1Y82qR2BT3C3fA%3D&reserved=3D0
> >=20
> > Thank you.
> >=20
> > Megan Ferguson
> > RFC Production Center
> >=20
> >=20
> >=20
> >> On Apr 14, 2026, at 8:52=E2=80=AFAM, Antoine Delignat-Lavaud =
<antdl@microsoft.com> wrote:
> >>=20
> >> Hi Megan,
> >>=20
> >> 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.
> >>=20
> >> 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.
> >>=20
> >> Best,
> >> AntoineFrom: Megan Ferguson <mferguson@staff.rfc-editor.org>
> >> Sent: Thursday, April 2, 2026 00:49
> >> To: orie@or13.io <orie@or13.io>; henk.birkholz@ietf.contact
> >> <henk.birkholz@ietf.contact>; Antoine Delignat-Lavaud
> >> <antdl@microsoft.com>; Cedric Fournet <fournet@microsoft.com>; =
Yogesh
> >> Deshpande <yogesh.deshpande@arm.com>; stevenlasker@hotmail.com
> >> <stevenlasker@hotmail.com>
> >> Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>;
> >> cose-ads@ietf.org <cose-ads@ietf.org>; cose-chairs@ietf.org
> >> <cose-chairs@ietf.org>; ivaylopetrov@google.com
> >> <ivaylopetrov@google.com>; paul.wouters@aiven.io
> >> <paul.wouters@aiven.io>; Amaury Chamayou
> >> <Amaury.Chamayou@microsoft.com>; scitt-ads@ietf.org
> >> <scitt-ads@ietf.org>; scitt-chairs@ietf.org =
<scitt-chairs@ietf.org>;
> >> Deb Cooley <debcooley1@gmail.com>;
> >> auth48archive@rfc-editor.org<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 mferguson@staff.rfc-editor.org. Learn why this is
> >> important at https://aka.ms/LearnAboutSenderIdentification ]
> >>=20
> >> C=C3=A9dric,
> >>=20
> >> 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.
> >>=20
> >> 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=E2=80=9D for =
full response from C=C3=A9dric).
> >>=20
> >> 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.)
> >>=20
> >> 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.
> >>=20
> >>=20
> >>> 1) We had a number of questions related to the consistent use of =
terminology throughout the cluster:
> >>>=20
> >>> b) Should the following similar forms be made uniform in prose?  =
If so, please let us know which is preferred:
> >>>=20
> >>> 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.
> >>=20
> >> [rfced] (Affects RFC-to-be 9942 only) We didn=E2=80=99t 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., =E2=80=9Creceipts=E2=80=
=9D header parameter) to match RFC 9052/9053.  Please review and let us =
know any objections.
> >>=20
> >>> 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)=E2=80=9D).
> >>=20
> >> [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.
> >>>=20
> >>> In addition, a reviewer has caught two mistakes.
> >>>=20
> >>> One in the examples of Figures 2 and 6, in which the inclusion =
path should be an array to match the schema:
> >>>=20
> >>>              / inclusion / -1 : [
> >>>                <<[
> >>>                  / size / 6, / leaf / 5,
> >>>                  / inclusion path /
> >>>                  h'9352f974...4ffa7ce0',
> >>>                  h'54806f32...f007ea06'
> >>>                ]>>
> >>>=20
> >>>=20
> >>> Should be:
> >>>=20
> >>>              / inclusion / -1 : [
> >>>                <<[
> >>>                  / size / 6, / leaf / 5,
> >>>                  / inclusion path /
> >>>                  [ h'9352f974...4ffa7ce0',
> >>>                    h'54806f32...f007ea06' ]
> >>>                ]>>
> >>>=20
> >>>=20
> >>> In figure 2. And:
> >>>=20
> >>>        / inclusion / -1 : [
> >>>          <<[
> >>>            / size / 20, / leaf / 17,
> >>>            / inclusion path /
> >>>            h'fc9f050f...221c92cb',
> >>>            h'bd0136ad...6b28cf21',
> >>>            h'd68af9d6...93b1632b'
> >>>          ]>>
> >>>        ],
> >>>=20
> >>>=20
> >>> Should be:
> >>>=20
> >>>        / inclusion / -1 : [
> >>>          <<[
> >>>            / size / 20, / leaf / 17,
> >>>            / inclusion path /
> >>>            [ h'fc9f050f...221c92cb',
> >>>              h'bd0136ad...6b28cf21',
> >>>              h'd68af9d6...93b1632b' ]
> >>>          ]>>
> >>>        ],
> >>>=20
> >>>=20
> >>> In Figure 6.
> >>>=20
> >>> The other in Figure 2, where the value of 394 (receipts) ought to =
be an array:
> >>>=20
> >>>      / receipts / 394 : {
> >>>        << ... >>
> >>>       }
> >>>=20
> >>>=20
> >>> Should be:
> >>>=20
> >>>      / receipts / 394 : {         [ << ... >> ]
> >>>       }
> >>>=20
> >> [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.
> >>=20
> >>>=20
> >>>=20
> >>>    =E2=80=A2 In Section 4.2
> >>>=20
> >>> This document establishes a registry of verifiable data structure
> >>> algorithm proofs, see Table 2 for details
> >>>=20
> >>> Should say:
> >>>=20
> >>> This document establishes a registry of verifiable data structure
> >>> algorithm proofs, see Table 3 for details
> >>=20
> >> [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).
> >>>=20
> >>> In addition, there are a couple of inconsistencies across the CDDL =
snippets:
> >>>=20
> >>>    =E2=80=A2 There is a mix of cose.label/cose.value(s) and =
cose-label/cose-value(s). Using the latter consistently would be =
preferable.
> >>=20
> >>>    =E2=80=A2 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.
> >>>=20
> >>> 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
> >>>=20
> >>>=20
> >>> Should be:
> >>>=20
> >>> / algorithm / 1 : -7,  / ES256 /
> >>=20
> >> [rfced] (RFC-to-be 9942 only) Again, please carefully review any =
updates we=E2=80=99ve made to code to ensure they appear as desired.
> >>=20
> >> One further question that arose for RFC-to-be 9942 in the =
following:
> >>=20
> >> Current:
> >> This is the value used to identify the Verifiable Data Structure =
Proof
> >> Type.
> >>=20
> >> Should this be read as VDS Proof Type or VDP Proof Type or VDP type =
(overlap of Proof)?
> >>=20
> >> Please review our updates in the files posted below carefully as we =
do not make updates once the documents are published as RFCs.
> >>=20
> >>  The files have been posted here (please refresh):
> >>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.txt&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966479166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3D0%2FnaMibmODHDM7p6EpYNrEypDp9UdF8qiSUB%2BQ4sQ%2F8%3D&rese=
rved=3D0
> >>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.pdf&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966498461%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3Dd564yTKBqQuoqsWadwv7a8GAU0pwZ7Wead%2FVucNDhMI%3D&reserved=
=3D0
> >>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.html&data=3D05%7C02%7Cantdl%40microsoft.c=
om%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7=
C1%7C0%7C639119618966516633%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW=
UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0=
%7C%7C%7C&sdata=3DsCcYHCSCfNE5rhigAlBiYqDw%2Bnzw2CrhNvsXPFzMyFk%3D&reserve=
d=3D0
> >>=20
> >> https://www/.
> >> =
rfc-editor.org%2Fauthors%2Frfc9942.xml&data=3D05%7C02%7Cantdl%40microsof
> >> =
t.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd01
> >> =
1db47%7C1%7C0%7C639117967933259962%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> >> =
hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> >> =
joyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DmghfteDzbnRINFD04bWLb2867ZMSS6BlI%2FpgS
> >> mGlQLE%3D&reserved=3D0
> >>=20
> >>  The diff files have been posted here (please refresh):
> >>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-diff.html&data=3D05%7C02%7Cantdl%40micros=
oft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011d=
b47%7C1%7C0%7C639119618966534675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO=
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3=
D%7C0%7C%7C%7C&sdata=3DVVqmlCj9P4atZzeQ87%2FBjqGgwXb96rj9Air9B7Q2L8w%3D&re=
served=3D0
> >>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-rfcdiff.html&data=3D05%7C02%7Cantdl%40mic=
rosoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd0=
11db47%7C1%7C0%7C639119618966551383%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG=
kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3=
D%3D%7C0%7C%7C%7C&sdata=3DwIeTYi90zSS9cANvolYbIOnCcjvnAsOzYrqraYGY5BE%3D&r=
eserved=3D0 (side by side)
> >>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-auth48diff.html&data=3D05%7C02%7Cantdl%40=
microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7=
cd011db47%7C1%7C0%7C639119618966570928%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1=
hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf=
Q%3D%3D%7C0%7C%7C%7C&sdata=3D70TQXtKhS9scGNPiA1IYy6Axi72aB4WiwG3ILX4x4%2B0=
%3D&reserved=3D0
> >>=20
> >> https://www/.
> >> =
rfc-editor.org%2Fauthors%2Frfc9942-auth48rfcdiff.html&data=3D05%7C02%7Ca
> >> =
ntdl%40microsoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f1
> >> =
41af91ab2d7cd011db47%7C1%7C0%7C639117967933344410%7CUnknown%7CTWFpbGZs
> >> =
b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
> >> =
oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DNJnco6RugvGf9mCQrMTvIBm7
> >> 5rSWW3SESirynUFJheU%3D&reserved=3D0 (side by side)
> >>=20
> >> 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.
> >>=20
> >> 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.
> >>=20
> >> The AUTH48 status page for RFC-to-be 9942 is viewable here:
> >>=20
> >> https://www/.
> >> =
rfc-editor.org%2Fauth48%2Frfc9942&data=3D05%7C02%7Cantdl%40microsoft.com
> >> =
%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47
> >> =
%7C1%7C0%7C639117967933364597%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> >> =
OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> >> =
%3D%3D%7C0%7C%7C%7C&sdata=3DYV6LHK1h8WupPZed0nA9YLZ0Bns%2FNri2KLJYpyZ7TO
> >> A%3D&reserved=3D0
> >>=20
> >> Further cluster information is viewable here:
> >>=20
> >> https://www/.
> >> =
rfc-editor.org%2Fcluster_info.php%3Fcid%3DC557&data=3D05%7C02%7Cantdl%40
> >> =
microsoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91a
> >> =
b2d7cd011db47%7C1%7C0%7C639117967933385568%7CUnknown%7CTWFpbGZsb3d8eyJ
> >> =
FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
> >> =
CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DZtnb%2B8Pf7wdXY2UJZKlKxohciQVfn
> >> kvLyBAlZ2iYklI%3D&reserved=3D0
> >>=20
> >> Thank you.
> >>=20
> >> Megan Ferguson
> >> RFC Production Center
> >>=20
> >>>=20
> >>>=20
> >>> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9942
> >>> <draft-ietf-cose-merkle-tree-proofs-18> for your review
> >>>=20
> >>> Authors,
> >>>=20
> >>> While reviewing this document during AUTH48, please resolve (as =
necessary) the following questions, which are also in the source file.
> >>>=20
> >>> 1) <!-- [rfced] Please note that the title of the document has =
been
> >>>     updated as follows:
> >>>=20
> >>> a) We have flipped the abbreviation and expansion for COSE to =
match
> >>> similar uses in past RFC titles.
> >>>=20
> >>> Original:
> >>> COSE (CBOR Object Signing and Encryption) Receipts
> >>>=20
> >>> Current:
> >>> CBOR Object Signing and Encryption (COSE) Receipts
> >>>=20
> >>> b) We have updated the "short title" (in the running header of the
> >>> PDF
> >>> version) as follows:
> >>>=20
> >>> Original:
> >>> COSE (CBOR Object Signing and Encryption) Receipts
> >>>=20
> >>> Current:
> >>> COSE Receipts
> >>> -->
> >>>=20
> >>>=20
> >>> 2) <!-- [rfced] Please insert any keywords (beyond those that =
appear
> >>> in the title) for use on
> >>> https://ww/
> >>> =
w.rfc-editor.org%2Fsearch&data=3D05%7C02%7Cantdl%40microsoft.com%7Cdcf
> >>> =
e6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1
> >>> =
%7C0%7C639117967933405199%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> >>> =
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> >>> =
%3D%3D%7C0%7C%7C%7C&sdata=3DzV3VFSc1LzeIRrm6mMfeThcuBArpvyasrJtWSg7o2B
> >>> 4%3D&reserved=3D0. -->
> >>>=20
> >>>=20
> >>> 3) <!--[rfced] We had the following questions related to the =
Terminology
> >>>     section:
> >>>=20
> >>> a) Would you like the terms to be alphabetized for the ease of the
> >>> reader?
> >>>=20
> >>> 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.
> >>>=20
> >>> Original:
> >>>   The terms "header", "payload", and "to-be-signed bytes" are =
defined
> >>>   in [STD96].
> >>>=20
> >>> 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".)
> >>>=20
> >>> If so, please let us know how/where to add as well as if the
> >>> reference entry would be normative or informative.
> >>>=20
> >>> 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?
> >>>=20
> >>> envelope
> >>> non-equivocation
> >>> statement
> >>> transparency service
> >>>=20
> >>>=20
> >>> 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).
> >>>=20
> >>> -->
> >>>=20
> >>>=20
> >>> 4) <!--[rfced] This sentence doesn't parse.  Please let us know =
how to
> >>>     update.
> >>>=20
> >>> 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.
> >>> -->
> >>>=20
> >>>=20
> >>> 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.
> >>>        -->
> >>>=20
> >>>=20
> >>> 6) <!--[rfced] We had two questions related to this document's use =
of the
> >>>     term "SHA256":
> >>>=20
> >>> 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.
> >>>=20
> >>> b) We see both SHA256 and sha-256 in running text.  Should these =
be
> >>> made uniform as SHA256?
> >>>=20
> >>> -->
> >>>=20
> >>>=20
> >>> 7) <!-- [rfced] We note that [RFC9162] uses "leaf_index" rather =
than
> >>>     "leaf-index".  Please review and let us know if updates should =
be
> >>>     made.
> >>>=20
> >>> Current:
> >>>  The term leaf-index is used for alignment with the use =
established in
> >>>  Section 2.1.3.2 of [RFC9162].
> >>> -->
> >>>=20
> >>>=20
> >>> 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.
> >>>=20
> >>> Current:
> >>>  The payload of an RFC9162_SHA256 inclusion proof signature is the
> >>>  Merkle tree hash as defined in [RFC9162].
> >>> -->
> >>>=20
> >>>=20
> >>> 9) <!--[rfced] This sentence doesn't seem to parse.  Please =
rephrase.
> >>>=20
> >>> Original:
> >>> First the verifier applies the inclusion proof to a possible entry
> >>> (set member) bytes.
> >>>=20
> >>> -->
> >>>=20
> >>>=20
> >>> 10) <!--[rfced] Please review this text for clarity (particularly =
for a
> >>>     missing verb after which?).
> >>>=20
> >>> Original:
> >>> If this process succeeds, the result is a Merkle root, which in =
the
> >>> attached as the COSE Sign1 payload.
> >>> -->
> >>>=20
> >>>=20
> >>> 11) <!--[rfced] The following may require clarification:
> >>>=20
> >>> Current:
> >>>  The privacy considerations section of [RFC9162] and [RFC9053] =
apply to
> >>>  this document.
> >>>=20
> >>> 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.
> >>> -->
> >>>=20
> >>>=20
> >>> 12) <!--[rfced] We had the following questions/comments related to =
the
> >>>     IANA Considerations section:
> >>>=20
> >>> 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.
> >>>=20
> >>> 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.
> >>>=20
> >>> 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/
> >>> =
w.iana.org%2Fassignments%2Fcose%2Fcose.xhtml%23verifiable-data-struc
> >>> =
ture-algorithms&data=3D05%7C02%7Cantdl%40microsoft.com%7Cdcfe6dabd4f64
> >>> =
1837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639
> >>> =
117967933424805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> >>> =
OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> >>> =
%7C%7C%7C&sdata=3DsNzsRJzHbjTjioaKB48QaDOvdF1srGfB44dnkmboAZQ%3D&reser
> >>> ved=3D0 will be communicate to IANA by the RPC once AUTH48
> >>> completes.-->
> >>>=20
> >>>=20
> >>> 13)  <!--[rfced] We had the following questions/comments related =
to
> >>>      abbreviations used throughout the document.
> >>>=20
> >>> 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.
> >>>=20
> >>> 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/
> >>> =
w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=3D05%7C02%7Cant=
dl%40microsoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91=
ab2d7cd011db47%7C1%7C0%7C639117967933442934%7CUnknown%7CTWFpbGZsb3d8eyJFbX=
B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU=
IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DFlAcTamXBVIZ7jGzQY4qfDlIYV8uIpEEdZIesb25=
l2I%3D&reserved=3D0 for the following abbreviations.  Please let us know =
any objections.
> >>>=20
> >>> VDS
> >>> VDP
> >>>=20
> >>> *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?
> >>>=20
> >>> **Note: We also see "verifiable data structure algorithm proofs".
> >>> Could this be made "VDP algorithms"?
> >>>=20
> >>> c) Things get a bit messy when we look at the expansion of VDP if
> >>> the expansion of "P" is plural "proofs".
> >>>=20
> >>> For example, in the following:
> >>>=20
> >>> Original:
> >>> This document describes how to convey VDS and associated VDP types
> >>> in unified COSE envelopes.
> >>>=20
> >>> If we were to expand this, we'd get "verifiable data structure
> >>> proofs types" (with the double plurals).
> >>>=20
> >>> However, sometimes the -s on proof disappears when this was =
expanded
> >>> in the text.
> >>>=20
> >>> For example:
> >>>=20
> >>> Original:
> >>> ..defining the integers used to identify verifiable data structure
> >>> proof types...
> >>>=20
> >>> and
> >>>=20
> >>> Original:
> >>> A data structure which supports one or more Verifiable Data
> >>> Structure Proof Types.
> >>>=20
> >>> It's also a bit strange for it to be plural here:
> >>>=20
> >>> Original:
> >>> The combination of representations of various VDS and VDP can
> >>> significantly increase the burden for implementers and create
> >>> interoperability challenges for transparency services.
> >>>=20
> >>> Where we will have to make it "various VDSs and VDP" (the reader
> >>> will likely expect VDPs).
> >>>=20
> >>> Is it possible to update to use Verifiable Data Structure Proofs
> >>> (VDPs)?
> >>>=20
> >>>=20
> >>> -->
> >>>=20
> >>>=20
> >>> 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.
> >>>=20
> >>> <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>
> >>>=20
> >>> -->
> >>>=20
> >>>=20
> >>> 15) <!-- [rfced] Please review the "Inclusive Language" portion of =
the
> >>>     online Style Guide
> >>>     =
<https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.r=
fc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=3D05%7C02%=
7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f14=
1af91ab2d7cd011db47%7C1%7C0%7C639119618966586519%7CUnknown%7CTWFpbGZsb3d8e=
yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI=
sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DtzAyeyC%2FeawpZPNfUdI7pVhtQPABSjeyi=
5dYraqXUls%3D&reserved=3D0>
> >>>     and let us know if any changes are needed.  Updates of this
> >>>     nature typically result in more precise language, which is
> >>>     helpful for readers.
> >>>=20
> >>> Note that our script did not flag any words in particular, but =
this
> >>> should still be reviewed as a best practice.
> >>>=20
> >>> -->
> >>>=20
> >>>=20
> >>> Thank you.
> >>>=20
> >>> Megan Ferguson
> >>> RFC Production Center
> >>>=20
> >>> *****IMPORTANT*****
> >>>=20
> >>> Updated 2026/03/06
> >>>=20
> >>> RFC Author(s):
> >>> --------------
> >>>=20
> >>> Instructions for Completing AUTH48
> >>>=20
> >>> 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=3Dhttps%3A%2F%2Fwww.r=
fc-editor.org%2Ffaq%2F&data=3D05%7C02%7Cantdl%40microsoft.com%7C050d698d1d=
9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119=
618966606408%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM=
DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
=3DENkUmQhVN2%2BVtjmREbe8CMWw%2FiWsJCeDWo0iP3q1Vq4%3D&reserved=3D0).
> >>>=20
> >>> You and you coauthors are responsible for engaging other parties
> >>> (e.g., Contributors or Working Group) as necessary before =
providing
> >>> your approval.
> >>>=20
> >>> Planning your review
> >>> ---------------------
> >>>=20
> >>> Please review the following aspects of your document:
> >>>=20
> >>> *  RFC Editor questions
> >>>=20
> >>>   Please review and resolve any questions raised by the RFC Editor
> >>>   that have been included in the XML file as comments marked as
> >>>   follows:
> >>>=20
> >>>   <!-- [rfced] ... -->
> >>>=20
> >>>   These questions will also be sent in a subsequent email.
> >>>=20
> >>> *  Changes submitted by coauthors
> >>>=20
> >>>   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.
> >>>=20
> >>> *  Content
> >>>=20
> >>>   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
> >>>=20
> >>> *  Copyright notices and legends
> >>>=20
> >>>   Please review the copyright notice and legends as defined in
> >>>   RFC 5378 and the Trust Legal Provisions
> >>>   (TLP =E2=80=93 =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftruste=
e.ietf.org%2Flicense-info&data=3D05%7C02%7Cantdl%40microsoft.com%7C050d698=
d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639=
119618966628254%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj=
AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd=
ata=3D3Z0WNOkjOgJdxMtVxG2cgsEE2c%2FAjGytSkjla8uMYEw%3D&reserved=3D0).
> >>>=20
> >>> *  Semantic markup
> >>>=20
> >>>   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=3Dhttps%3A%2F%2Fautho=
rs.ietf.org%2Frfcxml-vocabulary&data=3D05%7C02%7Cantdl%40microsoft.com%7C0=
50d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0=
%7C639119618966649096%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi=
OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C=
%7C&sdata=3Dmq4RGj9NfnNfN%2Flk70qyMfIVYxvhd0WRavHU5MyTHYE%3D&reserved=3D0>=
.
> >>>=20
> >>> *  Formatted output
> >>>=20
> >>>   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.
> >>>=20
> >>>=20
> >>> Submitting changes
> >>> ------------------
> >>>=20
> >>> To submit changes, please reply to this email using =E2=80=98REPLY =
ALL=E2=80=99 as
> >>> all the parties CCed on this message need to see your changes. The
> >>> parties
> >>> include:
> >>>=20
> >>>   *  your coauthors
> >>>=20
> >>>   *  rfc-editor@rfc-editor.org (the RPC team)
> >>>=20
> >>>   *  other document participants, depending on the stream (e.g.,
> >>>      IETF Stream participants are your working group chairs, the
> >>>      responsible ADs, and the document shepherd).
> >>>=20
> >>>   *  auth48archive@rfc-editor.org, which is a new archival mailing =
list
> >>>      to preserve AUTH48 conversations; it is not an active =
discussion
> >>>      list:
> >>>=20
> >>>     *  More info:
> >>>=20
> >>> https://ma/
> >>> =
ilarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxI
> >>> =
Ae6P8O4Zc&data=3D05%7C02%7Cantdl%40microsoft.com%7Cdcfe6dabd4f641837df
> >>> =
808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639117967
> >>> =
933523144%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> >>> =
AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> >>> =
%7C&sdata=3DAO1dwmJfnFANnE0FZEedZD4KJ7nG3d0wQQ0LtYNOZdA%3D&reserved=3D0
> >>>=20
> >>>     *  The archive itself:
> >>>=20
> >>> https://ma/
> >>> =
ilarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=3D05%7C02%7
> >>> =
Cantdl%40microsoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf
> >>> =
86f141af91ab2d7cd011db47%7C1%7C0%7C639117967933540368%7CUnknown%7CTW
> >>> =
FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> >>> =
IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D49r8yM4AczDKOe
> >>> uU53PknXmrIVsu%2BPIkfgzt13FjSu4%3D&reserved=3D0
> >>>=20
> >>>     *  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,
> >>>        auth48archive@rfc-editor.org will be re-added to the CC =
list and
> >>>        its addition will be noted at the top of the message.
> >>>=20
> >>> You may submit your changes in one of two ways:
> >>>=20
> >>> An update to the provided XML file
> >>> =E2=80=94 OR =E2=80=94
> >>> An explicit list of changes in this format
> >>>=20
> >>> Section # (or indicate Global)
> >>>=20
> >>> OLD:
> >>> old text
> >>>=20
> >>> NEW:
> >>> new text
> >>>=20
> >>> You do not need to reply with both an updated XML file and an
> >>> explicit list of changes, as either form is sufficient.
> >>>=20
> >>> 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.
> >>>=20
> >>>=20
> >>> Approving for publication
> >>> --------------------------
> >>>=20
> >>> To approve your RFC for publication, please reply to this email
> >>> stating that you approve this RFC for publication.  Please use
> >>> =E2=80=98REPLY ALL=E2=80=99, as all the parties CCed on this =
message need to see your approval.
> >>>=20
> >>>=20
> >>> Files
> >>> -----
> >>>=20
> >>> The files are available here:
> >>>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.xml&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966673791%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3DwE17aWJCxEFrgMjER9Re7ALRq8TJ9Wtw6G4g4i%2B%2FaTU%3D&reserv=
ed=3D0
> >>>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.html&data=3D05%7C02%7Cantdl%40microsoft.c=
om%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7=
C1%7C0%7C639119618966696945%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW=
UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0=
%7C%7C%7C&sdata=3DU16XsgfdOvDTgsuxJvWKEaAjvy00xIzc%2FB1EkcFubmE%3D&reserve=
d=3D0
> >>>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942.pdf&data=3D05%7C02%7Cantdl%40microsoft.co=
m%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C639119618966717085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&sdata=3DEg0m5dTLAddo8oatk2UbMAA99XWKGA8TpPrgX51DuaE%3D&reserved=3D=
0
> >>>=20
> >>> https://ww/
> >>> =
w.rfc-editor.org%2Fauthors%2Frfc9942.txt&data=3D05%7C02%7Cantdl%40micr
> >>> =
osoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2
> >>> =
d7cd011db47%7C1%7C0%7C639117967933610534%7CUnknown%7CTWFpbGZsb3d8eyJ
> >>> =
FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> >>> =
pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D0Xs8fRQn%2F9s%2FKR4KKOb3t3s
> >>> MkwrQeOsS50MxigL29u4%3D&reserved=3D0
> >>>=20
> >>> Diff file of the text:
> >>>   =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rf=
c-editor.org%2Fauthors%2Frfc9942-diff.html&data=3D05%7C02%7Cantdl%40micros=
oft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011d=
b47%7C1%7C0%7C639119618966736976%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO=
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3=
D%7C0%7C%7C%7C&sdata=3DZJ73QiU002PuLoS5cEM84LopcvrhxZklzKdZLd1l6Ws%3D&rese=
rved=3D0
> >>>=20
> >>> https://ww/
> >>> =
w.rfc-editor.org%2Fauthors%2Frfc9942-rfcdiff.html&data=3D05%7C02%7Cant
> >>> =
dl%40microsoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f1
> >>> =
41af91ab2d7cd011db47%7C1%7C0%7C639117967933637548%7CUnknown%7CTWFpbG
> >>> =
Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
> >>> =
FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D4JkPMy%2FiIdR3z4AO
> >>> xDm9Z%2FFakeBp9aglNClQjCRfQc8%3D&reserved=3D0 (side by side)
> >>>=20
> >>> Diff of the XML:
> >>>=20
> >>> https://ww/
> >>> =
w.rfc-editor.org%2Fauthors%2Frfc9942-xmldiff1.html&data=3D05%7C02%7Can
> >>> =
tdl%40microsoft.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f
> >>> =
141af91ab2d7cd011db47%7C1%7C0%7C639117967933653396%7CUnknown%7CTWFpb
> >>> =
GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> >>> =
kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Dy3%2FCQOq%2FC4kWF
> >>> %2BOKUOXlf2g4DRYowG4BNqUSl9xehWI%3D&reserved=3D0
> >>>=20
> >>>=20
> >>> Tracking progress
> >>> -----------------
> >>>=20
> >>> The details of the AUTH48 status of your document are here:
> >>>=20
> >>> https://ww/
> >>> =
w.rfc-editor.org%2Fauth48%2Frfc9942&data=3D05%7C02%7Cantdl%40microsoft
> >>> =
.com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd0
> >>> =
11db47%7C1%7C0%7C639117967933672481%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> >>> =
eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> >>> =
IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DznCCRuGuMv8k2jGpXl1kM3BP2OMX32kE
> >>> KcPjcdcsu84%3D&reserved=3D0
> >>>=20
> >>> Please let us know if you have any questions.
> >>>=20
> >>> Thank you for your cooperation,
> >>>=20
> >>> RFC Editor
> >>>=20
> >>> --------------------------------------
> >>> RFC9942 (draft-ietf-cose-merkle-tree-proofs-18)
> >>>=20
> >>> 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
> >>>=20
> >>> Area Director(s) : Deb Cooley, Paul Wouters
> >> <rfc9942.xml>
> >=20
>=20
> <rfc9942.xml>