David,
On Thu, Oct 2, 2014 at 12:13 PM, Stephen Kent<[email protected]> wrote:
On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent<[email protected]> 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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
