Thanks for your comments on this document. The parameters for VDS are modeled after the parameters for COSE Keys.
The reason being that key parameters enable different processes, such as "signing" or "encryption"... With a VDS, different parameters enable proving inclusion or consistency for the data structure. The CDDL here makes this clear: https://datatracker.ietf.org/doc/html/draft-ietf-cose-merkle-tree-proofs-08#section-5.3.1-6 The abstract states: """ COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. """ The introduction has this text: """ Different VDS can produce different verifiable data structure proofs (VDP). The combination of representations of various VDS and VDP can significantly increase burden for implementers and create interoperability challenges for transparency services. This document describes how to convey VDS and associated VDP types in unified COSE envelopes. """ I agree that the current text regarding parameters and proofs is confusing. I think the missing language is something to the effect of: Proofs for different properties of a VDS are conveyed through the use of verifiable data structure parameters (VDP) which are specific to the verifiable data structure (VDS). Although this text is very close to the current definition found here: https://datatracker.ietf.org/doc/html/draft-ietf-cose-merkle-tree-proofs-08#section-3-1.8.1 I'm not sure if I agree with the comment I made regarding proofs... after reviewing the text again, it seems that both the terms "parameters" and "proofs" may be valuable to preserve. PRs for improving clarity are welcome. Regards, OS On Fri, Feb 28, 2025 at 11:43 AM Amaury Chamayou <Amaury.Chamayou= [email protected]> wrote: > Hello, > > Section 3. Terminology of > https://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/08/ > defines > VDP as: > > Verifiable Data Structure Parameters (VDP): Parameters to a > verifiable data structure that are used to prove properties, such > as authentication, inclusion, consistency, and freshness. > Parameters can include multiple proofs of a given type, or > multiple types of proof (inclusion and consistency). This > property is conceptually similar to COSE Header Parameter "epk" > (-1) or CBOR Web Token (CWT) claim "cnf" (8), it is applied to a > verifiable data structure, to confirm a property. For example an > encrypted message might be decrypted using epk and a private key, > a digital signature for authentication might be verified using cnf > and the (CWT) claim "nonce" and "audience", and an inclusion proof > for a binary merkle tree might be verified with VDP and some entry > that is being tested or inclusion in the tree. > > > But every other use of VDP in the document is expanded to "proof" instead, > including 1. Introduction: > > Different VDS can produce different verifiable datastructure proofs (VDP). > > This is inconsistent and confusing, and leaves the document in a state > where "Verifiable Datastructure Proof" is effectively undefined. Could this > discrepancy be resolved before RFC? > > Orie Steele has suggested that VDP should be Parameter everywhere, to > follow IETF conventions, and that "proof" should not be used in the final > document. I have no opinion, I would only like consistency one way or > another. > > I am very happy to do a PR if that is acceptable. > > Thank you, > Amaury > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
