Subject: [therightkey] Updated Certificate Transparency + Extended Validation plan

From: Ben Laurie <[email-masked]>
Date: Tue, 4 Feb 2014 17:08:19 +0000

Enclosed, our revised plan.

Comments welcome.

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 10:33:32 -0700

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. 

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Laurie
Sent: Tuesday, February 04, 2014 10:08 AM
To: CABFPub; [email-masked]; [email-masked]
Subject: [cabfpub] Updated Certificate Transparency + Extended Validation plan

Comments welcome.

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Feb 2014 12:52:20 -0500

> 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. Addin…

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

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 10:08:25 -0800

One can also use OCSP Stapling or the TLS extension. OCSP stapling is
particularly useful for also dealing with the revocation status in a single
response.
On Feb 4, 2014 9:52 AM, "Adam Langley" <[email-masked]> 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.
>
> _______________________________________________
> Public mailing list
> [email-masked]
> https://cabforum.org/mailman/listinfo/public
>

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 12:00:05 -0700

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

-----Original Message-----
From: therightkey [mailto:[email-masked]] On Behalf Of Adam
Langley
Sent: Tuesday, February 04, 2014 10:52 AM
To: [email-masked]
Cc: [email-masked]; Ben Laurie; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency +
Extended Validation plan

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

Cheers

AGL
_______________________________________________
therightkey mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/therightkey

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Feb 2014 14:05:00 -0500

On Tue, Feb 4, 2014 at 1:58 PM, Doug Beattie
<[email-masked]> wrote:
> The number of proofs should be related to the reputation of the CA, the number
> of years the CA has been in business

I think you're assuming that a larger number of proofs is designed to
catch possible malpractice on the part of the CA, but that's not it at
all.

The aim is to make sure that bad /logs/ can be distrusted. The major
obstacle to killing logs is that certificates depend on the proofs and
that, if we killed all the logs that a certificate was depending on,
the site in question might go dark. In order to make sure that logs
can be distrusted without blowback, the number of proofs increases as
the duration of the certificate does. Thus, even if we kill one log
every 12 months (which we certainly hope not to do!), longer lived
certificates would still be functional towards the end of their lives.

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 12:06:04 -0700

Also, I'm not sure how basing the number of logs based on the lifecycle
actually minimizes the impact of log revocation. If a log containing a
couple thousand 1-year certificates is compromised, the damage from
revocation is about the same as a log containing thousands of 3-year certs.
Unless you plan is to revoke the log and wait for all impacted certificates
to actually expire (giving a 12 month risk), the impact depends on the
number of certificates valid at the time of revocation, not the expiration
date of the certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jeremy Rowley
Sent: Tuesday, February 04, 2014 12:00 PM
To: 'Adam Langley'; [email-masked]
Cc: [email-masked]; 'CABFPub'
Subject: Re: [cabfpub] [therightkey] Updated Certificate Transparency +
Extended Validation plan

Jeremy

-----Original Message-----

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 12:10:13 -0700

I do not think this is correct.  The number of proofs actually increases as you decrease validity periods. A 2-year certificate only lets the customer skip a year in the renewal process.  A 2-year certificate will lower the number of certificates logged by one (since the customer would need to log two 1-year certificates instead of one 2-year certificate). The number of domains requiring a certificate identifies the quantity of proofs, not the number of certificates actually issued.

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Tuesday, February 04, 2014 12:05 PM
To: certificate-transparency
Cc: Jeremy Rowley; Ben Laurie; CABFPub; therightkey
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended Validation plan

On Tue, Feb 4, 2014 at 1:58 PM, Doug Beattie <[email-masked]> wrote:
> The number of proofs should be related to the reputation of the CA, 
> the number of years the CA has been in business

I think you're assuming that a larger number of proofs is designed to catch possible malpractice on the part of the CA, but that's not it at all.

The aim is to make sure that bad /logs/ can be distrusted. The major obstacle to killing logs is that certificates depend on the proofs and that, if we killed all the logs that a certificate was depending on, the site in question might go dark. In order to make sure that logs can be distrusted without blowback, the number of proofs increases as the duration of the certificate does. Thus, even if we kill one log every 12 months (which we certainly hope not to do!), longer lived certificates would still be functional towards the end of their lives.

Cheers

AGL

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 11:21:46 -0800

> number of certificates valid at the time of revocation, not the expiration
The "impact" is only present if a single SCT is acceptable.

Increasing the number of SCTs decreases the impact of log revocation, as
the probability that any given certificate will be directly affected by a
single revocation (which is far, far less common one would hope) decreases
relative to the number of distinct logs it is logged in.

Further, a 1 year certificate that is renewed every year has a greater
chance to respond to any revocation events than a 3 year certificate, which
will not be re-issued for 3 years, and thus is unable to respond to any
revocation events (as unlikely as they may be) that happen in the interim.

> On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley <[email-masked]
> >
> wrote:
> not

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Feb 2014 14:41:42 -0500

On Tue, Feb 4, 2014 at 2:10 PM, Jeremy Rowley
<[email-masked]> wrote:
> I do not think this is correct.  The number of proofs actually increases as you decrease validity periods.

Consider a certificate setting out on a journey. It always needs to
have identity papers with it because the Browser Police are always on
the lookout for unregistered certificates. However, the Browser Police
sometimes decide that certain forms of ID are no longer acceptable and
so a certificate needs to carry several forms of ID with it. If it's
setting out on a one year journey it's wise to have two forms of ID
because one might become distrusted over the year, but it's
vanishingly unlikely that both would be.

However, if our plucky certificate is setting out on a two year
journey then it's wise to carry three forms of ID just in case two
become useless while it's out in the world. The longer it'll be out,
the more forms of id it should carry to ensure that one is always
acceptable.

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 13:10:41 -0700

That has little to do with distrusting a log.  That's an argument for
shorter-lived certificates in general.  

To continue your analogy: 

If the certificate sets out on a two year journey with a passport, it might
realize this is better than grabbing a utility bill and phone receipt.  Why
would it carry garbage when it already has something everyone accepts?

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Langley
Sent: Tuesday, February 04, 2014 12:42 PM
To: [email-masked]
Cc: therightkey; CABFPub
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended
Validation plan

> I do not think this is correct.  The number of proofs actually increases
as you decrease validity periods.

Consider a certificate setting out on a journey. It always needs to have
identity papers with it because the Browser Police are always on the lookout
for unregistered certificates. However, the Browser Police sometimes decide
that certain forms of ID are no longer acceptable and so a certificate needs
to carry several forms of ID with it. If it's setting out on a one year
journey it's wise to have two forms of ID because one might become
distrusted over the year, but it's vanishingly unlikely that both would be.

However, if our plucky certificate is setting out on a two year journey then
it's wise to carry three forms of ID just in case two become useless while
it's out in the world. The longer it'll be out, the more forms of id it
should carry to ensure that one is always acceptable.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Feb 2014 15:19:02 -0500

> would it carry garbage when it already has something everyone accepts?

We don't want to be in the position where we can't distrust a log
(*any log*) because it would render certificates invalid. Which is why
we're specifying that certificates carry multiple SCTs.

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 13:24:56 -0700

What's wrong with rendering certificates invalid?  Isn't the burden on the
CA to ensure their customers are satisfied?  If the CA wants to take the
risk, let them. We'll make sure our customers 100% understand the risks when
deciding how many proofs to embed.

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Langley
Sent: Tuesday, February 04, 2014 1:19 PM
To: Jeremy Rowley
Cc: therightkey; certificate-transparency; CABFPub
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended
Validation plan

