Re: [Trans] path validation

[Stephen Kent <[e-mail]>]

David,
> On Thu, Oct 2, 2014 at 12:13 PM, Stephen Kent<[e-mail]>  wrote:
>>> On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent<[e-mail]>   wrote:
>>> You are missing the point of certificate transparency.
>> I may, since the definition of the goals seem to change over time.
> That, in a nutshell, is exactly the point of certificate transparency.
An inability to clearly characterize goals is a bug, not a feature :-) when
developing a standard. I cannot recall any major security area WGs that
have ignored this issue in the past few years.
> CT should provide a log service in a way that is neutral with respect
> to whatever requirements CABF or browser vendors may in future impose.
>
> This is good for good CAs: It means that they will have the
> flexibility to provide new services / cert types as soon as clients
> will accept them. They won't have to, in addition, go through this
> WG.[*]
My revised proposal from yesterday allows a CA to assert that
the cert being submitted does not purport to conform to the CABF DV/EV
guidelines, so it seems to address this concern.
> [*] Requiring CAs/browser vendors to get this WG's blessing seems to
> be the motivation of many of the proposals.
Can you be more specific?
>> I was suggesting that there might be benefits to checking at the time
>> of issuance, principally in the case of pre-certs.
> These proposals amount to this:
>
> Let's spare a CA who lets their private key be used to sign something
> it shouldn't have signed any reputational damage by requiring logs to
> not report it. This is exactly the wrong incentive. CAs -- both root
> and intermediate -- need to have security controls that ensure that
> they don't sign malicious things.
I agree with the sentiment that CAs should be held responsible.
I have no idea why you believe that I suggested otherwise. Please
cite any messages I have generated that support the first sentence above.
>> What CT does should or should not be ought to be justified based on an
>> analysis of attacks and what CT does to address them, not on blanket
>> statements that mis-issuance cannot be defined.
> [and other Stephen]: > That's . . . better that a mere assertion that
> "logging is good."
>
> The IETF has previously standardized logging protocols. See, inter
> alia, RFC 5424. Is consensus lacking for the idea that logging is
> good?
5424 didn't invent syslog. It provided a common format for communicating 
syslog
entries and a standard means for transport. It did not require any 
system to make
use of the protocol, to export syslog entries to arbitrary third 
parties, etc.
Thus, syslog is not a reasonable analogy to CT.

Steve