Re: [Trans] Mutability of Certificate Signatures

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 <agwa@andrewayer.name> wrote:

> 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
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>