Re: [Trans] path validation

[Stephen Kent <[e-mail]>]

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