"If the client receives a response with a non-OK response_status, or a
log_status that does not contain the SCT's log, or a hash_suffix field
containing the SCT, the client should not report the SCT."
If it's a non-OK status, why not retry the request later? (The other
two scenarios make sense.) But an error condition could indicate an
attacker attempting to temporarily DOS Google go submissions from the
target fails, no?
"In consultation with cryptographers far smarter than this author, we
have determined that we only need a total hash length of 12 bytes to
ensure that the risk of hash collisions is below 2^32."
This works in a random world, but we aren't in a random world, I don't
think. The goal of this is to detect a SCT (via the hash of the SCT)
that the attacker does not want us to detect. The SCT contains a
signature by an ECDSA key; which is computed using an unknown k. An
attacker can therefore generate SCTs until they get an SCT whose hash
collides with another SCT. The collision rate should make that
generation process sufficiently hard, not guard against the chances of
a random collision.
> You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S69sjKgfsgHED9o908e2xgcJb7NH-GchvpNo49n%3DVmuLw%40mail.gmail.com