On Tue, Feb 4, 2014 at 3:10 PM, Jeremy Rowley <[email-masked]>
wrote:
> If the certificate sets out on a two year journey with a passport, it 
> might realize this is better than grabbing a utility bill and phone 
> receipt.  Why would it carry garbage when it already has something
everyone accepts?

We don't want to be in the position where we can't distrust a log (*any
log*) because it would render certificates invalid. Which is why we're
specifying that certificates carry multiple SCTs.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Feb 2014 15:31:55 -0500

> deciding how many proofs to embed.

But the burden of an invalid certificate significantly falls on
users/browsers, not just on the site. If distrusting a log causes 1%
of the Internet to go dark, we essentially cannot do it. It's because
of these externalities that we're seeking these assurances.

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 13:37:44 -0700

Doesn't that simply require the cert user to either start using OCSP with an
embedded certificate or getting a new certificate from the user?  Plus,
under the current plan, the site doesn't go dark. Instead, their EV cert
isn't recognized as an EV certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Langley
Sent: Tuesday, February 04, 2014 1:32 PM
To: Jeremy Rowley
Cc: therightkey; certificate-transparency; CABFPub
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended
Validation plan

On Tue, Feb 4, 2014 at 3:24 PM, Jeremy Rowley <[email-masked]>
wrote:
> What's wrong with rendering certificates invalid?  Isn't the burden on 
> the CA to ensure their customers are satisfied?  If the CA wants to 
> take the risk, let them. We'll make sure our customers 100% understand 
> the risks when deciding how many proofs to embed.

But the burden of an invalid certificate significantly falls on
users/browsers, not just on the site. If distrusting a log causes 1% of the
Internet to go dark, we essentially cannot do it. It's because of these
externalities that we're seeking these assurances.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Feb 2014 15:50:33 -0500

On Tue, Feb 4, 2014 at 3:37 PM, Jeremy Rowley
<[email-masked]> wrote:
> embedded certificate or getting a new certificate from the user?

If the certificate was used with OCSP stapling, the CA had a
reasonably short OCSP validity window and the CA could update the SCT
in the OCSP response quickly then that would solve the problem.

However, for the purposes of this spec I don't think we said anything
about that because of the complexity. Having multiple SCTs is clearly
ok and that kept things simple.

> Plus, under the current plan, the site doesn't go dark. Instead, their EV cert isn't recognized as an EV certificate.

For EV certificates the problem is greatly reduced. But EV
certificates are just a trial for doing it universally and we have the
end state in mind.

Cheers

AGL

---

From: Ben Laurie <[email-masked]>
Date: Tue, 4 Feb 2014 20:54:13 +0000

> ok and that kept things simple.

Actually, we do. For the TLS extension and OCSP stapling a single SCT
is allowed.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 13:14:51 -0800

On Tue, Feb 4, 2014 at 12:50 PM, Adam Langley <[email-masked]> wrote:

> > Plus, under the current plan, the site doesn't go dark. Instead, their
> EV cert isn't recognized as an EV certificate.
>

Also, EV has the added benefit of recommending/requiring (depending on
which doc) fresh revocation checks. As such, CAs that feel that multiple
logs are too onerous can benefit from the OCSP delivery method. Failing to
obtain fresh revocation information can already cause a loss of EV UI, so
including an SCT should be a much less onerous cross to bear.

It also allows for issuance patterns other than pre-certs.

Of course, it means that any sites purchasing certificates from such a CA
support OCSP stapling.

---

From: Wayne Thayer <[email-masked]>
Date: Wed, 5 Feb 2014 01:47:04 +0000

I'm somewhat confused by the following two points:

>>5. By July 2014 all EV certificates with validity periods beyond [July
>>2014] should be logged in
at least [one] qualifying log (see below).
>>6. On 1 Jan 2015 Chrome will create a whitelist of valid EV certificates
>>already issued without
an embedded SCT [issued by CAs participating in CT] from all qualifying
logs.

If EV certificates issued prior to 1 Jan 2015 will be whitelisted, what is
the purpose of point #5?

Also, regarding point #7, I understand if it¹s not practical to distribute
a large whitelist to mobile platforms, but IMO retroactively removing the
EV indicator from existing certs rather than letting them naturally expire
before enforcing CT on mobile platforms creates a bad EV experience in
return for little additional transparency & security.

Thanks,

Wayne

-----Original Message-----
From: therightkey [mailto:[email-masked]] On Behalf Of Ben
Laurie
Sent: Tuesday, February 04, 2014 10:08 AM
To: CABFPub; [email-masked];
[email-masked]
Subject: [therightkey] Updated Certificate Transparency + Extended
Validation plan

Comments welcome.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 17:55:45 -0800

> return for little additional transparency & security.
Hi Wayne,

Considering we already do not indicate EV on Android, nor have we ever, I
don't think this perceived loss of functionality is as significant as you
may believe.

Further, considering the very real and distinct performance characteristics
of mobile (radio warmups, RTTs, initcwnds), the idea of fetching OCSP, or,
worse, CRLs - especially when some CAs have CRLs that are quite large (20+
MB) - in order to assure the EV display is... non-ideal. So again, the EV
indicator on mobile is not as strong or as present as it may be on desktop
platforms.

---

From: Wayne Thayer <[email-masked]>
Date: Wed, 5 Feb 2014 02:32:31 +0000

Hi Wayne,

Considering we already do not indicate EV on Android, nor have we ever, I don't think this perceived loss of functionality is as significant as you may believe.

Further, considering the very real and distinct performance characteristics of mobile (radio warmups, RTTs, initcwnds), the idea of fetching OCSP, or, worse, CRLs - especially when some CAs have CRLs that are quite large (20+ MB) - in order to assure the EV display is... non-ideal. So again, the EV indicator on mobile is not as strong or as present as it may be on desktop platforms.

In that case, what does this statement mean?

Chrome for mobile platforms will cease to show EV indicators for certificates that are not CT qualified according to the criteria below.

