Authors, While reviewing this cluster of documents*, please reply to the questions below regarding consistency across the cluster. These questions are in addition to the document-specific questions sent for each RFC-to-be. Your reply will likely impact both of the documents in the cluster, so please discuss off-list as necessary, and then let us know how to proceed.
Note - You have the option of updating the edited XML files yourself, if you prefer. We will wait to hear from you before continuing with the publication process. * Cluster 557 (C557) currently in AUTH48 state: https://www.rfc-editor.org/authors/rfc9942.html https://www.rfc-editor.org/authors/rfc9943.html (In addition, the .pdf, .txt, .xml, and diff files are available.) You may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C557 1) We had a number of questions related to the consistent use of terminology throughout the cluster: a) We will update to use the form on the right for all instances that occur in prose throughout the cluster unless we hear objection: COSE key type vs. COSE Key Type Note: RFCs 9052/9053 only use this term in registry titles COSE_Sign1 vs. COSE Sign1 vs. 'COSE_Sign1' Note: RFCs 9052/9053 use COSE_Sign1 consistently (underscore no quotes) 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. COSE Objects vs. COSE signed object Note: RFCs 9052/9053 have no instances of COSE signed object COSE Envelope vs. COSE envelope Note: RFCs 9052/9053 use Enveloped COSE Structure as a section title and envelope (lowercase) generally, but there are no other instances of COSE Envelope. Algorithm vs. algorithm (when used with verifiable data structure in any of its forms (capped, abbreviated, etc.)) Note: RFCs 9052/9053 use lowercase algorithm throughout (except in titles) Append-only vs. append-only vs. append only Note: RFCs 9052/9053 do not use this term. Transparency Service vs. Transparency service vs. transparency service (see possible related question about TS in scitt) Note: RFCs 9052/9053 do not use this term. Inclusion Proof vs. Inclusion proof vs. "inclusion proof" vs. inclusion proof (see also proof of inclusion, proofs of type "inclusion") Note: RFCs 9052/9053 do not use this term. Signed Inclusion Proofs vs. signed proofs Note: RFCs 9052/9053 do not use this term. Consistency Proof vs. "consistency proof" vs. consistency proof (see also proof of consistency Note: RFCs 9052/9053 do not use this term. Tree Size vs. tree size Note: RFCs 9052/9053 do not use this term. Merkle Tree vs. Merkle tree Note: RFCs 9052/9053 do not use this term. Merkle tree root vs. Merkle root tree vs. Merkle root (see also Merkle root tree-size) Note: RFCs 9052/9053 do not use this term. Receipt vs. receipt Note: RFC 9052 includes a single instance of the term receipt that seems to be used in the general sense. Proof Type vs. proof type Note: RFCs 9052/9053 do not use this term. c) We see that both documents have slightly different definitions for some of the same terms. Should these be made more uniform or more consistent? Or might it be best to define them in one document and point to the definition in the Terminology section of the other document? In draft-ietf-cose-merkle-tree-proofs-18: Verifiable Data Structure (VDS): A data structure which supports one or more Verifiable Data Structure Proof Types. This property describes an algorithm used to maintain a verifiable data structure, for example a binary Merkle tree algorithm. vs. In draft-ietf-scitt-architecture-22: Verifiable Data Structure: a data structure which supports one or more proof types, such as "inclusion proofs" or "consistency proofs", for Signed Statements as they are Registered to a Transparency Service. SCITT supports multiple Verifiable Data Structures and Receipt formats as defined in [I-D.draft-ietf-cose-merkle-tree-proofs], accommodating different Transparency Service implementations. and In draft-ietf-cose-merkle-tree-proofs-18: Receipt: A COSE object, as defined in [RFC9052], containing the header parameters necessary to convey VDP for an associated VDS. vs. In draft-ietf-scitt-architecture-22: Receipt: a cryptographic proof that a Signed Statement is included in the Verifiable Data Structure. See [I-D.draft-ietf-cose-merkle-tree-proofs] for implementations. Receipts are signed proofs of verifiable data-structure properties. Receipt Profiles implemented by a Transparency Service MUST support inclusion proofs and MAY support other proof types, such as consistency proofs. 2) C. Fournet and A. Delignat-Lavaud have two different affiliations in the headers: Microsoft Research vs. Microsoft And both have listed different addresses (same address for both authors) in the two docs (see below). Please let us know which you would like to use for both documents in the cluster. For example: Cedric Fournet Microsoft Research 21 Station Road Cambridge CB1 2FB United Kingdom Email: [email protected] vs. Cedric Fournet Microsoft United Kingdom Email: [email protected] -------------------------------------- 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 -------------------------------------- RFC9943 (draft-ietf-scitt-architecture-22) Title : An Architecture for Trustworthy and Transparent Digital Supply Chains Author(s) : H. Birkholz, A. Delignat-Lavaud, C. Fournet, Y. Deshpande, S. Lasker WG Chair(s) : Jon Geater, Christopher Inacio Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
