Thanks Henk and others, it looks good to me. Deb
On Wed, Sep 10, 2025 at 5:59 AM Henk Birkholz <[email protected]> wrote: > Hi Deb, > > your your comment inspired the authors to make very clear that we do not > carry a dependency to a "failed experiment" in this specification, but > are only referring to parts a specification text specific to Merkle tree > proofs. > > Please find (hopefully our final) diff in this context here: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-cose-merkle-tree-proofs-17 > > It's pretty comprehensive and the goal of the editorial changes is to > reduce the feeling that this specification depends on RFC9162 being > implemented. > > > Viele Grüße, > > Henk > > On 09.09.25 13:25, Deb Cooley 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 > < > 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/ > < > 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/ > > < > 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