-----Original Message-----
From: therightkey [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ben
Laurie
Sent: Tuesday, February 04, 2014 10:08 AM
To: CABFPub; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Subject: [therightkey] Updated Certificate Transparency + Extended
Validation plan

Comments welcome.

_______________________________________________
Public mailing list
[email-masked]<mailto:[email-masked]>
https://cabforum.org/mailman/listinfo/public

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 4 Feb 2014 19:38:05 -0700

I'm confused as well.  Does that mean Android will start showing an EV
indicator?

From: therightkey [mailto:[email-masked]] On Behalf Of Wayne
Thayer
Sent: Tuesday, February 04, 2014 7:33 PM
To: Ryan Sleevi
Cc: [email-masked]; Ben Laurie;
[email-masked]; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency +
Extended Validation plan

Hi Wayne,

Chrome for mobile platforms will cease to show EV indicators for
certificates that are not CT qualified according to the criteria below.

-----Original Message-----

Comments welcome.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 18:48:40 -0800

On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <[email-masked]>wrote:

> I’m confused as well.  Does that mean Android will start showing an EV
> indicator?
>
>
>
> *From:* therightkey [mailto:[email-masked]] *On Behalf Of *Wayne
> Thayer
> *Sent:* Tuesday, February 04, 2014 7:33 PM
> *To:* Ryan Sleevi
> *Cc:* [email-masked]; Ben Laurie;
> *Subject:* Re: [therightkey] [cabfpub] Updated Certificate Transparency +
> Extended Validation plan
>
>
>
>
>
> Hi Wayne,
>
>
>
> Further, considering the very real and distinct performance
> characteristics of mobile (radio warmups, RTTs, initcwnds), the idea of
> fetching OCSP, or, worse, CRLs - especially when some CAs have CRLs that
> are quite large (20+ MB) - in order to assure the EV display is...
> non-ideal. So again, the EV indicator on mobile is not as strong or as
> present as it may be on desktop platforms.
>
>
>

It means that for any CAs that hope to be recognized as EV on Chrome for
mobile platforms (which include iOS), implementing CT by the dates outlined
is seen as a requirement for such treatment. We wanted to specifically call
attention to this - the whitelist is seen as a temporary measure for
Desktop, but given the unique characteristics of mobile platforms, we're
pursuing this requirement at a more aggressive pace.

While Chrome for Android - and the Chrome-based WebView, as the WebView
preceding it - do not provide special treatment for EV, any future plans
for EV indications on these platforms have incorporated the above
requirements and dates.

---

From: Wayne Thayer <[email-masked]>
Date: Wed, 5 Feb 2014 03:12:08 +0000

On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <[email-masked]<mailto:[email-masked]>> wrote:
I'm confused as well.  Does that mean Android will start showing an EV indicator?

From: therightkey [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Wayne Thayer
Sent: Tuesday, February 04, 2014 7:33 PM
To: Ryan Sleevi
Cc: [email-masked]<mailto:[email-masked]>; Ben Laurie; [email-masked]<mailto:[email-masked]>; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan

Hi Wayne,

It means that for any CAs that hope to be recognized as EV on Chrome for mobile platforms (which include iOS), implementing CT by the dates outlined is seen as a requirement for such treatment. We wanted to specifically call attention to this - the whitelist is seen as a temporary measure for Desktop, but given the unique characteristics of mobile platforms, we're pursuing this requirement at a more aggressive pace.

While Chrome for Android - and the Chrome-based WebView, as the WebView preceding it - do not provide special treatment for EV, any future plans for EV indications on these platforms have incorporated the above requirements and dates.

In that case, my original objection stands - this policy retroactively downgrades existing EV certificates if and when a mobile platform chooses to implement an EV indicator. There are certainly times when it's necessary to apply a new policy to existing certificates to protect relying parties, but IMO this isn't one of them.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 19:23:21 -0800

On Tue, Feb 4, 2014 at 7:12 PM, Wayne Thayer <[email-masked]> wrote:

>> *Subject:* Re: [therightkey] [cabfpub] Updated Certificate Transparency
>> + Extended Validation plan
>>
>>
>>
>>
>>
>>  Hi Wayne,
>>
>>
>>
>  In that case, my original objection stands – this policy retroactively
> downgrades existing EV certificates if and when a mobile platform chooses
> to implement an EV indicator. There are certainly times when it’s necessary
> to apply a new policy to existing certificates to protect relying parties,
> but IMO this isn’t one of them.
>

Wayne,

While I appreciate your position, I am absolutely baffled as how you can
present this as a "downgrade".

If and when Android supports EV, certificates that fail to meet this
requirements will continue to appear exactly the same as they do today and
they have in the past. Certificates which do conform to these program
requirements will, presumably, be granted distinguishing UI. To the
customer who purchased a certificate today, their certificate will continue
to appear in that future world exactly how it appears today, presumably -
providing them exactly what they expected.

I can only interpret your objection as an objection to root store programs
requiring additional requirements above and beyond that of the EV
Guidelines. I can only presume that you have similar objections to root
store programs requiring additional requirements above and beyond the
Baseline Requirements - as (to the best of my knowledge) - every root
program already does today.

Could you perhaps quantify exactly what you see as the downgrade, given
that such a hypothetical user experience (as again, EV is not presently
implemented in Chrome for Android) does not change?

---

From: Wayne Thayer <[email-masked]>
Date: Wed, 5 Feb 2014 04:31:12 +0000

On Tue, Feb 4, 2014 at 7:12 PM, Wayne Thayer <[email-masked]<mailto:[email-masked]>> wrote:

I’m confused as well.  Does that mean Android will start showing an EV indicator?

Hi Wayne,

In that case, my original objection stands – this policy retroactively downgrades existing EV certificates if and when a mobile platform chooses to implement an EV indicator. There are certainly times when it’s necessary to apply a new policy to existing certificates to protect relying parties, but IMO this isn’t one of them.

Wayne,

While I appreciate your position, I am absolutely baffled as how you can present this as a "downgrade".

If and when Android supports EV, certificates that fail to meet this requirements will continue to appear exactly the same as they do today and they have in the past. Certificates which do conform to these program requirements will, presumably, be granted distinguishing UI. To the customer who purchased a certificate today, their certificate will continue to appear in that future world exactly how it appears today, presumably - providing them exactly what they expected.

I can only interpret your objection as an objection to root store programs requiring additional requirements above and beyond that of the EV Guidelines. I can only presume that you have similar objections to root store programs requiring additional requirements above and beyond the Baseline Requirements - as (to the best of my knowledge) - every root program already does today.

Ryan,

I believe that I have repeatedly stated my support for Google’s overall plan to implement CT, so please don't blow this discussion out of proportion by interpreting it as me objecting to anything and everything a root store operator chooses to do unilaterally. On the other hand, more coordination amongst root store operators would be great!

Could you perhaps quantify exactly what you see as the downgrade, given that such a hypothetical user experience (as again, EV is not presently implemented in Chrome for Android) does not change?

My concern is one of timing. Rather than letting perfectly good EV certificates expire naturally or be grandfathered in, they are treated as non-EV certificates under this policy. When I use the terms ‘downgrade’ and ‘retroactive', I am specifically referring to a policy in which some EV certificates issued prior to the implementation of the policy (retroactive) are treated as non-EV (downgrade). I now understand that there is currently no change in how they are displayed in Chrome for Android, but (1) the policy and your comments imply that there will be, and (2) however hypothetical it may be, a precedent is being set here.

If this still doesn’t make sense, maybe we can discuss it at the CAB Forum meeting in a few weeks.

Also, can someone answer my question on point #5 in my original message?

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 20:39:40 -0800

On Tue, Feb 4, 2014 at 8:31 PM, Wayne Thayer <[email-masked]> wrote:

>> On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <[email-masked]
>> > wrote:
>>
>>> *From:* therightkey [mailto:[email-masked]] *On Behalf Of
>>> *Wayne Thayer
>>> Considering we already do not indicate EV on Android, nor have we ever,
>>> I don't think this perceived loss of functionality is as significant as you
>>> may believe.
>>>
>>  It means that for any CAs that hope to be recognized as EV on Chrome
>> for mobile platforms (which include iOS), implementing CT by the dates
>> outlined is seen as a requirement for such treatment. We wanted to
>> specifically call attention to this - the whitelist is seen as a temporary
>> measure for Desktop, but given the unique characteristics of mobile
>> platforms, we're pursuing this requirement at a more aggressive pace.
>>
>  I can only interpret your objection as an objection to root store
> programs requiring additional requirements above and beyond that of the EV
>  I believe that I have repeatedly stated my support for Google’s overall
> plan to implement CT, so please don't blow this discussion out of
> proportion by interpreting it as me objecting to anything and everything a
> root store operator chooses to do unilaterally. On the other hand, more
> coordination amongst root store operators would be great!
>
>
>  My concern is one of timing. Rather than letting perfectly good EV
> certificates expire naturally or be grandfathered in, they are treated as
> non-EV certificates under this policy. When I use the terms ‘downgrade’ and
> ‘retroactive', I am specifically referring to a policy in which some EV
> certificates issued prior to the implementation of the policy (retroactive)
> are treated as non-EV (downgrade). I now understand that there is currently
> no change in how they are displayed in Chrome for Android, but (1) the
> policy and your comments imply that there will be, and (2) however
> hypothetical it may be, a precedent is being set here.
>
>
I'm still not sure I follow the argument, so apologies for my ignorance. EV
treatment will only be granted to certificates that conform to these
policies. Are you imagining a scenario in which a certificate appears as EV
in Android (which again, is not a feature currently implemented), and then
later in the future, no longer does?

And I'm not sure what your view of the precedent is. Chrome has already
applied policies it believes are necessary to protect users - we no longer
treat internal host names as secure, for example, independent of the
Baseline Requirements 2015 sunset. Equally, we are aggressively proceeding
with ensuring that the security indicator is appropriate for certificates
that fail to meet minimum cryptographic requirements or validity dates.

A certificate which does not display as EV today, and which does not
display as EV tomorrow, does not particularly seem like a "downgrade"?

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Feb 2014 12:36:44 +0000

On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley wrote:
> Three or four proofs for a 27 month certificate is way too many.
<snip>
> Adding 400 bytes per certificate will make EV certificates unusable by entities concerned with performance.

The updated CT+EV plan requires three SCTs for a (maximum length) 
27-month EV certificate, not four.  400 bytes for three SCTs is about 
right though.

Assuming RFC6962-compliant v1 SCTs that contain no SCT extensions and 
are signed using ECDSA and a P-256 private key, then, including all of 
the ASN.1 fluff for the SCT List certificate extension, I calculate that 
it'll be...

140 or 141 bytes to embed 1 SCT

261 to 263 bytes to embed 2 SCTs

380 to 383 bytes to embed 3 SCTs

For (non-EV) validity periods between 27 and 39 months:
499 to 503 bytes to embed 4 SCTs

On 04/02/14 17:52, Adam Langley wrote:
<snip>
> We should make the SCTs as small as possible

Agreed.  Time for some back-of-an-envelope sums.  For SCT v2, if we were 
to pack in the data as tightly as possible I reckon we could cut it down 
to as little as...

84 bytes to embed 1 SCT

159 bytes to embed 2 SCTs

231 bytes to embed 3 SCTs

303 bytes to embed 4 SCTs

Here's how...

1. Use a shorter OID for the SCT List extension.  Perhaps CABForum could 
define 2.23.140.n (with n < 128).  Save 6 bytes.

2. The first 2 bytes of the SignedCertificateTimestampList structure are 
its total length.  Since this can be calculated from the OCTET STRING 
length, these 2 bytes could be omitted.  Save 2 bytes.

3. Pack the SCT fields into as few bytes as possible for the common 
case, whilst retaining options for future expansion.  Save 37 bytes per SCT.
Replace...
   (1 byte)    Version sct_version;
   (32 bytes)  LogID id;
   (8 bytes)   uint64 timestamp;
   (2+? bytes) CtExtensions extensions;
...with...
   (2 bits)    sct_version    (00=v1; 01=v2; 10,11=unassigned)
   (2 bits)    log_id_type    (00=SHA-256(log_public_key);
                               01=1-byte Registered Log ID;
                               10=2-byte Registered Log ID;
                               11=4-byte Registered Log ID)
   (2 bits)    timestamp_size (00=8-bytes;
                               01=6-bytes;
                               10=5-bytes;
                               11=4-bytes)
   (1 bit)     extensions     (0=CtExtensions is present;
                               1=CtExtensions is absent)
   (1 bit)     signature_type (0=digitally-signed struct;
                               1=raw Ed25519 signature)
   For the common case:
   (1 byte)    Registered Log ID
   (4 bytes)   Timestamp (seconds, not milliseconds)

4. Use the Ed25519 signature scheme instead of ECDSA.  ECDSA signatures 
using a P-256 key seem to be 72 or 73 bytes, whereas Ed25519 signatures 
are 64 bytes.  Save 8 or 9 bytes per SCT.
Also, for Ed25519, omit the 2 bytes containing the hash algorithm and 
signature algorithm from the "digitally-signed struct" header.  Save 2 
bytes per SCT.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ben Laurie <[email-masked]>
Date: Wed, 5 Feb 2014 12:44:36 +0000

> If EV certificates issued prior to 1 Jan 2015 will be whitelisted, what is

Sorry, this wasn't particularly clear. By "logged in a qualifying log"
we meant also that the certificate should include an appropriate
number of SCTs. The whitelist _may_ not include certificates issued
after July 2014.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Feb 2014 12:54:38 +0000

On 04/02/14 17:33, Jeremy Rowley wrote:
<snip>
> Adding 400 bytes per certificate will make EV certificates unusable by entities concerned with performance.

BTW Jeremy, in seeking to get some perspective on this issue, I notice 
that the current EV cert for www.digicert.com has a Certificate Policies 
User Notice that takes up 338 bytes!  (2 bytes per character, 'cos for 
some reason you use a BMPString).

"Any use of this Certificate constitutes acceptance of the DigiCert 
CP/CPS and the Relying Party Agreement which limit liability and are 
incorporated herein by reference"

Is it really necessary to include this notice in each cert?

Have any "entities concerned with performance" complained about it?

You could save 169 bytes immediately by simply switching from BMPString 
to UTF8String!  ;-)

---

From: "Mehner, Carl" <[email-masked]>
Date: Wed, 5 Feb 2014 14:40:44 +0000

Ryan,

Today EV certificates do display the EV green bar treatment in Chrome on iOS (albeit briefly) as well as a message about validating the organization and location when you click on the certificate (vs just the “website has been verified” that you get in Chrome on Android for EV and on any platform for non-EV certs)

Following the mobile stipulations in number 7 on your document, in the case of Chrome on iOS, this would be the downgrade that Wayne mentions. A certificate appears as EV in Chrome for iOS on 31 Jan 2015, and would not display as EV after 1 Feb 2015.

Carl Mehner

From: therightkey [mailto:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Tuesday, February 04, 2014 10:40 PM
To: Wayne Thayer
Cc: therightkey; Ben Laurie; certificate-transparency; Jeremy Rowley; CABFPub
Subject: EXTERNAL: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan

On Tue, Feb 4, 2014 at 8:31 PM, Wayne Thayer <[email-masked]<mailto:[email-masked]>> wrote:

         Hi Wayne,

   Wayne,

   Ryan,

   I'm still not sure I follow the argument, so apologies for my ignorance. EV treatment will only be granted to certificates that conform to these policies. Are you imagining a scenario in which a certificate appears as EV in Android (which again, is not a feature currently implemented), and then later in the future, no longer does?

   And I'm not sure what your view of the precedent is. Chrome has already applied policies it believes are necessary to protect users - we no longer treat internal host names as secure, for example, independent of the Baseline Requirements 2015 sunset. Equally, we are aggressively proceeding with ensuring that the security indicator is appropriate for certificates that fail to meet minimum cryptographic requirements or validity dates.

   A certificate which does not display as EV today, and which does not display as EV tomorrow, does not particularly seem like a "downgrade"?

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Feb 2014 15:26:45 +0000

> Enclosed, our revised plan.

Ben,

Table 1 and Footnote 4 seem a bit confused, wrongly implying that 
39-month EV certs do exist and/or that >39-month non-EV certs don't exist.

 >27 month EV SSL certificates shouldn't exist, as per the EV Guidelines.

 >60 month non-EV SSL certificates shouldn't have been issued by any CA 
since the BRs came into effect.

 >39 month non-EV SSL certificates shouldn't be issued from 1st April 
2015, as per the BRs.

Also, what happened to the idea of only requiring 1 SCT for a 1-month cert?

---

From: Adam Langley <[email-masked]>
Date: Wed, 5 Feb 2014 10:39:49 -0500

> Also, what happened to the idea of only requiring 1 SCT for a 1-month cert?

I'm to blame for that.

Certificates with a single SCT put a lower bound on how quickly we can
distrust a log (at least without special measures, such as shipping
the whole, public log hashes to all the clients, which is probably
impractical.) Since I'm not aware of any CAs issuing one month certs,
and it only saves ~100 bytes vs 2 SCTs, it seemed to be something that
should be dropped.

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Wed, 5 Feb 2014 09:19:07 -0700

Table 1 of the plan document said both 3 SCTs and 4 SCTs for 27 months.
Until there is clarification on which is required, 3-4 is the best
representation of the requirement. I'm hoping Ben meant 15-27 months = 3 and
>27 = 4, but it's not clear from the document.

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rob Stradling
Sent: Wednesday, February 05, 2014 5:37 AM
To: [email-masked]
Cc: [email-masked]; CABFPub
Subject: [cabfpub] Thoughts on reducing SCT sizes (was Re: Updated
Certificate Transparency + Extended Validation plan)

<snip>
> Adding 400 bytes per certificate will make EV certificates unusable by
entities concerned with performance.

The updated CT+EV plan requires three SCTs for a (maximum length) 27-month
EV certificate, not four.  400 bytes for three SCTs is about right though.

Assuming RFC6962-compliant v1 SCTs that contain no SCT extensions and are
signed using ECDSA and a P-256 private key, then, including all of the ASN.1
fluff for the SCT List certificate extension, I calculate that it'll be...

> We should make the SCTs as small as possible

Agreed.  Time for some back-of-an-envelope sums.  For SCT v2, if we were to
pack in the data as tightly as possible I reckon we could cut it down to as
little as...

84 bytes to embed 1 SCT

Here's how...

2. The first 2 bytes of the SignedCertificateTimestampList structure are its
total length.  Since this can be calculated from the OCTET STRING length,
these 2 bytes could be omitted.  Save 2 bytes.

3. Pack the SCT fields into as few bytes as possible for the common case,
whilst retaining options for future expansion.  Save 37 bytes per SCT.
Replace...

4. Use the Ed25519 signature scheme instead of ECDSA.  ECDSA signatures
using a P-256 key seem to be 72 or 73 bytes, whereas Ed25519 signatures are
64 bytes.  Save 8 or 9 bytes per SCT.
Also, for Ed25519, omit the 2 bytes containing the hash algorithm and
signature algorithm from the "digitally-signed struct" header.  Save 2 bytes
per SCT.

---

From: "Jeremy Rowley" <[email-masked]>
Date: Wed, 5 Feb 2014 09:24:28 -0700

We could also remove the subject field to save a bunch of space, but that would defeat the point of the certificate.  Similarly, removing the public notice defeats the purpose of our relying party warranty.  However, I do think we need to shorten the message and deliver it more efficiently. 

Thanks for the heads up.

Jeremy

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Wednesday, February 05, 2014 5:55 AM
To: Jeremy Rowley
Cc: [email-masked]; 'Ben Laurie'; 'CABFPub'; [email-masked]
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended Validation plan

> Adding 400 bytes per certificate will make EV certificates unusable by entities concerned with performance.

BTW Jeremy, in seeking to get some perspective on this issue, I notice that the current EV cert for www.digicert.com has a Certificate Policies User Notice that takes up 338 bytes!  (2 bytes per character, 'cos for some reason you use a BMPString).

"Any use of this Certificate constitutes acceptance of the DigiCert CP/CPS and the Relying Party Agreement which limit liability and are incorporated herein by reference"

You could save 169 bytes immediately by simply switching from BMPString to UTF8String!  ;-)

---

From: "Jeremy Rowley" <[email-masked]>
Date: Wed, 5 Feb 2014 09:29:44 -0700

We've issued one month certs before. We would have used shorter certs if the
CAB Forum had relaxed the OCSP requirements.  Since these are supposed to be
extremely streamlined, one SCT would be great.  

Jeremy

-----Original Message-----
Sent: Wednesday, February 05, 2014 8:40 AM

I'm to blame for that.

Certificates with a single SCT put a lower bound on how quickly we can
distrust a log (at least without special measures, such as shipping the
whole, public log hashes to all the clients, which is probably
impractical.) Since I'm not aware of any CAs issuing one month certs, and it
only saves ~100 bytes vs 2 SCTs, it seemed to be something that should be
dropped.

Cheers

AGL

---

From: "Jeremy Rowley" <[email-masked]>
Date: Wed, 5 Feb 2014 09:32:36 -0700

True - short lived certs are typically not EV certs, but, as pointed out,
the eventual plan is for all certs.  We might as well make it uniform now.  

Anyone use a short-lived cert must be able to easily replace existing
certificates.  That, combined with the relatively low number of
certificates, minimalizes the risk of a site going dark because of a
compromised log.  

Jeremy

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, February 05, 2014 9:20 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended
Validation plan

If we are talking about EV certificates then probably there are not many
that are valid for a 1 month. 

It may be the case for other types of certificates. For example CERTUM issue
trusted test SSL certificates valid for 30 days (standard DV verification
procedures and DV certificate profile). 

>From the other hand we give our customer possibility to manually shorten
validity period to one day if they like (for every certificate type). 

-Michał 

Adam Langley <[email-masked]> 
Wysłane przez: [email-masked] 

2014-02-05 16:40 

Do

certificate-transparency <[email-masked]> 

DW

"[email-masked]" <[email-masked]>, CABFPub <[email-masked]>

Temat

Re: [cabfpub] Updated Certificate Transparency + Extended        Validation
plan

I'm to blame for that.

Cheers

AGL
_______________________________________________
Public mailing list
[email-masked]
 <https://cabforum.org/mailman/listinfo/public>
https://cabforum.org/mailman/listinfo/public

---

From: Carl Wallace <[email-masked]>
Date: Wed, 05 Feb 2014 11:51:29 -0500

On 2/4/14, 2:41 PM, "Adam Langley" <[email-masked]> wrote:

>> I do not think this is correct.  The number of proofs actually
>>increases as you decrease validity periods.
>

This would be more clear if the section of the document that notes Chrome
will periodically refresh the list of qualifying logs also indicated the
list of formerly qualifying logs will also be updated.  You will need both
lists.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Feb 2014 08:55:36 -0800

On Feb 5, 2014, at 7:26 AM, Rob Stradling <[email-masked]> wrote:

> Table 1 and Footnote 4 seem a bit confused, wrongly implying that 39-month EV certs do exist and/or that >39-month non-EV certs don't exist.
> 
> >60 month non-EV SSL certificates shouldn't have been issued by any CA since the BRs came into effect.
> 
> >39 month non-EV SSL certificates shouldn't be issued from 1st April 2015, as per the BRs.

The above seems to be based in the belief that no one than CABForum members issue certificates. It also seems to be based on the idea that no CABForum member will ever not follow the current-at-the-time CABForum rules.

The CT work seems to be based on the idea that other CAs exist, and even that CABForum members might not follow the CABForum rules. Those seem like good assumptions to me.

--Paul Hoffman

---

From: Adam Langley <[email-masked]>
Date: Wed, 5 Feb 2014 12:17:59 -0500

> The CT work seems to be based on the idea that other CAs exist, and even that CABForum members might not follow the CABForum rules. Those seem like good assumptions to me.

In this case I think the table was drafted with all certificates in
mind and we didn't remove the inapplicable rows when just considering
EV certificates.

In general, CAs that issue outside of the Baseline are skating on thin
ice whether they are CA/B Forum members or not. We can (and do)
enforce Baseline limits in software.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Feb 2014 17:26:29 +0000

On 05/02/14 15:39, Adam Langley wrote:
> impractical.)

Sure.

How quickly do you want to be able to distrust a log (without needing to 
resort to using probably impractical special measures)?

Presumably it's somewhere between 10 and 31 days, since 1 SCT is 
acceptable for Stapled OCSP and the BRs permit OCSP Responses to be 
valid for up to 10 days.

> Since I'm not aware of any CAs issuing one month certs,

Maybe not today, but...

> and it only saves ~100 bytes vs 2 SCTs, it seemed to be something that

Do you still think [1] is a good plan?

I think we should design CT with the assumption that [1] might happen in 
the future.  Just looking at what CAs are issuing today seems 
short-sighted IMHO.

How about requiring only 1 SCT for certs with durations <= the maximum 
validity period for an OCSP Response?

[1] https://www.imperialviolet.org/2011/03/18/revocation.html
"A much better solution would be for certificates to only be valid for a 
few days and to forget about revocation altogether. This doesn't mean 
that the private key needs to change every few days, just the 
certificate. And the certificate is public data, so servers could just 
download their refreshed certificate over HTTP periodically and 
automatically (like OCSP stapling). Clients wouldn't have to perform 
revocation checks (which are very complex and slow), CAs wouldn't have 
to pay for massive, DDoS proof serving capacity and revocation would 
actually work. If the CA went down for six hours, nobody cares. Only if 
the CA is down for days is there a problem. If you want to “revoke” a 
certificate, just stop renewing it."

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Feb 2014 09:37:44 -0800

> enforce Baseline limits in software.

Where "we" is Chrome, yes? Is the list of the rules you enforce published somewhere other than in the source code? If so, that would help the CT conversation a great deal.

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Feb 2014 17:48:02 +0000

> The CT work seems to be based on the idea that other CAs exist, and even that CABForum members might not follow the CABForum rules. Those seem like good assumptions to me.

Paul, there are 2 things going on here.

1. The IETF CT work (i.e. RFC6962) hasn't specified anything about 
requiring multiple SCTs, and I doubt RFC6962-bis will change that.  In 
this context, other CAs do exist (both CABForum non-members and 
non-publicly-trusted CAs).

2. The Chrome CT roll-out plan.  In this context, CAs that don't adhere 
to the BRs and EVGs are likely to find that their non-compliant certs 
are rejected for other reasons.  This is the context to which I was 
speaking.

---

From: Adam Langley <[email-masked]>
Date: Wed, 5 Feb 2014 12:49:21 -0500

On Wed, Feb 5, 2014 at 12:26 PM, Rob Stradling <[email-masked]> wrote:
> Presumably it's somewhere between 10 and 31 days, since 1 SCT is acceptable
> for Stapled OCSP and the BRs permit OCSP Responses to be valid for up to 10
> days.

The speed at which we need to distrust a log depends on the minimum
number of SCTs actually, which is why allowing a single SCT in stapled
OCSP responses is such a large concession. If the minimum number of
SCTs were two then the pressure to distrust a log (and the pressure on
the logs) would be dramatically reduced because compromising one log
wouldn't be sufficient.

> Do you still think [1] is a good plan?

Sure, if any CAs are willing to do it now :)

