Hi Deb! Thanks for your comments on this document.
For producing receipts, any COSE signature algorithm can be used, including PQC ones. This spec does not make assumptions about storing the COSE sign1, only the leaves and intermediate nodes necessary to verify the root, and the format of a receipt in CBOR. For a standard binary Merkle tree with a height of h, a single signature on the root can be used to authenticate 2^h separate items. This specification targeted initial compatibility with CT trees, so that software could be easily reused, but with the establishment of the registry, we also open the door to other tree structures that are not compatible with CT trees. While SCITT requires the leaves be COSE Sign1, this document does not require that, only that the receipts need to be COSE Sign1, so the leaves could be anything that needed to be batched. For example, https://datatracker.ietf.org/doc/draft-joseph-tls-batch-signatures/ I spoke with some of the authors of the tls draft above at IETF 116, and we considered what it would be like if a batched signature scheme existed that was format agnostic (no CBOR, JSON or ASN.1 dependencies). With the right layering, we could all share batch signature primitives... but protocols would need some adjustment to support batch signatures instead of traditional ones. I would expect any ecosystem that already had a signature scheme that was not based on COSE to be suspicious of needing to add COSE to do batched signatures, but the approach we took in this document could be applied to JSON, or ASN.1 There is a related topic, where you get a receipt for a receipt... This was discussed in SCITT, but ultimately, the WG decided to not describe that behavior, because it requires normalizing receipts (COSE Sign1 has unprotected headers) to produce consistent leaf hashes. That flow looks like: msg_1...msg_5 -> receipt_1 msg_6...msg_10 -> receipt_2 receipt_1...receipt_2 -> receipt_a Here receipt_1 and receipt_2 are "batched signature receipts", but receipt_a is "batch of batch signature receipts". This specification is also silent on this matter, but does not preclude it. I've not been able to follow PLANTS, but it's possible they could take a similar approach with or without COSE / CBOR. Regards, OS On Tue, Sep 9, 2025 at 6:26 AM Deb Cooley <[email protected]> wrote: > These updates answer my comment (name of the registry) > > Just be aware, RFC9162 (CTv2.0) has not been implemented. The 'Binary > Merkle Tree' parts of the specification are fine. > > Also FYI, there will be a BOF at IETF124 (PLANTS) which will propose a way > to reduce the signature load within the merkle trees for CT. The size of > signatures (and the number of signatures) will dramatically increase the > size of the stored data. While you all have decided that it is 'too early' > to plan for PQC, they have not. You all may be able to leverage that work > in a future revision of this specification. > > Deb > > On Tue, Sep 2, 2025 at 10:34 AM Henk Birkholz <[email protected]> > wrote: > >> Hi Deb, >> hi med >> >> @Deb: we addressed all of your comments but the Section 7 one: "probably >> too early for this". We think you are right, but still we pondered on >> this topic for a while. The editors current agreement is to not add more >> text on this subject today. We agree with your reasoning in principle >> and also think that this will be addressed in a subsequent I-D that >> updates this one in the fullness of time. >> >> @Med: we think we rendered the abstract self-contained (by only >> mentioning RFC 9162 instead if including a ref in an abstract, sorry >> btw...). Please check, if you are happy with that! >> >> Otherwise, we think we addressed all IESG feedback. Please find the diff >> at: >> >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-cose-merkle-tree-proofs-16 >> >> >> For the author/editors, >> >> Henk >> >> >> >> On 02.08.25 14:54, Deb Cooley via Datatracker wrote: >> > Deb Cooley has entered the following ballot position for >> > draft-ietf-cose-merkle-tree-proofs-14: No Objection >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> > for more information about how to handle DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > Thanks to Charlie Kaufman for their secdir review (his nits still exist >> in the >> > draft, btw). >> > >> > Section 4.1, 8.2.2: I don't love the fact that the registry called >> 'COSE >> > Verifiable Data Structures' is actually an algorithm registry - super >> > confusing. Moreover, the description in the registration template in >> Section >> > 8.2.2 says nothing about algorithms. In section 4.1, there is a >> sentence that >> > calls it 'a registry of verifiable data structure algorithms'. Can we >> change >> > the name of the registry to that? >> > >> > Section 7: While I think it is probably too early for this, it might >> be wise >> > to have a post quantum section here warning of an eventual shift in >> algorithms. >> > Depending on how long the proofs and receipts are expected to be >> valid will >> > determine how soon an algorithm migration should be considered. I >> would be >> > happy to help write it if that is helpful. Note: I would expect that >> this >> > includes both the hash (currently only SHA-2 256 is registered) and the >> > signatures. >> > >> > Authors: A nit... Will Orie change his contact details before >> publication? >> > Seems like it might be better in the long run. >> > >> > >> > >> >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
