On Tue, March 24, 2015 3:11 pm, Daniel Micay wrote:
> That's not a zero tolerance policy. It's an example of compromise where
> in exchange for more lenience, the CAs have to do something. You have to
> demonstrate that they have something to gain by showing that the
> policies have teeth though.
Daniel,
It's difficult to have a discussion with you when you mount attacks ("This
happened because of your negligence" / "Can you please stop pretending
that the people involved in PKI are responsible") and then change the
goalposts and definition arbitrarily and capriciously ("That's not a zero
tolerance policy", when Kai's proposal is just that)
I can understand you're excited to discuss this topic, but it would be
helpful to be more productive in the commentary, and recognize the
messages being replied to.
As it stands, Kai's proposal is problematic, for the reasons I've
addressed. There is still a service disruption for every CA, it's just a
service disruption you view as acceptable because "They should have used
CT". That doesn't make it not a service disruption, and it doesn't make it
not zero-tolerance.
Regardless of your feelings towards this particular incident, I think we
can agree that a world where every domain holder could, in event of a CA
compromise, validate that the compromised CA had not misissued
certificates by examining the public logs, of which all certificates were
required to be logged, is a good world. A world in which we can say "All
currently disclosed certificates are and remain trusted; no new
certificates are trusted" is also a world in which we can make more
informed decisions regarding misissuance. Those are worlds we want to go
to.
But they're neither the end-state nor are they wholly sufficient. And
while it's good to keep those potentialities in mind, it's also good to
recognize there are some worlds that we wouldn't want. I don't think we'd
want a world in which Let's Encrypt could not exist, or which would be
functionally delayed for 10 years. That benefits no one. This proposal
would require that - and even more, greater disruption for any CA that
disagreed and tried to help make Let's Encrypt a reality.
These are things we can discuss. Personal attacks? Those would best be
left for another forum.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
