Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key

From: Linus Nordberg <[email-masked]>
Date: Fri, 03 Jun 2016 13:01:54 +0200

Hi,

I like that -- if you're not gossiping SCT plus full chain, gossip SCT
plus the input needed for producing the real unique key of the log,
i.e. the merkle tree leaf. Making it mandatory should not complicate the
gossip protocol much, but I'll investigate.

Regarding your first point for why an SCT alone is not useful, I'm not
sure that I understand how a log could drop such a reqeust. If a log
doesn't reply to a request it's supposed to support it's misbehaving,
isn't it?  And SCT's are certainly signed so the log can indeed be held
accountable.

I agree that implementing a "best effort" get-entry-by-sct request is
trivial -- try verifying the SCT against all entries until you find the
match, return the match. Using the timestamp as a hint of where to start
looking is probably a good optimisation. It might even be efficient.

Eran Messeri <[email-masked]> wrote
Thu, 19 May 2016 18:07:01 +0100:

> Back to dkg's original question, I'd suggest gossiping the MerkleTreeLeaf
> (RFC6962) / TransItem containing TimestampedCertificateEntryDataV2
> (RFC6962-bis).
>
> For each of the protocols, that's the data structure necessary to validate
> the signature in the SCT *and* to audit the log (because these data
> structures themselves are not signed they cannot be the only thing that's
> gossiped).
>
> IMHO gossiping only the SCT is not very useful, even if logs offer
> get-entry-by-sct:
> * A log could deny / drop such a request (as it's not signed), in which
> case the client's recourse is a download of the entire log.
> * Without the data covered by the signature, there's no meaningful
> auditing: the entity holding the SCT does not know which certificate hasn't
> been incorporated into the log.
>
> Re get-entry-by-sct, as it does complicate implementation, one option is to
> make this API optional (which is a particularly viable approach as it can
> be implemented by a log mirror based on data from a log that does not
> implement it).
>
> Eran
>
>
> On Thu, May 19, 2016 at 3:56 PM, Linus Nordberg <[email-masked]> wrote:
>
>> Ben Laurie <[email-masked]> wrote
>> Wed, 18 May 2016 18:30:37 +0100:
>>
>> | On 18 May 2016 at 17:23, Linus Nordberg <[email-masked]> wrote:
>> | > Ben Laurie <[email-masked]> wrote
>> | > Fri, 13 May 2016 15:56:44 +0100:
>> | >
>> | > | Actually, it seems to me that the simplest answer is to allow lookups
>> | > | in logs based on SCT alone. Then the SCT can be validated using the
>> | > | retrieved chain.
>> | >
>> | > That seems odd. From a logs point of view, an SCT is not a persistent
>> | > object.
>> | >
>> | > I don't know about other implementations but catlfish would not be able
>> | > to efficiently find an entry in the database given only an SCT.
>> |
>> | Are you saying there's some technical barrier to doing this, or just
>> | that as it stands you wouldn't be able to?
>>
>> I was being inprecise. I should have said that it would require some
>> redesign.
>>
>>
>> | It seems to me that the log could easily save SCTs it issued alongside
>> | the cert chains it issued them for.
>>
>> All SCT's for every chain, I presume, if there's going to be any point
>> in offering a lookup with an SCT as input? This would complicate things
>> at least in our design. I'm sure it could be solved at the price of more
>> complexity.
>>
>>
>> | And that it could easily create an index based on those SCTs.
>>
>>
>> | Note that 6962-bis already requires you to return SCTs in some lookups...
>>
>> You meen get-entries? I don't see how that's relevant. An SCT can be
>> generated given the data in leaf_input. No need to store it, unless you
>> wanted to for caching of course (we do that on frontend nodes). There's
>> a big difference between doing this and indexing on SCT's though.
>>
>> _______________________________________________
>> Trans mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/trans>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Linus Nordberg <[email-masked]>
Date: Fri, 03 Jun 2016 13:06:03 +0200

Ben Laurie <[email-masked]> wrote
Tue, 24 May 2016 11:25:15 +0100:

> On 19 May 2016 at 15:56, Linus Nordberg <[email-masked]> wrote:
> We were reviewing the spec for 6962-bis, and we believe it is not
> possible to have more than one SCT for any particular log entry.

I agree.

There can be more than one log entry with the same chain though, each of
which at submission returned a separate SCT. But that's beside the point
so to answer my own question: Yes, all SCT's for every chain, one per
entry. :)

> I agree there's a difference. I am curious what architecture makes it
> a big difference, though!

Here's why adding SCT's to the database is hard in our implementation.

- SCT's can not be included in the entry stored in the database

Our system doesn't trust its frontend nodes. Therefore our signing nodes
refuse to produce an SCT for an entry until they know that the entry has
been stored at a configured quorum of storage nodes.

Once an entry has been stored it doesn't change.

>From this follows that the SCT can not be included in the entry.

- SCT's can not easily be added to the database, like in a new table or
  similar

We don't have a database distribution mechanism for anything else than
log entries that almost always already are present at all storage
nodes. Adding a new type of data is doable but will take some redesign.

- One a side note, good we require deterministic signature algorithms

Using an SCT as a unique key seems hard at first, until you realise that
6962-bis mandates deterministic signatures. This is fortunate if your
key-value store isn't multi-value, which ours is not (because
complicated if you want to write once and never change, only append).

Design documents for catlfish, the database and one of the database
backends below. Happy to talk more about this.

- https://git.nordu.net/?p=catlfish.git;a=blob;f=doc/design.txt
- https://git.nordu.net/?p=plop.git;a=blob;f=doc/db.md
- https://git.nordu.net/?p=plop.git;a=blob;f=doc/permdb.md