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

Thu Dec 19 09:20:12 UTC 2013

On 12/19/2013 02:27 AM, From Ryan Sleevi:
>
> It has been repeatedly explained to you, by multiple parties, that it 
> is not the end users (that is, to use CA terms, "Relying Parties"), 
> but instead the site operators, who will be monitoring the CT log.

I don't think it really matters who and how is monitoring this log, if 
at all.

>
>> 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.
>
>
> So protection for nobody. Got it.

I thought CT is about detection and not primarily protection? Detection 
also provides retroactive protection obviously, there might be other 
ways (better, worse) to achieving the same or similar.

> Eddy, I have tremendous respect for you and your efforts, but I feel 
> at this time, we've reached an impasse at being able to fruitfully and 
> productively discuss CT, its merits, and its risks.

Probably - at this point we can simply agree that we disagree.

> As has been previously discussed ( 
> https://cabforum.org/pipermail/public/2013-September/002233.html ), 
> Google Chrome intends to require Certificate Transparency for all EV 
> certificates issued after a future date. This is, as has been 
> previously stated, an additional requirement that Google Chrome is 
> imposing on certificates that it grants the EV badge to - in addition 
> to, not in replacement of, the existing auditing requirements 
> according to the CA/Browser Forum's EV Certificate Guidelines, and as 
> documented at 
> http://www.chromium.org/Home/chromium-security/root-ca-policy

I took note about your intentions, funnily that EV is your primary 
target which I believe needs it the least.

Now, regarding your intentions I believe it needs two to tango - we  
will make our calculations and will make a decision if we can support it 
or not. _If compliance would mean a significant change to the current 
business model of StartCom and the way we issue certificates, we will 
most likely not support it_. **

It could be that other CAs for this or other reasons (maybe privacy, 
existing NDAs etc.) will not be able to support it either, than you 
might be in a difficult situation too...

** Please note that less than half a year ago we had to make 
considerable efforts to support a complete change of our OCSP 
infrastructure, which involved some difficulties and still does for us. 
Unfortunately the only browser that really does something with that 
information (Firefox), is the one that suffered the most because of it. 
We are willing to make another effort shortly if Firefox doesn't support 
OCSP GET requests very soon in order to improve the situation.

Other requirements, changes and regulations are coming forth every here 
and now by the software vendors (and not through the CAB forum 
guidelines necessarily where CAs also have a say) affecting operation, 
implementations and business models, whereas I'm not sure if and when 
some real actions are warranted by the software vendors it always 
happens the way I'd like to see it. Other times the same browser vendors 
bent over themselves (and some CAs) for far less significant changes and 
far bigger failures (excuse my rambling)...

In short, this might be a deal-breaker for us which we will consider 
carefully at the appropriate time. And now I will shut up in order not 
to annoy the audience any further! :-)

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/eafe181a/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/eafe181a/attachment-0001.p7s>