[cabfpub] [therightkey] Updated Certificate Transparency + Extended Validation plan

Tue Feb 4 20:06:22 UTC 2014

Comments in line:

Moving therightkey at ietf.org to bcc to avoid cross-posting.

I wanted to correct a misunderstanding that I've seen repeated several times within the CA/Browser Forum, and which I've tried to correct repeatedly.

No, the entire point is NOT to disclose the entire universe of public certificates to the customer. The entire point is to disclose the entire universe of public certificates __to the public__.

[JR] This is part of the point since it’s one of the primary reasons we’ve supported CT since the beginning.

That is, if no *customer* ever uses CT to monitor logs (an improbable and extremely unlike situation, as demonstrated by the IETF WG chartering), we will STILL see CT as a benefit to the public and as a success.

[JR] I will see it as a benefit, but a lesser benefit than the monitoring advantage.

This is because CT provides capabilities to allow ALL relying parties to audit public CAs. This capability extends to allowing root store operators to audit compliance to their programs. This capability extends to those who ingest root programs to examine the authorities trusted by these root programs. This allows independent third parties to monitor compliance to stated policies and practices.

[JR] If this were true, Google would be applying CT to all certificate types (or at least DV certificates). EV certificates have not traditionally been mis-issued.  Thus, the public gains nothing from added EV monitoring capabilities.

The current practice sees a random audit at a point in time conducted by an auditor (ETSI or WebTrust), often with a quite small percentage (3%, at most, IIRC), with the results of those audits not disclosed to any entity beyond the CA. Even if every browser program required full disclosure to the browser, this would fail to meet the goals.

[JR] Nitpick - The requirements are higher than this for EV. We are excited about this aspect, but the primary benefit we recognize is the advantage it gives domain owners in detected fraudulent issuance.  

I want to make sure it's clear the _why_ we're requiring CT, and where the value is derived from, as suggesting the *entire* point is just for the customer misses out the significant improvements to the ecosystem.

[JR] True. I should not have said “entire” since that was clearly inaccurate. I agree there are many additional (and significant) secondary benefits.

It's already clear that root store operators care about these things - as seen by Google's indexing or Microsoft's SmartScreen reporting ( http://realworldcrypto.files.wordpress.com/2013/06/shumow.pdf ). These are NOT sufficient technologies, as has been previously suggested, but they do demonstrate the increasing concern of root stores - and the interested parties such as EFF and the Certificate Observatory.

[JR] I recognize that, but, from a CA perspective, the main advantage is to our customers. By making the system unusable to our customers (by requiring CT only for EV and requiring 3-4 proofs), you’ve undermined the primary reason behind CA support.

CT addresses many of these holes, but only when it's required. We're happy to add CT to the list of requirements that CAs that wish to participate in our root stores and EV programs because of this, and we hope that other root store operators will follow.

[JR] Yep – this is why we support a global requirement for CT.  For EV with 3-4 proofs per certificate, the appeal to customers diminishes.

Jeremy 

-----Original Message-----
From: therightkey [mailto:therightkey-bounces at ietf.org] On Behalf Of Adam
Langley
Sent: Tuesday, February 04, 2014 10:52 AM
To: certificate-transparency at googlegroups.com
Cc: therightkey at ietf.org; Ben Laurie; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency +
Extended Validation plan

On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:
> Three or four proofs for a 27 month certificate is way too many.  The
number of proofs should be decided based on the customer's risk profile, not
a set number based on certificate lifecycle. Adding 400 bytes per
certificate will make EV certificates unusable by entities concerned with
performance.

The customer doesn't carry the risk: the risk is that we'll be unable to
revoke a log in clients due to the number of certificates that depend on it.

We should make the SCTs as small as possible, the the switch to larger
initcwnds in recent years has released much of the pressure on keeping
certificate sizes below the tradition initcwnd limit.

Cheers

AGL
_______________________________________________

therightkey mailing list
therightkey at ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140204/8b860a1e/attachment-0003.html>