> validity period for an OCSP Response?

I agree that, if we're going to allow one SCT for stapled OCSP
responses then we might as well allow one for 10 day certs.

However, the only case where ~100 bytes makes any different is if the
certificate chain is right on the edge of the initcwnd and the server
cannot (somehow?) set the initcwnd. I.e. it's gone cargo cult.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Feb 2014 18:21:14 +0000

> Sure, if any CAs are willing to do it now :)

I think "servers could just download their refreshed certificate over 
HTTP periodically and automatically" is the showstopper at the moment. 
Yes they could, but I'm not aware of any server that actually implements 
such a feature.

For at least httpd and nginx, I guess it would be pretty easy (albeit 
crude) to implement this in a simple shell script.  The bigger problem 
would be getting it widely deployed to servers.

> cannot (somehow?) set the initcwnd. I.e. it's gone cargo cult.

What % of deployed servers can't (and/or don't?) set the initcwnd?

How small (in bytes) does a certificate chain need to be in order to 
avoid overflowing the initcwnd?

Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Rick Andrews <[email-masked]>
Date: Thu, 6 Feb 2014 10:51:16 -0800

Ben,

Can you clarify something? The SCT delivery options described in the RFC are options for the web site owner, not for the CA. CAs will need to support all three options. We will have customers who won’t do stapling and can’t handle TLS extensions, so they just want the SCTs embedded in the cert. But not all customers will prefer that option. I believe other customers will want the SCT-in-the-OCSP-response or TLS extension option, because in those options you don’t have to transmit the SCTs in every SSL handshake. I suspect some of our large customers who are obsessed with performance will demand one of these options.
 
