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

[Ryan Sleevi]

On Dec 18, 2013 11:14 AM, "Rick Andrews" <Rick_Andrews at symantec.com> wrote:
>
> Moving back to the public list, with Eddy’s permission.
>
>
>
> I agree with Eddy that pinning appears to be a very effective and
low-cost solution.

Pinning is not a low-cost system, nor is it at all a solution to all the
problems that CT addresses.

> My impression is that many of the past mis-issuances were detected by
Chrome’s pinning support. Is that accurate?
>

While it is well known that some incidences (such as Diginotar) were caught
by pinning, they only were effective through users recognizing something is
amiss and contacting Google.

I have trouble imagining a world in which the operational costs of millions
of server operators and the diligence and training of billions of users to
report to "someone" when they "see something," all for a solution that is
only a fraction as capable of CT, would somehow be either desirable or
low-cost.

Let me reiterate that pinning and CT seek to address different problem
spaces, with a different set of trade-offs. Suggesting pinning as an
alternative to CT is, on a very real and technical level, akin to
suggesting we do away with WebTrust/ETSI audits entirely, and let pinning
suffice. CT is complimentary to the existing auditing frameworks AND has
the benefit of providing detection capabilities where there are none.

To further belabor the beating of the straw man, why bother with the BRs at
all, and not just let browsers enforce technical requirements on the client
side? After all, the UA will reject such certs, so no harm, no foul?

CT is about improving trust and auditability in a system that operates
opaquely and has repeatedly failed to adhere to its own standards.

The minimal adoption of pinning, compared to the ever increasing academic
research into the CA ecosystem, coupled with the repeated failures of many
CAs to adhere to their stated CP/CPSes, should hopefully clearly show that
the set of problems are not equivalent.

>
>
> -Rick
>
>
>
> From: management-bounces at cabforum.org [mailto:
management-bounces at cabforum.org] On Behalf Of Eddy Nigg (StartCom Ltd.)
> Sent: Wednesday, December 18, 2013 9:56 AM
>
> To: 'management at cabforum.org'
> Subject: Re: [cabfman] Improving the security of EV Certificates
>
>
>
>
> On 12/18/2013 07:28 PM, From Jeremy Rowley:
>
> Pinning is more risky for unsophisticated users who could brick their
systems.
>
>
> I don't think so....such users would never use it, the same way such
users would never investigate a log or list of certificates.
>
>
> Plus, pinning becomes a market divider so I’d worry about anti-trust
violations if the recommendation came from the CAB Forum.
>
>
> How come, can you explain?
>
>
> Transparency, in my view, is better because it requires a change only by
the CAs and browsers, not by the users.  The information is then available
for any researcher to digest and evaluate, not just the end user.
>
>
> It's mostly the competing CAs!!!, software vendors, Netcraft and friends,
and some researchers that care about it (EFF, Qualsys and some others).
It's the same crowd that would use pinning too.
>
>
> A headache is when another DigiNotar is compromised , issues a couple
thousand certificates fraudulently, and covers it up for several months.
>
>
> Truly a problem, but may be attacked from a different angel (how about
different approach  to auditing?). I mean, we are doing our utmost to
comply to all the various requirements and much more than that - a price we
are willing  to pay because for this we are here. Now this proposal has a
significant price tag for something that hasn't been tested and used over
time with the "only" goal to detect the next DigiNotar.
>
> IMO pinning can achieve the same way cheaper (for me). And again, if we
could combine revocation for example, the benefit would be much bigger and
trade off the expenses/efforts...
>
> Regards
>
>
>
> Signer:
>
> Eddy Nigg, COO/CTO
>
>
>
> StartCom Ltd.
>
> XMPP:
>
> startcom at startcom.org
>
> Blog:
>
> Join the Revolution!
>
> Twitter:
>
> Follow Me
>
>
>
>
>
>
> _______________________________________________
> Management mailing list
> Management at cabforum.org
> https://cabforum.org/mailman/listinfo/management
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131218/05a7124e/attachment-0003.html>