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://www.rfc-editor.org/search. -->
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://www.iana.org/assignments/cose/cose.xhtml#verifiable-data-structure-algorithms
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://www.rfc-editor.org/styleguide/part2/#exp_abbrev 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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
Thank you.
Megan Ferguson
RFC Production Center
*****IMPORTANT*****
Updated 2026/03/06
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* 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://www.rfc-editor.org/authors/rfc9942.xml
https://www.rfc-editor.org/authors/rfc9942.html
https://www.rfc-editor.org/authors/rfc9942.pdf
https://www.rfc-editor.org/authors/rfc9942.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9942-diff.html
https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9942-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9942
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
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