So CAs will need to support all three options, unless you’re so small a CA that your few EV customers agree on one option. Is that your expectation?

-Rick

> From: therightkey [mailto:[email-masked]] On Behalf Of
> Ben Laurie
> Sent: Tuesday, February 04, 2014 9:08 AM

---

From: Adam Langley <[email-masked]>
Date: Thu, 6 Feb 2014 14:05:25 -0500

> So CAs will need to support all three options, unless you’re so small a CA that your few EV customers agree on one option. Is that your expectation?

SCTs embedded in the certificate won't be sent for resumption
handshakes of course.

The TLS extension will be sent in the same cases as SCTs embedded in
the certificate. (And the TLS extension doesn't need the CA to do
anything.)

The stapled OCSP response is likely to be sent in the same cases also.
One could imagine a client that doesn't request a stapled OCSP
response when it has a cached OCSP response for the certificate that
it saw from the server last time. But, if the server responds with a
different certificate it's stuck. So I expect clients to always
request the OCSP staple.

So a CA only really need worry about the embedded case. Customers who
are concerned about the performance impact of a few hundred extra
bytes very likely have much easier avenues to reduce the size, like
having different certs for different names rather than dozens of SANs.

Cheers

AGL

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 4 Feb 2014 11:18:45 -0800

> the last I've heard from our team is  they are still at 100 bytes per log.

