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

[Ryan Sleevi]

On Tue, Feb 4, 2014 at 11:00 AM, Jeremy Rowley
<jeremy.rowley at digicert.com>wrote:

> The entire point is to disclose the entire universe of public certificates
> to the customer.  If the customer doesn't want to use it, the purpose is no
> longer being fulfilled. The way we plan on implementing CT will ensure logs
> are not irrevocable.  I agree we should make SCTs as small as possible, but
> the last I've heard from our team is  they are still at 100 bytes per log.
>
> Jeremy
>

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__.

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.

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.

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.

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.

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.

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.


>
> -----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/0525d93f/attachment-0003.html>