Subject: Re: [Trans] [Public Notary Transparency Wiki] #162: Bound the set of artifacts a log is expected to produce

From: "trans issue tracker" <[email-masked]>
Date: Mon, 15 May 2017 16:29:43 -0000

#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