Rob,
On 01/10/14 15:34, Stephen Kent wrote:
<snip>
I thought the CT design makes a counter argument, i.e., that CAs are
motivated to log certs because, over time, TLS clients will reject
connections to servers when there is no evidence of an SCT.
Over time, yes, we hope that this will happen. But we obviously can't
guarantee that, in N months/years from now, 100% of TLS clients will
support CT.
I agree, which is why I suggested that text to the contrary be modified
in 6962-bis.
if this argument is true, then having logs check for syntactic
mis-issuance is a good thing.
I disagree. There is a gap between what is syntactically properly
issued (according to CABF guidelines, etc) and what a typical TLS
client actually accepts.
is that a good thing?
If logs checked for syntactic mis-issuance, a rogue CA could exploit
this gap by maliciously mis-issuing certs containing "syntax errors".
CT would not reveal the attack (because the logs would refuse to issue
SCTs), but TLS clients that don't reject connections when no SCT is
provided would be vulnerable.
See my attack analysis, which notes this as part of the larger set of
what CT can and cannot
detect.
We want to provide as much "herd immunity" as possible to TLS clients
that don't support CT. This means that we need all certs to be
publicly logged, to maximize the chances that any (maliciously)
mis-issued cert will be discovered quickly.
That's a clear statement about wanting to protect clients who don't
implement CT, i.e.,
don't mandate the presence of an SCT. That's a reasonable argument,
better that a mere
assertion that "logging is good." It belongs in 6962-bis. See my revised
proposal on syntax
checking, which addresses this.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans