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

Eddy Nigg (StartCom Ltd.) eddy_nigg at startcom.org
Thu Dec 19 00:08:44 UTC 2013


On 12/19/2013 01:29 AM, From Ryan Sleevi:
>
> On Wed, Dec 18, 2013 at 3:23 PM, Eddy Nigg (StartCom Ltd.) 
> <eddy_nigg at startcom.org <mailto:eddy_nigg at startcom.org>> wrote:
>
>     But this is exactly how Diginotar was detected however - basically
>     a few emails back I suggested that browser vendors nail the most
>     important sites in their browser as "pins" and allow users to pin
>     additional certificates to the respective sites. It's a very
>     simple and efficient way to get some protection and allows
>     detection for the most important sites.
>
>
> So your idea is that every end-user is capable of evaluating the 
> security policy of the site, without input of the site operator?

No, as not every user is capable or has the necessary 
interest/knowledge/integrity to monitor and review a log containing all 
issued certificates and to know what to do with this data. And I made 
the other arguments already at the managements list I think.

> And who do these users yell at when pins break?

There is most likely a reason if that happens, this way or the other. A 
knowledgeable users will know the difference and the others will not pin 
any certificates to start with.

> The suggesting that pinning is between user+browser, rather than 
> site+browser, is certainly a far worse model, utterly incomprehensible 
> and providing no value to end users.

I certainly works for me - it even worked for Google as far as I understood.

> Also, the idea that we should somehow balkanize the Internet, and only 
> the "very important ones" get security, at the discretion of browsers, 
> is a terrible one.

It's where the attacks probably happen first with the most value.

> CT provides protection for every single user and site operator on the 
> Internet - surely you can agree that has value?

That's a very worthy goal and I believe the vast majority get reasonable 
protection in any case already today. Otherwise we can stop using SSL if 
there is no value in the work CAs perform. Or change the rules, but 
don't basically double the work with another layer.

> Regardless of the views of pinning, however, the continued failures of 
> the WebTrust and ETSI audit schemes to "prevent" mis-issuance has 
> demonstrated to root store operators that it is no longer acceptable 
> for continued trust in CA operations.

Well, that's a very bleak interpretation - of course there were a bunch 
of failures (making me real angry too), but nothing is 100% ever. Not 
even CT will that be, trust me.

> By requiring audits be transparent - which CT does - it provides a 
> much better trust signal to root stores and their users that the 
> participating CAs are deserving of trust.

I have no problem with some transparency - I'd be willing to hand over a 
list of all issued certificates to an agreed upon consortium (how about 
Google, Netcraft, EFF and Qualsys) for review if that would increase 
your trust of my work. However I'm not really interested to carry the 
costs your proposal implies (at least as far as I see it, with no real 
numbers yet) and our subscribers will be probably very upset because 
they'll have to pay for it in the end.

> A simple audit letter from an AICPA accountant or a qualified auditor 
> is no longer sufficient, as the continued events demonstrate.

Can we skip auditing then if there is no value in that? Than everybody 
can become a CA as long as the certs are in the CT log?


Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131219/2d154aef/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131219/2d154aef/attachment-0001.p7s>


More information about the Public mailing list