Moving [email-masked] 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.

---

From: [email-masked]
Date: Wed, 5 Feb 2014 17:19:38 +0100

It may be the case for other types of certificates. For example CERTUM 
issue trusted test SSL certificates valid for 30 days (standard DV 
verification procedures and DV certificate profile).

-Michał

Do
certificate-transparency <[email-masked]>
DW
"[email-masked]" <[email-masked]>, CABFPub 
<[email-masked]>
Temat
Re: [cabfpub] Updated Certificate Transparency + Extended       Validation 
plan

I'm to blame for that.

Cheers

AGL

---

From: Ben Laurie <[email-masked]>
Date: Sat, 8 Feb 2014 13:13:50 +0000

On 5 February 2014 15:26, Rob Stradling <[email-masked]> wrote:
> Table 1 and Footnote 4 seem a bit confused, wrongly implying that 39-month
> EV certs do exist and/or that >39-month non-EV certs don't exist.
>

Yes, I will release a slightly updated version clarifying this (and
other points) a bit more.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 8 Feb 2014 13:28:54 +0000

> list of formerly qualifying logs will also be updated.  You will need both

Good point, I will update the document.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 8 Feb 2014 13:32:16 +0000

On 5 February 2014 18:21, Rob Stradling <[email-masked]> wrote:
>>> acceptable
> I think "servers could just download their refreshed certificate over HTTP
> periodically and automatically" is the showstopper at the moment. Yes they
> could, but I'm not aware of any server that actually implements such a
> feature.

