#162: Bound the set of artifacts a log is expected to produce
-------------------------+-----------------------
Reporter: rlb@… | Owner: eranm@…
Type: defect | Status: assigned
Priority: major | Milestone:
Component: rfc6962-bis | Version:
Severity: - | Resolution:
Keywords: |
-------------------------+-----------------------
Changes (by eranm@…):
* owner: draft-ietf-trans-rfc6962-bis@… => eranm@…
* status: new => assigned
* component: to-be-decided => rfc6962-bis
Comment:
I think that the protocol should enable minimizing the number of
artifacts, but not force it.
Given that STH issuance frequency is already limited, that allows logs to
produce a limited number of consistency proofs.
As TransItems can be bundled, a "chain" of consistency proofs between STHs
can already be provided to clients. But its size would be linear in the
number of STHs, while an actual consistency proof between two STHs will be
shorter, or equal to, a chain of consistency proofs between intermediate
STHs.
In practice, no log operator has ever complained on the difficulty of
calculating inclusion and consistency proofs on-the-fly (that's never a
part we ran into difficulty implementing).
My suggestions:
* Outline how a log may limit the artifacts it produces.
* Change some of the HTTP endpoints to return a TransItemList rather than
a TransItem to accommodate a collection of inclusion/consistency proofs
and an STH.
--
Ticket URL: <https://trac.ietf.org/trac/trans/ticket/162#comment:3>
Public Notary Transparency Wiki <https://trac.ietf.org/trac/trans>
My example project
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
