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]
