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]
