On Thu, Apr 21, 2022 at 01:46:37PM +0000, Maik Riechert wrote: > Hi all, > > As part of SCITT we've extended the concept of COSE countersignatures to work > within structures like Merkle trees, commonly used in transparency ledgers: > > https://ietf-scitt.github.io/draft-birkholz-scitt-receipts/draft-birkholz-scitt-receipts.html > > For the signing and verification process, we've re-used the > Countersign_structure of COSE_Sign1 V2 countersignatures: > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign-05#section-3.3 > > In the context of SCITT, we call those countersignatures "receipts". > > One of the realizations was that there is not just a single type of Merkle > tree, and in order to support multiple variants we are proposing to establish > a registry of "tree algorithms" (possibly not the best term) that define, > amongst others, the concrete receipt content data structure and how > verification and generation works. > > In the current draft, we defined a single algorithm called "CCF 2 Tree > Algorithm" that is compatible with the CCF framework (version 2) developed by > Microsoft. We didn't just call it "Binary Merkle Tree algorithm" because we > felt that wasn't specific enough and would have required a much longer name > to make sense. > > The purpose of this thread is to invite comments from the SCITT and COSE > communities.
On first look this seems unobjectionable. The draft seems to list the registration policy for the Tree Algorithms registry as "TBD"; I would advise a lenient policy like "Expert Review" or "Specification Required" (maybe even "First Come, First Served"!) since the purpose of the registry seems to be to avoid collisions rather than to reliably avoid dupication of effort. -Ben _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
