[cabfpub] [cabfman] Improving the security of EV Certificates

Ryan Sleevi sleevi at google.com
Wed Dec 18 21:32:54 UTC 2013

On Wed, Dec 18, 2013 at 1:23 PM, Eddy Nigg (StartCom Ltd.) <
eddy_nigg at startcom.org> wrote:

> On 12/18/2013 10:14 PM, From Ryan Sleevi:
>  > How did you arrive at that sum? Pinning shouldn't really cost anything
> once the code is in the browsers. I also assume that code changes for CT
> wouldn't be any cheaper than that.
> Pinning is NOT just a nob you turn. It carries huge operational risks to
> realize the preventative guarantees
> Are we talking about the same thing here?


If you haven't followed the IETF discussions about pinning, I absolutely
encourage you to do so. The pinning draft itself is careful to spell out
that there are non-trivial risks aplenty with pinning, BUT it can provide
*preventative* mitigation.

As Brad states, pinning (and counter-solutions like TACK) introduce a whole
new key lifetime / management cycle that many organizations are barely
capable of meeting with SSL. However, unlike expired certs and lost keys,
there is no CA to call up in the middle of the night to get them to rush a
cert out for you - you've bricked your customers for as long as you
committed your pins to.

That sort of "footgun" behaviour is NOT desired by all sites, many of whom
would be happy to make a trade-off for detection rather than prevention.

Again, pinning (and solutions like pinning, such as TACK) are solving a
very different problem set than CT attempts to solve. They just *happen* to
overlap in one part of the problem space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131218/9c2a7ace/attachment-0003.html>

More information about the Public mailing list