Opened 7 years ago

Closed 7 years ago

#82 closed enhancement (fixed)

Add a way to get the SCTs for entries returned by get-entries

Reported by: pphaneuf@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:


When monitoring a log, get-entries provide no assurance against in-flight corruption. It will get caught once verifying the entries against an STH, but that makes it hard to act upon (can't tell which exactly entry is corrupted, for example).

Also, the question of how to fetch the SCT for a logged entry has been asked a few times.

One way to solve both problems at once would be to return the SCT signature in get-entries. The rest of the data for the SCT is already there, and since it's done over all this data and the entry's digest, it should provide a way to check the integrity of the entry.

Change History (8)

comment:1 Changed 7 years ago by rob.stradling@…

  • Component changed from client-behavior to rfc6962-bis

comment:2 Changed 7 years ago by eranm@…

SGTM - providing the SCTs together with entries in the get-entries response would enable efficient mirroring of logs and integrity checking of returned entries (although not for truncated responses).
It seems most suitable to encapsulate the entire output of add-chain/add-pre-chain in an additional field for each entry returned by get-entries (named 'sct').

comment:3 Changed 7 years ago by eranm@…

Note that the SCTs do not cover the extra_data hence this addition will not provide integrity for the extra_data field (but accessing logs over HTTPS, which the RFC mandates they support, would).

comment:4 Changed 7 years ago by eranm@…

  • Summary changed from add integrity validation to get-entries (and fetching SCTs?) to Add a way to get the SCTs for entries returned by get-entries

comment:5 Changed 7 years ago by eranm@…

Out for review in

I've changed the ticket to reflect that what's needed is a way to get back SCTs, not integrity validation to get-entries:

  • Integrity can be provided by accessing the log over HTTPS (assuming the TLS client checks the log's certificate chain correctly).
  • the extra_data field is not currently covered by any signature so it'd be impossible to distinguish between transit and storage corruptions.
  • Providing the SCTs is enough to allow log mirroring.

comment:6 Changed 7 years ago by benl@…

It is not really true that fetching over HTTPS provides integrity: for a start, HTTPS is only as good as its inputs, which could be corrupted before HTTPS gets its hands on them.

comment:8 Changed 7 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.