Work is under way for Apache: https://github.com/trawick/ct-httpd/.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 8 Feb 2014 13:40:09 +0000

> having different certs for different names rather than dozens of SANs.

Just to clarify: if CAs want to use OCSP stapling, then obviously they
need to add CT support to their OCSP responder. But the only thing CAs
really _have_ to do is the embedded case.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 10 Feb 2014 10:13:36 +0000

> Work is under way for Apache: https://github.com/trawick/ct-httpd/.

That looks like great work, but AFAICT it's only for fetching SCTs from 
CT Logs.

I was talking about the lack of any mechanism in popular webserver 
software for automatically fetching and installing certificates from 
CAs.  In particular: a short-duration certificate that reuses the same 
public key as the previous certificate.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 10 Feb 2014 11:35:41 +0000

On 10 February 2014 10:13, Rob Stradling <[email-masked]> wrote:
>>>> On Wed, Feb 5, 2014 at 12:26 PM, Rob Stradling
>>>> <[email-masked]>
>>>> wrote:
>>>>>
>>>>>
>>>>> for Stapled OCSP and the BRs permit OCSP Responses to be valid for up
>>>>> to
>>>>> 10
>>>>> days.
>>>>
>>>>
>>>>
>>> HTTP
> That looks like great work, but AFAICT it's only for fetching SCTs from CT
> Logs.
>
> I was talking about the lack of any mechanism in popular webserver software
> for automatically fetching and installing certificates from CAs.  In
> particular: a short-duration certificate that reuses the same public key as
> the previous certificate.

Ah, I see! But why would you need it if you can refresh the SCTs yourself?

---

From: Rob Stradling <[email-masked]>
Date: Mon, 10 Feb 2014 11:50:13 +0000

> Ah, I see! But why would you need it if you can refresh the SCTs yourself?

To fix certificate revocation checking, by avoiding the need for it (as 
Adam proposed a couple of years ago - see [1]).

But really, I was just trying to point out that just because CAs aren't 
noticeably issuing short-duration certs today, it doesn't mean that they 
won't do so in the future.  So I think it is worth permitting just 1 
embedded SCT for short-duration certs (for some value of "short").

---

From: Rick Andrews <[email-masked]>
Date: Mon, 10 Feb 2014 16:59:52 -0800

> Sent: Saturday, February 08, 2014 5:40 AM
> To: Adam Langley
> Cc: [email-masked]; certificate-transparency; CABFPub
> Subject: Re: [therightkey] Updated Certificate Transparency + Extended
> Validation plan
> 
> >> Can you clarify something? The SCT delivery options described in the
> RFC are options for the web site owner, not for the CA. CAs will need
> to support all three options. We will have customers who won’t do
> stapling and can’t handle TLS extensions, so they just want the SCTs
> embedded in the cert. But not all customers will prefer that option. I
> believe other customers will want the SCT-in-the-OCSP-response or TLS
> extension option, because in those options you don’t have to transmit
> the SCTs in every SSL handshake. I suspect some of our large customers
> who are obsessed with performance will demand one of these options.
> >>
> >> So CAs will need to support all three options, unless you’re so
> small a CA that your few EV customers agree on one option. Is that your
> expectation?
> >

I thought the TLS extension will be sent only if the client requests it. 'Clients that support the extension SHOULD send a ClientHello extension with the appropriate type and empty "extension_data".'

And I suspect that CAs would need/want to create a service to help their customers obtain SCTs if they choose the TLS extension option. 

-Rick

---

From: Chema López González <[email-masked]>
Date: Mon, 10 Feb 2014 17:28:47 +0100

Have anyone take into account the current position of
EJBCA<http://blog.ejbca.org/2013/09/certificate-transparency-and.html>,
a mayor player in this stuff of digital certificates?

To summarize:

"My suggestion:
- Skip PreCertificates altogether"

On the other hand, trying to use a thing that looks like a certificate
(X.509v3) not to do the task of a certificate is like trying to use a
screwdriver to nail nails.

We agree that the information contained in the precertificate is relevant,
and that the signature of such information is also necessary, but maybe the
container could be a different format or ASN.1 structure different from a
X.509v3 cert.

 <http://www.firmaprofesional.com/>

*Chema López González AC Firmaprofesional S.A.*

Av. Torre Blanca, 57.
Edificio ESADECREAPOLIS - 1B13

08173 Sant Cugat del Vallès. Barcelona.
Tel: 93.477.42.45 / 666.429.224

El contenido de este mensaje y de sus anexos es confidencial. Si no es el
destinatario, le hacemos saber que está prohibido utilizarlo, divulgarlo
y/o copiarlo sin tener la autorización correspondiente. Si ha recibido este
mensaje por error, le agradeceríamos que lo haga saber inmediatamente al
remitente y que proceda a destruir el mensaje.

On Mon, Feb 10, 2014 at 12:50 PM, Rob Stradling <[email-masked]>wrote:

> CT
> software

---

From: Ben Laurie <[email-masked]>
Date: Tue, 11 Feb 2014 11:00:28 +0000

> I thought the TLS extension will be sent only if the client requests it. 'Clients that support the extension SHOULD send a ClientHello extension with the appropriate type and empty "extension_data"…

That is true, but I would expect all CT-capable clients to support the
extension.

Sure.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 11 Feb 2014 18:30:26 +0000

Chema, thanks for posting the link to the EJBCA blog on pre-certificates.  I’ve pasted in the text below.  We should discuss these questions in Mountain View.

By the way, the blog below says that Certificate Transparency is supported in EJBCA Enterprise<http://www.primekey.se/Products/EJBCA+PKI/> as of EJBCA version 6.0.4.  However, in looking at the EJBCA website, that version has not yet been released, so any CA using EJBCA will not have updated software to use.

Kirk R. Hall
Operations Director, Trust Services
Trend Micro

*************

Certificate Transparency and PreCertificates, how will that work?

