glenpowell / certificate-transparency

Automatically exported from code.google.com/p/certificate-transparency
0 stars 0 forks source link

RFC6962-bis: Need a way to obtain Merkle proofs for a batch for certificates around the SCT timestamp #33

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Section 7.3 says:
  "In order to protect the clients' privacy, these checks need not
   reveal the exact certificate to the log.  Clients can instead
   ...
   request Merkle proofs for a batch of certificates around the SCT
   timestamp."

Section 3 specifies two mechanisms to lookup a single proof - get-proof-by-hash 
and get-entry-and-proof - but there's no mechanism defined to get "proofs for a 
batch of certificates around the SCT timestamp."

Presumably TLS Clients that audit (see Issue 25) and that want to protect 
clients' privacy will need a mechanism to do this!

Suggested text...

"4.9.  Retrieve Merkle Audit Proofs from Log by Timestamp Range

   GET https://<log server>/ct/v1/get-proofs-by-timestamp-range

   Inputs:

      timestamp_1:  The earliest timestamp.

      timestamp_2:  The latest timestamp.

      tree_size:  The tree_size of the tree for which the proofs are
         desired.

   The tree size must designate an existing STH.

   Outputs:

      entries:  An array of objects (one object for each entry added to the Merkle Tree
         between timestamp_1 and timestamp_2), each consisting of

         leaf_index:  The 0-based index of the entry.

         audit_path:  An array of base64-encoded Merkle Tree nodes proving
            the inclusion of the certificate."

IIUC, the Client would be able to locate the proof it is interested in by 
looking at the zeroth node in each entry's "audit_path" until it finds the node 
it is expecting to see.

Original issue reported on code.google.com by robst...@gmail.com on 11 Feb 2014 at 2:06

GoogleCodeExporter commented 9 years ago
Migrated to http://trac.tools.ietf.org/wg/trans/trac/ticket/8.

Original comment by er...@google.com on 3 Mar 2014 at 8:39