Subject: Re: [Trans] Mutability of Certificate Signatures

From: Andrew Ayer <[email-masked]>
Date: Mon, 3 Jul 2017 10:02:41 -0700

To get the ball rolling again on fixing this issue, I've submitted a PR
which:

1. Changes issuer_key_hash to issuer_key.

2. Adds language to the Monitor section describing what checks a
monitor should do to detect signature mutation.

https://github.com/google/certificate-transparency-rfcs/pull/270

Regards,
Andrew

---

From: Eran Messeri <[email-masked]>
Date: Tue, 18 Jul 2017 17:57:33 +0100

Going back to the original email, I support the proposal to fix the issue
by adding language to the document saying that a failure to produce a full,
valid chain with the (immediate) issuer's key hash identical to the key
hash covered by the SCT signature.

I do not think the full key should be present in the SCT - even though it
would be convenient for monitors, the full chain *is* present in the
get-entries response, and requiring that the chain returned includes the
intermediate with the same key whose hash is covered by the SCT signature
is enough to guarantee monitors have the key.

While a CT log can present different, valid chains, leading to different
trust anchors, for a particular entry (as long as the same key was used for
signing the submission) - but that is true when certificates are used in
TLS connections, and in the context of CT this is more of a spam/log
credibility problem than a security problem: The log could present chains
that seem "uninteresting" to the general public (because they terminate in
a trust anchor unrecognized by any major UA) while, in fact, there is a
valid path from the submitted entry to a trust anchor recognized by UAs.

This could be detected by identifying which intermediates have the key that
was used to sign the submission. Regardless, this is not an attack on the
protocol or log implementation - but an ecosystem issue: Logs that accept a
mix of credible and unvetted trust anchors could always be spammed, and so
may not have the same utility as logs that accept TAs.
Signing the entire chain in the submission won't be useful to TLS clients
(because TLS certificates can be served with different, valid chains), so I
think that from a correctness perspective 6962-bis should just require the
log to serve a valid chain for each entry (which monitors can verify), and
if it can't, then it misbehaved.

Would that resolve the concern? IMHO such an addition to 6962-bis would not
require restarting WGLC as this is already implied by the protocol.

Eran

On Mon, Jul 3, 2017 at 6:02 PM, Andrew Ayer <[email-masked]> wrote:

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

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 18 Jul 2017 20:42:56 -0700

On Tue, 18 Jul 2017 17:57:33 +0100
Eran Messeri <[email-masked]> wrote:

> Going back to the original email, I support the proposal to fix the
> issue by adding language to the document saying that a failure to
> produce a full, valid chain with the (immediate) issuer's key hash
> identical to the key hash covered by the SCT signature.
> 
> I do not think the full key should be present in the SCT - even
> though it would be convenient for monitors, the full chain *is*
> present in the get-entries response, and requiring that the chain
> returned includes the intermediate with the same key whose hash is
> covered by the SCT signature is enough to guarantee monitors have the
> key.

I'm not proposing storing the key in the SCT, but in the
TimestampedCertificateEntryDataV2 structure (i.e. the Merkle leaf
input). Logs would have to store some extra data (though in most cases
they could dedupe it with the chain), but there would be no increase in
the size of SCTs.

To be clear, are you proposing a requirement that the chain always
contain a certificate with the issuer's public key, even if the logged
certificate is a trust anchor?  This would be a new requirement, as
6962-bis currently allows a non-self-signed trust anchor to be logged
without a chain containing its issuer.

Such a requirement would fix the problem, but it seems rather awkward
(chains wouldn't always end with a trust anchor) and it's such an edge
case that I fear logs might get it wrong (and if that happens, the log can
no longer be trusted).  I think converting issuer_key_hash to issuer_key
is a more conservative change, but I won't object to your approach if it's
what you prefer.  The wording would need to be extremely clear so there
is no doubt that a log needs to make the issuer available in this case.

> While a CT log can present different, valid chains, leading to
> different trust anchors, for a particular entry (as long as the same
> key was used for signing the submission) - but that is true when
> certificates are used in TLS connections, and in the context of CT
> this is more of a spam/log credibility problem than a security
> problem: The log could present chains that seem "uninteresting" to
> the general public (because they terminate in a trust anchor
> unrecognized by any major UA) while, in fact, there is a valid path
> from the submitted entry to a trust anchor recognized by UAs.
> 
> This could be detected by identifying which intermediates have the
> key that was used to sign the submission. Regardless, this is not an
> attack on the protocol or log implementation - but an ecosystem
> issue: Logs that accept a mix of credible and unvetted trust anchors
> could always be spammed, and so may not have the same utility as logs
> that accept TAs. Signing the entire chain in the submission won't be
> useful to TLS clients (because TLS certificates can be served with
> different, valid chains), so I think that from a correctness
> perspective 6962-bis should just require the log to serve a valid
> chain for each entry (which monitors can verify), and if it can't,
> then it misbehaved.

Presenting different, valid chains is a separate problem so I'm curious
what the relevance is?  I agree there's nothing 6962-bis needs to do
about the multiple chain problem.

Regards,
Andrew

---

From: Rob Stradling <[email-masked]>
Date: Wed, 19 Jul 2017 10:13:36 +0100

On 19/07/17 04:42, Andrew Ayer wrote:
<snip>
> without a chain containing its issuer.
How about we revert to the RFC6962 requirement that only self-signed 
certificates may be trust anchors?

It would still be possible for an "intermediate CA" to be a trust 
anchor, since there's nothing to stop an "intermediate CA" from also 
self-certifying itself.

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