The Certificate Transparency initiative (RFC6962<http://tools.ietf.org/html/rfc6962>) is an admirable suggestion to improve security of TLS web session for certificates issued by public CAs. It has cool technology with Merkle trees, is admirable short and could have been straight forward was it not for something called PreCertificates. PreCertificates are hard for me to understand, I don't like them. I hope it is because I don't understand them...if so please let me know.

Writing this post is a way to sort things out for myself and I'd be happy to edit this post if explained why I "just don't get it". Of course I am posting this to the CT forum as well...

In the sake of transparency, I'm writing with the view point of an implementer of open source CA software<http://ejbca.org/> (if you didn't figure that one out from the blog name:-)).

Update 1: I got lots of comments already over at the Certificate Transparency Forum<https://groups.google.com/forum/?fromgroups#!topic/certificate-transparency/1tWzSXKe3gQ>, really good.

Update 2: I created an issue in the Certificate Transparency issue tracker. https://code.google.com/p/certificate-transparency/issues/detail?id=18

Update 3: Of course my views on CT changes as the discussion continues, the post below was my original starting point. Follow the discussion in Update 1 for updates.

Update 4: EJBCA supports Certificate Transparency in EJBCA Enterprise<http://www.primekey.se/Products/EJBCA+PKI/> as of EJBCA version 6.0.4.

On to PreCertificates...

PreCertificates are defined in section "3.1. Log Entries<http://tools.ietf.org/html/rfc6962#section-3.1>" as (text trimed by me) "The Precertificate is constructed from the certificate to be issued by adding a special critical poison extension to the end-entity TBSCertificate". Then it describes how it can be produced and it is mentioned throughout the spec in many places.
A PreCertificate is a essentially a certificate signed with one of two options:

1. PreCertificates signed by the real CA.
This sounds very dangerous as will break the fundamental X.509 rule of unique issuerDN/serialNumber pairs. The consequences of having two "certificates" with the same issuerDN/serialNumber in the wild can not possibly be estimated, making this practice quite dangerous imho.

2. PreCertificates signed by a separate PreCertificate signing CA, which is a SubCA to the real signing CA. This is a less scary, since it is normal practice that different CAs can issue certificate with the same subjectDN/serialNumber, just not the same issuerDN.

The actual implementation of issuing PreCertificates makes it quite impractical. I would believe that most CA implementations creates the TBSCertificate<http://tools.ietf.org/html/rfc5280#section-4.1.1.1> as part of the actual certificate issuance. The CA will not create the TBSCertificate to have is lying around for a couple of days before using it to issue the real certificate.
Thus, if the CA is to create a PreCertificate to send to the CT log, it might as well issue the real certificate and send it to the log. The time difference should be in the milliseconds for most CAs.
If the CA wants to wait before distributing the real certificate, to make sure it's in the logs before put into production, it can surely do so as well.

The PreCertificate imho suffers from several complicating factors for implementers, both on the CA and the CT log side. The TBSCertificate must have a poison extension inserted, and removed, effectively re-encoding the ASN.1 TBSCertificate several times, all these are points of failure.

The reason for PreCertificates are not clearly explained. Why would you want to use PreCertificates?

Fine combing through the spec gives me some ideas on why, for example to be able to embed the Certificate extension from PreCertificate CT logs in the final certificate (section 3.3<http://tools.ietf.org/html/rfc6962#section-3.3>). But the the TBSCertificate of the PreCertificate is then no longer the real TBSCertificate? In that case, why is the PreCertificate the TBSCertificate at all, and not just a new data structure with the data the CT log wants?

The PreCertificate complicates the CT spec by orders of magnitude, which is not a good thing. There are so many ifs and buts about PreCertificate the RFC is not even itself consitent about what it is.

Ok, I know the PreCertificate is is optional, but the best standards, who gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping PreCertificates from the CT spec makes it so much simpler.

My suggestion:
- Skip PreCertificates altogether

I see though why people will not accept that just because I say something...so in that case

- Explain the purpose behind PreCertificates well
- Describe what the actual information fro PreCertificate are used
- Be consistent throughout in the RFC

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chema López González
Sent: Monday, February 10, 2014 8:29 AM
To: Rob Stradling; [email-masked]
Cc: [email-masked]; CABFPub
Subject: Re: [cabfpub] Updated Certificate Transparency + Extended Validation plan

Have anyone take into account the current position of EJBCA<http://blog.ejbca.org/2013/09/certificate-transparency-and.html>, a mayor player in this stuff of digital certificates?

To summarize:
"My suggestion:

On the other hand, trying to use a thing that looks like a certificate (X.509v3) not to do the task of a certificate is like trying to use a screwdriver to nail nails.

We agree that the information contained in the precertificate is relevant, and that the signature of such information is also necessary, but maybe the container could be a different format or ASN.1 structure different from a X.509v3 cert.

[AC Firmaprofesional S.A.]<http://www.firmaprofesional.com/>

Chema López González

AC Firmaprofesional S.A.

Av. Torre Blanca, 57.

El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, le hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si ha recibido este mensaje por error, le agradeceríamos que lo haga saber inmediatamente al remitente y que proceda a destruir el mensaje.

On Mon, Feb 10, 2014 at 12:50 PM, Rob Stradling <[email-masked]<mailto:[email-masked]>> wrote:
On 10/02/14 11:35, Ben Laurie wrote:
> On 10 February 2014 10:13, Rob Stradling <[email-masked]<mailto:[email-masked]>> wrote:
>>> On 5 February 2014 18:21, Rob Stradling <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>> wrote:
>>>>>>
>>>>>>

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Feb 2014 15:29:52 +0000

Sorry for long delay.

> 27 = 4, but it's not clear from the document.

Yes, that's exactly what I meant.

> You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> For more options, visit https://groups.google.com/groups/opt_out.

---

From: Tim Moses <[email-masked]>
Date: Tue, 18 Feb 2014 15:37:56 +0000

Ben - Will Chrome deny EV  status to a certificate with too few SCTs, or will it grant EV status as long as at least one of its SCTs is from a log that remains in the program?

All the best. Tim.

> On Feb 18, 2014, at 10:30 AM, "Ben Laurie" <[email-masked]> wrote:
> 
> Sorry for long delay.
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Feb 2014 16:58:56 +0000

> Ben - Will Chrome deny EV  status to a certificate with too few SCTs, or will it grant EV status as long as at least one of its SCTs is from a log that remains in the program?

It will deny.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 Feb 2014 12:07:41 -0500

>> Ben - Will Chrome deny EV  status to a certificate with too few SCTs, or will it grant EV status as long as at least one of its SCTs is from a log that remains in the program?

Doesn't this reintroduce the perverse incentive to avoid killing a
known-misbehaving log?

one of the nice things about requiring corroborative SCTs on new certs
is that we can kill any log that is misbehaving without any pushback
from certificate-holders concerned that their site will "go dark" (or
"lose the fancy green label", in this EV case).

If we make it so that the EV label goes away when either of the
corroborators dies, then certificate holders have incentive to support a
failed log, even though this goes against the best interests of their users.

	--dkg

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Feb 2014 18:27:57 +0000

> failed log, even though this goes against the best interests of their users.

That's not the rule. The rule is you need one SCT from a live log, and
N SCTs from logs that were valid at the time of issue.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 Feb 2014 13:40:32 -0500

>> Doesn't this reintroduce the perverse incentive to avoid killing a
 [...]
> N SCTs from logs that were valid at the time of issue

Thanks.  That makes sense, and resolves my concern.

	--dkg