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