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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 04 May 2016 18:12:09 -0400

hey folks--

Why aren't we explicitly including the issuer_hash in the
SignedCertificateTimestampDataV2 object?

i notice that someone who has only:

 a) an X.509 end-entity certificate and
 b) what appears to be a corresponding SCT

Can't actually evaluate the validity of the log signature on the SCT
over the certificate.  This missing data is the hash of the issuer's
public key, which is included in the signed material but isn't otherwise
available from either (a) or (b).

(i'm assuming here that (b) is a TransItem with versioned_type set to
either x509_sct_v2(3) or precert_sct_v2(4), with data set to a
SignedCertificateTimestampDataV2)

I understand that adding the issuer_hash will increase the size of the
SCT by 32 octets, but without that information, someone evaluating the
SCT has no way of knowing whether it is legitimate.

In the TLS handshake case, it's likely that the TLS client can compute
the issuer_hash by extracting the SPKI from the next cert in the offered
x.509 chain.  But in other cases (e.g. auditing, gossiping), there's no
guarantee that the issuer cert (or issuer public key) is going to be
passed alongside the SCT.

Do we want to require people to pass the issuer cert (or issuer public
key?) alongside the cert in order to be able to verify the signature on
an SCT?  If so, where is the best place to document that concern?

Or have i misunderstood the data structures?  I'm working from
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14

the issuer key hash was re-introduced here, i think:

 https://trac.tools.ietf.org/wg/trans/trac/ticket/80

but there's no consideration there for how validators are expected to
function in the absence of the full chain.

Any thoughts?

   --dkg

---

From: Ben Laurie <[email-masked]>
Date: Thu, 5 May 2016 14:04:09 +0100

On 4 May 2016 at 23:12, Daniel Kahn Gillmor <[email-masked]> wrote:
> x.509 chain.

Likely? Isn't it certain (if the EE cert validates, that is)?

>  But in other cases (e.g. auditing, gossiping), there's no

That seems like a good idea. Presumably we'd need to add a new
TransItem type to carry this information.

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rob Stradling <[email-masked]>
Date: Thu, 5 May 2016 14:17:53 +0100

On 05/05/16 14:04, Ben Laurie wrote:
> On 4 May 2016 at 23:12, Daniel Kahn Gillmor wrote:
<snip>
> TransItem type to carry this information.

Makes sense.  I think this should go into the gossip document rather 
than 6962-bis.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 May 2016 14:04:55 -0400

> Likely? Isn't it certain (if the EE cert validates, that is)?

well, there are always cases like:

 * web browser not configured with certificate chain (aka transvalid
   certs), and
   
 * user has clicked "accept" on the scary warning page for the cert in
   question

I'd argue that even in that case, CT is still useful -- for example, a
browser could consider make the clickthrough less
scary/cumbersome/difficult if it had a valid SCT.  But it won't be able
to validate the SCT, so that's not an option.

> TransItem type to carry this information.

Is there a transaction in CT itself where you expect that to happen?
Can you propose a change to the draft that would make that clear?

Is the clumsiness of needing the issuer key in addition to the cert and
SCT in order to validate the SCT worth the 32 octets in size it shaves
off?

    --dkg

---

From: Eran Messeri <[email-masked]>
Date: Fri, 6 May 2016 12:26:35 +0100

> to validate the SCT, so that's not an option.
The SCT was obtained in the first place by submission of a cert and a chain
to validate it. Can you further expand on the situations you see where a
cert would be provided but not  the chain? (I couldn't find anything about
transvalid certs)

> SCT in order to validate the SCT worth the 32 octets in size it shaves
The reason (I recall) for requiring the issuer key hash and TBSCertificate
was to unify handling of precerts and X.509 certs, such that the SCT
signature is over the same data structure for both cases.
The concern you raise is very valid - the issuer cert would always have to
accompany the leaf cert for clients/auditors to be able to verify the SCT's
signature (note that get-entries returns, in addition to the log entry and
the chain, the SCT issued).
I agree we should make sure the protocol takes it into account - just not
sure what type of clients will have a problem (TLS clients should get  a
full chain, auditors get everything from the log).

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 12 May 2016 15:00:47 +0200

Eran Messeri <[email-masked]> wrote
Fri, 6 May 2016 12:26:35 +0100:

| > >>  But in other cases (e.g. auditing, gossiping), there's no
| > >> guarantee that the issuer cert (or issuer public key) is going to be
| > >> passed alongside the SCT.
| > >>
| > >> Do we want to require people to pass the issuer cert (or issuer public
| > >> key?) alongside the cert in order to be able to verify the signature on
| > >> an SCT?  If so, where is the best place to document that concern?
| > >
| > > That seems like a good idea. Presumably we'd need to add a new
| > > TransItem type to carry this information.
| >
| > Is there a transaction in CT itself where you expect that to happen?
| > Can you propose a change to the draft that would make that clear?
| >
| > Is the clumsiness of needing the issuer key in addition to the cert and
| > SCT in order to validate the SCT worth the 32 octets in size it shaves
| > off?
| >
| The reason (I recall) for requiring the issuer key hash and TBSCertificate
| was to unify handling of precerts and X.509 certs, such that the SCT
| signature is over the same data structure for both cases.
| The concern you raise is very valid - the issuer cert would always have to
| accompany the leaf cert for clients/auditors to be able to verify the SCT's
| signature (note that get-entries returns, in addition to the log entry and
| the chain, the SCT issued).
| I agree we should make sure the protocol takes it into account - just not
| sure what type of clients will have a problem (TLS clients should get  a
| full chain, auditors get everything from the log).

The current incarnation of the CT gossip draft defines two modes of
operations for HTTPS servers when taking part in SCT Feedback
(draft-ietf-trans-gossip-02 section 8.1.3). In "simple mode" the HTTPS
server doesn't have a set of trusted roots and won't deal with anything
in the cert chain except the end-entity cert.

The argument for this is that it requires less configuration which
should increase the likelyhood of adoption.

An argument against this, beside the issue brought up by dkg in this
thread, is that "simple mode" won't protect against the
double-CA-compromise attack.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 13 May 2016 15:56:44 +0100

> function in the absence of the full chain.

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.

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 18 May 2016 18:23:13 +0200

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.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 May 2016 18:30:37 +0100

> 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?

It seems to me that the log could easily save SCTs it issued alongside
the cert chains it issued them for.

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...

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 19 May 2016 16:56:55 +0200

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.

---

From: Eran Messeri <[email-masked]>
Date: 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

---

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

> at least in our design. I'm sure it could be solved at the price of more

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.

> a big difference between doing this and indexing on SCT's though.

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