Re: [Trans] Mutability of Certificate Signatures

[Andrew Ayer <[e-mail]>]

On Tue, 18 Jul 2017 17:57:33 +0100
Eran Messeri <[e-mail]> 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