Re: [Trans] path validation

[David Leon Gil <[e-mail]>]

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.

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.[*]

[*] Requiring CAs/browser vendors to get this WG's blessing seems to
be the motivation of many of the proposals.

> 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.

> 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?