Proposed changes to EV/CT Plan

[Ben Laurie]

Current version: http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0

I propose the following changes, which I hope will address the various concerns recently expressed:

Change:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Feb 2015."

To:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Jan 2015."

Rationale: this is what the body of the document actually says and what we have been telling people we'll be doing all along. I have no idea why I failed to notice this, I guess I just stopped reading that first paragraph. Sorry - I realise this has continued to cause confusion!

Change:

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

To:

"On 1 Jan 2015 Chrome will create a whitelist of valid EV certificates already issued that would not otherwise qualify (see below) issued by CAs participating in CT from all qualifying logs."

Rationale: allow CAs to embed SCTs from not-yet-qualified logs without disqaulifying the certs from whitelisting. Also allows CAs to start issuing embedded certs early with little risk.

Change:

"At least the number of SCTs shown in Table 1, each from an independent log that was qualifying at the time of issue, are embedded in the certificate. "

To:

"At least the number of SCTs shown in Table 1, each from an independent log that was either qualifying at the time of issue or later became qualified, are embedded in the certificate. "

Rationale: Allow CAs to embed SCTs from not-yet-qualified logs. If those logs then qualify, the SCTs count towards the required totals.

Add a new section above "Timeouts":

"Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else."

Rationale: whilst a number of logs are under development or are currently in the process of qualifying, this has taken a little longer than originally anticipated, and so relaxing the independence requirement until a few more logs come online seems appropriate.

[Rob Stradling]

Thanks Ben.  Looks good to me, as long as the Alpha log and/or DigiCert log are accepted within the very near future.

AIUI, the 90-day pre-inclusion monitoring period for the Alpha log has now concluded.  Can we expect an imminent announcement that this log will definitely be included in Chrome ASAP?

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CABrd9SS%3DJy42aUa4QuwWWqMaxq-%2Bs%3DMJHQvkBdRrMW6_C8cgMw%40mail.gmail.com.

[Matt Palmer]

On Tue, Nov 11, 2014 at 02:06:00PM +0000, 'Ben Laurie' via Certificate Transparency Policy wrote:
> Current version:
> http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0
>
> I propose the following changes, which I hope will address the various
> concerns recently expressed:
>
> Change:
>
> "In order to improve the security of Extended Validation (EV) certificates,
> Google Chrome intends to require Certificate Transparency (CT) for all EV
> certificates issued after 1 Feb 2015."
>
> To:
>
> "In order to improve the security of Extended Validation (EV) certificates,
> Google Chrome intends to require Certificate Transparency (CT) for all EV
> certificates issued after 1 Jan 2015."
>
> Rationale: this is what the body of the document actually says and what we
> have been telling people we'll be doing all along. I have no idea why I
> failed to notice this, I guess I just stopped reading that first paragraph.
> Sorry - I realise this has continued to cause confusion!

Personally, I'm not a fan of making a change like this during the holiday
period, but either way, the dates certainly should be consistent throughout
the document.

> Change:
>
> "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."
>
> To:
>
> "On 1 Jan 2015 Chrome will create a whitelist of valid EV certificates
> already issued that would not otherwise qualify (see below) issued by CAs
> participating in CT from all qualifying logs."
>
> Rationale: allow CAs to embed SCTs from not-yet-qualified logs without
> disqaulifying the certs from whitelisting. Also allows CAs to start issuing
> embedded certs early with little risk.

I think this is a very wise change.

> Change:
>
> "At least the number of SCTs shown in Table 1, each from an independent log
> that was qualifying at the time of issue, are embedded in the certificate. "
>
> To:
>
> "At least the number of SCTs shown in Table 1, each from an independent log
> that was either qualifying at the time of issue or later became qualified,
> are embedded in the certificate. "
>
> Rationale: Allow CAs to embed SCTs from not-yet-qualified logs. If those
> logs then qualify, the SCTs count towards the required totals.

The intention is solid, but the wording feels a bit clumsy. How about:

"At least the number of SCTs shown in Table 1, each from an independent log

that is qualified at the time of TLS handshake, or was qualified at the time
the SCT was issued."

I'm not 100% happy with that version either, but it reads better (to me)
than the previous version.

(As an aside, I think the phrase "independent qualifying logs" in point 3
should also reference footnote 4, for clarity)

> Add a new section above "Timeouts":
>
> "Temporary Relaxation of Independence
>
> For certificates issued before 1 July 2015, no matter how many SCTs are
> required they must come from different logs at least two of which are
> independent. For example, if three SCTs are required, two could come from
> two logs operated by the same entity, and one from a log operated by
> someone else."
>
> Rationale: whilst a number of logs are under development or are currently
> in the process of qualifying, this has taken a little longer than
> originally anticipated, and so relaxing the independence requirement until
> a few more logs come online seems appropriate.

Yeah, with the DigiCert log not being eligible for inclusion until Dec 30
(at the earliest), that does cut the timeline *rather* fine. I'm in two
minds about whether issuance date of the certificate is a sufficiently
strong guarantee. Sure, CT means we *can* now detect CAs playing
silly buggers with notBefore, but I think this requirement would be better
served by something more like this:

"For SCTs issued before 1 July 2015, no matter how many SCTs are required
(based on the validity period of the certificate), at least two must be from
logs which are independent from each other. For example, if three SCTs are
required, two could come from two logs operated by the same entity, whilst
the third must come from a log operated by someone else."

Incidentally, for the purposes of independence, should a log operated by a
third party, but running on Google's "public cloud" infrastructure, be
considered independent from pilot/aviator? Without having a lot more
insight into Google's operations, it would be hard for anyone outside of
Google to be reasonably confident that independence was maintained.

- Matt

[Ben Laurie]

On Wed Nov 12 2014 at 1:49:43 AM Matt Palmer <mpa...@hezmatt.org> wrote:

On Tue, Nov 11, 2014 at 02:06:00PM +0000, 'Ben Laurie' via Certificate Transparency Policy wrote:
> Current version:
> http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0
>
> I propose the following changes, which I hope will address the various
> concerns recently expressed:
>
> Change:
>
> "In order to improve the security of Extended Validation (EV) certificates,
> Google Chrome intends to require Certificate Transparency (CT) for all EV
> certificates issued after 1 Feb 2015."
>
> To:
>
> "In order to improve the security of Extended Validation (EV) certificates,
> Google Chrome intends to require Certificate Transparency (CT) for all EV
> certificates issued after 1 Jan 2015."
>
> Rationale: this is what the body of the document actually says and what we
> have been telling people we'll be doing all along. I have no idea why I
> failed to notice this, I guess I just stopped reading that first paragraph.
> Sorry - I realise this has continued to cause confusion!

Personally, I'm not a fan of making a change like this during the holiday
period, but either way, the dates certainly should be consistent throughout
the document.

With this revised policy, nobody has to actually change anything on Jan 1, that's just the date the whitelist is created.

That would also work. In the absence of better wording, I will adopt it.

 

I'm not 100% happy with that version either, but it reads better (to me)
than the previous version.

(As an aside, I think the phrase "independent qualifying logs" in point 3
should also reference footnote 4, for clarity)

> Add a new section above "Timeouts":
>
> "Temporary Relaxation of Independence
>
> For certificates issued before 1 July 2015, no matter how many SCTs are
> required they must come from different logs at least two of which are
> independent. For example, if three SCTs are required, two could come from
> two logs operated by the same entity, and one from a log operated by
> someone else."
>
> Rationale: whilst a number of logs are under development or are currently
> in the process of qualifying, this has taken a little longer than
> originally anticipated, and so relaxing the independence requirement until
> a few more logs come online seems appropriate.

Yeah, with the DigiCert log not being eligible for inclusion until Dec 30
(at the earliest), that does cut the timeline *rather* fine.  I'm in two
minds about whether issuance date of the certificate is a sufficiently
strong guarantee.  Sure, CT means we *can* now detect CAs playing
silly buggers with notBefore, but I think this requirement would be better
served by something more like this:

SCTs do not contain notBefore - the issuance of an SCT is the timestamp in the SCT, which, as you say, we can audit for correctness.

 

"For SCTs issued before 1 July 2015, no matter how many SCTs are required
(based on the validity period of the certificate), at least two must be from
logs which are independent from each other.  For example, if three SCTs are
required, two could come from two logs operated by the same entity, whilst
the third must come from a log operated by someone else."

Not sure how this helps with your concern!

 

Incidentally, for the purposes of independence, should a log operated by a
third party, but running on Google's "public cloud" infrastructure, be
considered independent from pilot/aviator?  Without having a lot more
insight into Google's operations, it would be hard for anyone outside of
Google to be reasonably confident that independence was maintained.

Quite so. I am not sure where we stand on this issue!

[Matt Palmer]

Ah, true. That isn't the date that Chrome starts dropping EV indications.
On the other hand, since people are people, and people generally don't do
things in advance, I'm willing to predict that, based on this deadline, at
least one CA will only start putting SCTs into certs on January 2. Not that
that's Google's fault, I agree.

Because your wording talks about *certificates* issued before 1 July 2015,
implying (though, I agree, not stating) that it is the certificate's
notBefore date that will be checked to decide whether or not to relax the
independence check. My alternate wording just changes the focus to be the
issue date of the SCT.

- Matt

--
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

[Rick Andrews]

"Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else."

Rationale: whilst a number of logs are under development or are currently in the process of qualifying, this has taken a little longer than originally anticipated, and so relaxing the independence requirement until a few more logs come online seems appropriate.

Ben, this doesn't seem like much of a relaxation to me. CAs are going to start issuing and logging certs very soon now. Digicert has two choices for the "independent" log server (theirs and alpha.ctlogs), but all other CAs have only one choice: alpha.ctlogs. I trust Matt and Google's vetting of his server, but I feel it's putting too many eggs in one basket.

I would prefer if you delay the independence requirement until there are >1 log servers independent of Google.

[Jeremy Rowley]

Rick and everyone,

 

As mentioned in our CT log server application, we’d like the DigiCert submitted log to be a CA community-run log server.  We’re going to add additional root certificates from CAs who are interested in helping run the server starting on December 15^th. If you would like to participate in our log server and are willing to participate in maintaining the log, send me an email, and we'll get your roots in by that date.  

 

Jeremy

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/0db436e2-d70e-442b-9010-7d367c7254dc%40chromium.org.

--

Jeremy Rowley
Rowley Law
(801) 633-8482
rowl...@gmail.com

Please Read the Warnings Below: This e-mail and any attachments are for use by the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, please contact me and delete the message without reading it or making a copy. 

[Matt Palmer]

On Wed, Nov 12, 2014 at 01:21:21PM -0800, Rick Andrews wrote:
> "Temporary Relaxation of Independence

[...]

> Ben, this doesn't seem like much of a relaxation to me. CAs are going to
> start issuing and logging certs very soon now. Digicert has two choices for
> the "independent" log server (theirs and alpha.ctlogs), but all other CAs
> have only one choice: alpha.ctlogs. I trust Matt and Google's vetting of
> his server, but I feel it's putting too many eggs in one basket.

But... but... it's such a *well made* basket! <grin>

I'm a bit fuzzy on why Digicert's log is only available to them. Is it
because they've only got a limited set of roots in the allowed set, and
they're not open to adding others?

If so, and you decide that you'd be best served by running your own log, I'd
be happy to help your team to get one running. Obviously I can't be
involved in operating it (that would rather defeat the purpose, since it
wouldn't be independent of alpha) but I'd be happy to give any and all help
I can. That goes for any CA (or anyone else, for that matter) who might be
interested in deploying a log.

> I would prefer if you delay the independence requirement until there are >1
> log servers independent of Google.

I'm not sure if/when there's likely to be another open-to-everyone CT log.
There's been a third inclusion request made recently (by the Basque CA
Izenpe), but that appears to have a similar policy as Digicert's log
regarding root inclusion. The Nordu team's roadmap has their log going live
in 2015 (https://www.ct.nordu.net), and I don't know what their inclusion
policy will be like.

That being said, I'm not totally happy with essentially being a
single-point-of-failure on this myself, either; while I think the
requirement for independence of logs is an important one, I find myself
sympathetic to the temporary suspension of independence during this
bootstrapping phase.

That being said, since the appearance of further independent logs is
entirely out of Google's control, it will be very difficult to put a date on
when the suspension will end, and without a firm date to point to, there's a
high chance that nobody else will prioritise the work necessary to allow
independent logs to flourish. It's a tricky problem, and I don't envy your
position in having to make the tough calls on this, Ben.

- Matt

--
Java. The elegant simplicity of C++. The blazing speed of Smalltalk.
-- From http://c2.com/cgi/wiki?SmalltalkMinusMinus

[Doug Beattie]

Hi Ben,

Ryan often pushes back on changes initiated by others that do not have a direct impact on improving security, after all, that is what we're all looking to achieve in CA/B Forum and related initiatives.  The requirement that there be at least one SCT that validates at the time Chrome checks the status is clear and precise.  I would claim that the other "requirements" (minimum number of SCTs and at least 2 independent logs) are really suggestions and best practices for CAs and web site owners to help guarantee EV treatment for the life of the certificate, but are not necessarily (security) requirements.  Shouldn't the risk that a certificate no longer has a valid SCT be a CA or Web site operator risk and not a browser risk?  In the event that an issued certificate no longer has valid SCTs the web site operator can get it reissued with a fresh set - it's not the end of the world.

This would make it easier for the community to kick-start this project now and to simplify Chrome validation rules in February.

Doug

[Ben Laurie]

On Thu Nov 13 2014 at 1:06:16 PM Doug Beattie <douglas...@gmail.com> wrote:

Hi Ben,

Ryan often pushes back on changes initiated by others that do not have a direct impact on improving security, after all, that is what we're all looking to achieve in CA/B Forum and related initiatives.  The requirement that there be at least one SCT that validates at the time Chrome checks the status is clear and precise.  I would claim that the other "requirements" (minimum number of SCTs and at least 2 independent logs) are really suggestions and best practices for CAs and web site owners to help guarantee EV treatment for the life of the certificate, but are not necessarily (security) requirements.

As it happens, this was also my position - however, various people argue that the two independent log requirement is needed to make it harder for a CA and log to collude to hide an evil certificate.

This is partly a consequence of the tradeoff that led to SCTs and the MMD - clearly a colluding log/CA can hide a cert for at least the MMD. The original design did not allow that because rather than an SCT an inclusion proof was required...

 

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/5676e6f0-31fc-479c-a52e-c23656083042%40chromium.org.

[Doug Beattie]

On Thursday, November 13, 2014 8:26:34 AM UTC-5, Ben Laurie wrote:

On Thu Nov 13 2014 at 1:06:16 PM Doug Beattie <douglas...@gmail.com> wrote:

Hi Ben,

Ryan often pushes back on changes initiated by others that do not have a direct impact on improving security, after all, that is what we're all looking to achieve in CA/B Forum and related initiatives.  The requirement that there be at least one SCT that validates at the time Chrome checks the status is clear and precise.  I would claim that the other "requirements" (minimum number of SCTs and at least 2 independent logs) are really suggestions and best practices for CAs and web site owners to help guarantee EV treatment for the life of the certificate, but are not necessarily (security) requirements.

As it happens, this was also my position - however, various people argue that the two independent log requirement is needed to make it harder for a CA and log to collude to hide an evil certificate.

This is partly a consequence of the tradeoff that led to SCTs and the MMD - clearly a colluding log/CA can hide a cert for at least the MMD. The original design did not allow that because rather than an SCT an inclusion proof was required...

 

This seems a bit excessive just to maintain the green EV treatment.  Do we expect a CA and Log provider to collude so they can issue an EV certificate which will receive the EV treatment for the MMD?

In the long run, sure, SCTs will probably trigger other treatments and security warnings, but for the foreseeable future it's only to receive the EV treatment in Chrome.

I still say that the requirements for number of SCTs and having at least 2 independent logs is overkill and should be guidelines vs. requirements.

[Ryan Sleevi]

On Thu, Nov 13, 2014 at 6:38 AM, Doug Beattie <douglas...@gmail.com> wrote:

On Thursday, November 13, 2014 8:26:34 AM UTC-5, Ben Laurie wrote:

On Thu Nov 13 2014 at 1:06:16 PM Doug Beattie <douglas...@gmail.com> wrote:

Hi Ben,

Ryan often pushes back on changes initiated by others that do not have a direct impact on improving security, after all, that is what we're all looking to achieve in CA/B Forum and related initiatives.  The requirement that there be at least one SCT that validates at the time Chrome checks the status is clear and precise.  I would claim that the other "requirements" (minimum number of SCTs and at least 2 independent logs) are really suggestions and best practices for CAs and web site owners to help guarantee EV treatment for the life of the certificate, but are not necessarily (security) requirements.

As it happens, this was also my position - however, various people argue that the two independent log requirement is needed to make it harder for a CA and log to collude to hide an evil certificate.

This is partly a consequence of the tradeoff that led to SCTs and the MMD - clearly a colluding log/CA can hide a cert for at least the MMD. The original design did not allow that because rather than an SCT an inclusion proof was required...

 

This seems a bit excessive just to maintain the green EV treatment.  Do we expect a CA and Log provider to collude so they can issue an EV certificate which will receive the EV treatment for the MMD? 

Yes, absolutely. Especially given that many CAs are interested in operating their own logs, which does nothing to reduce the risk or improve the effective transparency.

 

In the long run, sure, SCTs will probably trigger other treatments and security warnings, but for the foreseeable future it's only to receive the EV treatment in Chrome.

I'm not sure what you mean here. The requirement of CT, independent of any change in browser behaviour, provides a public audit record that a publicly trusted CA is operating in the public trust, and that publicly recognizing a CA as following the EV guidelines is a behaviour that can be publicly validated.

In short, there is zero trust in the correctness of the WebTrust EV Audits, not because the audit standards are lax (although there are a number of things in the EVGs that are not being covered by audits), but as a fundamental limitation of such audit schemes.

 

I still say that the requirements for number of SCTs and having at least 2 independent logs is overkill and should be guidelines vs. requirements.

I'm sorry that you feel that it doesn't provide security benefits, since that's been widely discussed, especially by the critics of CT who have missed that Chrome is requiring 2+ SCTs, and have instead focused on the attacks possible with only 1 SCT.

However, the argument that it's "operational" is something that can be equally made about certificate expiration policies. The Forum is shifting to a 39-month max validity period for certificates, reducing from the (current) 60 month. This reduction is not because we believe that RSA-2048 bit is safe from factoring for 60 months right now and will only last 39 months in the future, but because of the variety of operational concerns.

For certificates, this validity period is the upper-bound of when any positive movement towards security can be made (deprecating key sizes or algorithms, as an example). When those dates don't align perfectly (as with SHA-1), we see great challenges, especially those raised by CAs.

These requirements are fundamental to ensure that "too big to fail" - which is fundamentally a security concern - is not a repeated mistake in a CT-based system as it was and is within a CA system.

[Matt Palmer]

On Thu, Nov 13, 2014 at 06:38:00AM -0800, Doug Beattie wrote:
> This seems a bit excessive just to maintain the green EV treatment. Do we
> expect a CA and Log provider to collude so they can issue an EV certificate
> which will receive the EV treatment for the MMD?

I think the chances of a CA *proper* colluding with a log to be low, but I'd
certainly consider it possible that an attacker, who was able to exploit a
CA, using a compromised log to obtain CT's blessing -- that's *especially*
true if the log is one run by the same CA. By requiring two independent
logs, that increases the attacker's workload significantly. That's part of
the reason I decided to write an independent implementation for my log -- it
isn't that I think I'm $DEITY's gift to security programming, just that if
you've got to pop two logs, better that you've got to start from scratch
both times rather than using the same exploit on both.

> In the long run, sure, SCTs will probably trigger other treatments and
> security warnings, but for the foreseeable future it's only to receive the
> EV treatment in Chrome.

Maybe I have longer-range vision (or a more active imagination), but I like
to think that it won't be particularly long (in the order of 1-2 years,
which is nigh-instantaneous in the security world) before Chrome might start
talking about causing non-transparent certs to fail.

- Matt

--
"Python is a rich scripting language offering a lot of the power of C++
while retaining the ease of use of VBscript."
-- The PyWin32 documentation

[Matt Palmer]

On Thu, Nov 13, 2014 at 05:06:15AM -0800, Doug Beattie wrote:
> status is clear and precise. I would claim that the other "requirements"
> (minimum number of SCTs and at least 2 independent logs) are really
> suggestions and best practices for CAs and web site owners to help
> guarantee EV treatment for the life of the certificate, but are
> not necessarily (security) requirements.

I think that independence *is* a security requirement (as I described in my
previous message), and you can't have independence if you don't require
multiple SCTs. Increasing the number of SCTs for longer-validity
certificates is a security requirement insofar as if you don't do that, you
either get reduced security *or* a poor user experience (which has security
implications of its own).

> Shouldn't the risk that a certificate no longer has a valid SCT be a CA or
> Web site operator risk and not a browser risk? In the event that an
> issued certificate no longer has valid SCTs the web site operator can get
> it reissued with a fresh set - it's not the end of the world.

It *is* a browser risk, because it's the browser that users will blame when
their websites suddenly stop working, because that's the last thing that
changed. As a demonstration of this, consider Mozilla's attempt to improve
the certificate validation code in NSS, which resulted in this sort of
response:

https://groups.google.com/d/msg/mozilla.dev.tech.crypto/EbWse7Ryj8I/EupN1M8uFXIJ

Someone who is in that frame of mind isn't going to respond well to the
suggestion that they just need to contact the CA who originally issued the
certificate two and a half years ago and get it reissued with fresh SCTs.
They'll point out how everything "worked just fine" with the previous
version of Chrome (that trusted the log that's now been kicked out for being
shady). From a security perspective, not requiring[1] more SCTs will just
train people to click through "pointless" security warnings. If you take
the hard line and make it impossible for people to click through, you'll get
the sort of message in the above URL.

To prevent degrading the user experience, you could have the browser say,
"well, if the SCT in the cert was issued by a log that was trusted at the
time the SCT was issued, you should continue to trust it, and not degrade
the user experience", but that degrades security. A compromised log key
means that an attacker can forge an SCT with any timestamp -- and they can
present any view of the log they like (by forging the entire log history if
need be). So, if a log is removed, no data from it can be trusted.

> This would make it easier for the community to kick-start this project
> now and to simplify Chrome validation rules in February.

Apologies in advance for the crudity of this statement, but a lack of
planning on the part of "the community" does not constitute an emergency on
Chromium's part.

The criteria under which certs would get EV treatment has been known since
March. Heck, I first heard of CT in *May*, and somehow the log I'm running
(on code I independently implemented, entirely from the RFC) is the first
non-Google log to get into Chromium. There really isn't any reason why more
logs couldn't have been setup by interested parties. Digicert and Izenpe
have got logs up, and assuming they pass muster (no reason they shouldn't),
that's a decent crop. If you (or anyone) feels that there should be more
logs out there, my offer to help anyone stand up a log server remains open.

If there were a criteria which I think could stand to be temporarily
adjusted for the good of CT adoption, it would be the monitoring lead time
for new logs. Watching my log -- an independent implementation run by an
unknown individual -- for three months, is prudent. For an established CA
like Digicert, I'm willing to bet that if they can keep a log running for a
month (which they've now done) they can keep it going for a while. Assuming
that there have been no hiccups with the Digicert log since it started being
monitored on about October 6, I'd say they've proven the log is stable, and
it would be of more benefit to add them at the same time as alpha than to
wait until the end of the year.

- Matt

[1] Yes, "requiring". Whilst in principle you could leave it up to CAs to
do their own risk assessment, in practice that won't fly. There are valid
arguments that *can* be made in favour of embedding fewer SCTs into a
certificate. Given that the costs of failing to do so are borne almost
entirely by the browser, it's an externality as far as the CA is concerned,
so no CA will rationally decide to put more SCTs into a certificate than
they have to[2]. Hence, Chromium's decision to *mandate* a larger number of
SCTs is the rational one, to force the CAs to take an action that will
mitigate Chromium's risk.

[2] If any CA would like to prove me wrong in that analysis, feel free:
embed more SCTs than you need to into the certificates you issue in January
2015. I'm not holding my breath.

[Sigbjørn Vik]

On 13-Nov-14 15:38, Doug Beattie wrote:
> Do
> we expect a CA and Log provider to collude so they can issue an EV
> certificate which will receive the EV treatment for the MMD?

Well, yes, this is one scenario we want to protect against. But not the
only one.

If a log provider and a CA is the same entity, it makes it all so much
easier for a government to force this entity to issue a certificate and
a fake log. A government is also able to ensure that usage of this
certificate only happens inside a walled garden (cordon off the targeted
user), so nobody would ever know. Even if the CA and the log provider(s)
operate in the same country, a government can still do this.

I have argued for before (and still believe), that not only should there
be multiple logs, but at least one of the logs should come from a region
not controlled by the same government as the CA.

--
Sigbjørn Vik
Opera Software

[Rob Stradling]

On 14/11/14 00:49, Matt Palmer wrote:

There really isn't any reason why more logs couldn't have been setup by interested parties.

Hi Matt.  Setting up an RFC6962-compliant log is one thing, but making it robust and scalable is something else.  When we do apply to have our log(s) added to Chromium, I want to be confident that we can keep them running, keep our MMD promises, etc.

We're intending to setup at least one log using the certificate-transparency.org code, but my understanding is that the work to make it sufficiently robust and scalable is still ongoing.  If, a year ago, it had been clear that the certificate-transparency.org was not going to be production-ready in time for the EV/CT launch, then we probably would have considered writing our own log server code.  Oh well.

BTW, I see that your Alpha log has now been officially added to Chromium.  Congratulations!

I just hope Alpha turns out to be robust and scalable.  :-)

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

[Doug Beattie]

On Thu, Nov 13, 2014 at 2:50 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Nov 13, 2014 at 6:38 AM, Doug Beattie <douglas...@gmail.com> wrote:

On Thursday, November 13, 2014 8:26:34 AM UTC-5, Ben Laurie wrote:

On Thu Nov 13 2014 at 1:06:16 PM Doug Beattie <douglas...@gmail.com> wrote:

Hi Ben,

Ryan often pushes back on changes initiated by others that do not have a direct impact on improving security, after all, that is what we're all looking to achieve in CA/B Forum and related initiatives.  The requirement that there be at least one SCT that validates at the time Chrome checks the status is clear and precise.  I would claim that the other "requirements" (minimum number of SCTs and at least 2 independent logs) are really suggestions and best practices for CAs and web site owners to help guarantee EV treatment for the life of the certificate, but are not necessarily (security) requirements.

As it happens, this was also my position - however, various people argue that the two independent log requirement is needed to make it harder for a CA and log to collude to hide an evil certificate.

This is partly a consequence of the tradeoff that led to SCTs and the MMD - clearly a colluding log/CA can hide a cert for at least the MMD. The original design did not allow that because rather than an SCT an inclusion proof was required...

 

This seems a bit excessive just to maintain the green EV treatment.  Do we expect a CA and Log provider to collude so they can issue an EV certificate which will receive the EV treatment for the MMD? 

Yes, absolutely. Especially given that many CAs are interested in operating their own logs, which does nothing to reduce the risk or improve the effective transparency.

You're not answering my question.  If you want to impose a requirement that CAs can't use just their log, fine.  But you didn't answer the question I asked which was why do you need more than one independent log today?  Posting to 2 logs, sure, that is good practice.

 

 

In the long run, sure, SCTs will probably trigger other treatments and security warnings, but for the foreseeable future it's only to receive the EV treatment in Chrome.

I'm not sure what you mean here. The requirement of CT, independent of any change in browser behaviour, provides a public audit record that a publicly trusted CA is operating in the public trust, and that publicly recognizing a CA as following the EV guidelines is a behaviour that can be publicly validated.

In short, there is zero trust in the correctness of the WebTrust EV Audits, not because the audit standards are lax (although there are a number of things in the EVGs that are not being covered by audits), but as a fundamental limitation of such audit schemes.

 

Let's face it, the only reason CAs are posting to CT logs is to maintain EV treatment in Chrome.  Why would shady CAs that are lax about meeting audit standards want to log anything more than absolutely required?  Your statements above don't have any bearing on the current situation (which I just noticed changed since Alpha was just approved).

I'll ask a pointed question: Does Google have plans to require SCTs, or logging of certificates post issuance for purposes other than maintaining the current EV treatment?  If so, let's hear it now vs. 9 weeks before existing certificates are suddenly untrusted.  Matt is implying there are plans.  If that's the case, we'd like to know so we can issue certificates today which will work without UI degradation for their lifetime (which by the way, is still 60 months)

 

I still say that the requirements for number of SCTs and having at least 2 independent logs is overkill and should be guidelines vs. requirements.

I'm sorry that you feel that it doesn't provide security benefits, since that's been widely discussed, especially by the critics of CT who have missed that Chrome is requiring 2+ SCTs, and have instead focused on the attacks possible with only 1 SCT.

There are no security benefits until all certificates are required to be logged and a more severe browser treatment is applied to those certificates that CT compliant by all/most browsers.  The bad guy will just obtain certificates from products which are not publically logged as part of issuance.  Where is the security in that?  We haven't lowered the bar - it remains exactly where it has been for all certificates.  Only EV certificates are supposed to be logged, but if they are not logged they just don't receive the green EV treatment(which has nothing to do with security).  There is no security penalty for not logging so all of the attacks discussed for logs are irrelevant from a security perspective (today). 

What am I missing?  CT appears to be purely an academic exercise until all SSL certificates must be logged and browsers provide security warnings/treatment when encountering non CT certificates.

 

However, the argument that it's "operational" is something that can be equally made about certificate expiration policies. The Forum is shifting to a 39-month max validity period for certificates, reducing from the (current) 60 month. This reduction is not because we believe that RSA-2048 bit is safe from factoring for 60 months right now and will only last 39 months in the future, but because of the variety of operational concerns.

For certificates, this validity period is the upper-bound of when any positive movement towards security can be made (deprecating key sizes or algorithms, as an example). When those dates don't align perfectly (as with SHA-1), we see great challenges, especially those raised by CAs.

These requirements are fundamental to ensure that "too big to fail" - which is fundamentally a security concern - is not a repeated mistake in a CT-based system as it was and is within a CA system.

I have no idea what you're talking about.  Is there a statement in there that answers my question about why you need independent logs or why you need more SCTs for longer validity period certificates as it relates to security? 

[Jeremy Rowley]

I think Ben Laurie's been pretty straightforward about the goal being to eventually to log every SSL cert. I'm guessing they want to observe how the EV plan goes before deciding exact timelines for when that will happen.  I'm hoping it'll happen fairly quickly afterwards since the non-EV certs will be a more interesting observation than EV.  Although the exercise is purely academic until all certs are logged, it's an important academic exercise to ensure that CT doesn't break the Internet.   

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAE-_UVe4hTU_qqvuKsp5TW2dK31aA5_VgmMcNaVLJn9KTGEHhg%40mail.gmail.com.

[Richard Salz]

> Although the exercise is purely academic until all certs are logged

I don't understand this. Why isn't it just a good thing?

[Matt Palmer]

On Fri, Nov 14, 2014 at 11:31:54AM +0000, Rob Stradling wrote:
> On 14/11/14 00:49, Matt Palmer wrote:
> >There really isn't any reason why more logs couldn't have been
> >setup by interested parties.
>
> Hi Matt. Setting up an RFC6962-compliant log is one thing, but
> making it robust and scalable is something else.

It's not as though running a robust and scalable web service is an unsolved
problem, though.

> If, a year ago, it had been clear that the
> certificate-transparency.org was not going to be production-ready in
> time for the EV/CT launch, then we probably would have considered
> writing our own log server code. Oh well.

I'm sure the people behind the c-t.org codebase would have welcomed
additional contributions to help it reach its goals earlier. As I
understand it, at least the Izenpe log is using that codebase -- and I
assume Digicert's using it, too. In that case, presumably it isn't *that*
far away from being robust and scalable.

> BTW, I see that your Alpha log has now been officially added to
> Chromium. Congratulations!
>
> I just hope Alpha turns out to be robust and scalable. :-)

Well, I'd have more of an idea of that if anyone was actually submitting
certs to it... but I've done a fair amount of load-testing, and I'm pretty
confident that the scalability mechanisms are solid. It helps that the
responses to most of the requests are *very* cacheable, and the database
update is async.

- Matt

--
"You keep using that word. I do not think it means what you think it means."
-- Inigo, The Princess Bride

[Jeremy Rowley]

It's a good thing, but if you can issue a DV or OV cert without logging it, then it doesn't eliminate the threat.  EV certs have a lot higher validation so aren't likely to be mis-issued.  EV will help detect a compromised CA (if the attacker issued an EV cert), but not necessarily. 

On Fri, Nov 14, 2014 at 3:51 PM, Richard Salz <rich...@gmail.com> wrote:

>  Although the exercise is purely academic until all certs are logged

I don't understand this.  Why isn't it just a good thing?

[Matt Palmer]

Hi Doug,

On Fri, Nov 14, 2014 at 02:57:52PM -0500, Doug Beattie wrote:
> I'll ask a pointed question: Does Google have plans to require SCTs, or
> logging of certificates post issuance for purposes other than maintaining
> the current EV treatment? If so, let's hear it now vs. 9 weeks before
> existing certificates are suddenly untrusted. Matt is implying there are
> plans.

Just in case there's some misunderstanding here, I'm not privvy to any
behind-the-scenes information about Chromium's plans re: CT. I don't work
for Google in any capacity, nor have I had private conversations with anyone
at Google regarding the future plans for CT. I'm basing my statements
entirely upon public information, such as that in
http://www.certificate-transparency.org/ev-ct-plan, which states, in part:

Once we have gained experience with EV certificates we will publish a
plan to bring CT to all certificates.

(Incidentally, the 1 Feb 2015 cutover date for non-CT EV certs is mentioned
on *that* page, too... Ben, that's another place that needs adjusting).

> If that's the case, we'd like to know so we can issue certificates today
> which will work without UI degradation for their lifetime (which by the
> way, is still 60 months)

My best guess (again, based entirely on public information and a healthy
dose of hand-waving) is that the cutover would be made similarly to that for
EV certs -- probably with a longer lead-time, to reduce the number of certs
that have to be whitelisted (if that turns out to be a good idea). My
expectation would be that the cutover date would also be influenced by the
availability of servers which are capable of serving SCTs in the TLS
handshake, and/or support OCSP stapling (along with OCSP responders which
place SCTs in the OCSP response).

The decision as to whether to throw up erors could also be applied to
certificates based on their notAfter date, giving CAs the opportunity to
"phase-in" SCT issuance, starting with those certificates that would last
the longest. Say, an announcement any time before late 2016 that "any
certificate with a notAfter date on or after 1 April 2020 will have to pass
CT verification in order to be considered trusted". That would let any
five-year certs issued just before the BR 39-month deadline (tell me there
ain't going to be a whole *pile* of five-year certs issued in late March
next year...) avoid the need for CTs, give CAs puh-*lenty* of time to get
their infrastructure CT-ready, before needing to incorporate SCTs into their
certs (or else hope and pray that OCSP stapling or SCTs in the TLS handshake
get very widespread deployment). This plan wouldn't give any comfort to any
remaining "valid for a decade" certs that might be around out there, but
frankly I'd be happy if those certs all died in a fire anyway.

> >> I still say that the requirements for number of SCTs and having at least
> >> 2 independent logs is overkill and should be guidelines vs. requirements.
> >
> > I'm sorry that you feel that it doesn't provide security benefits, since
> > that's been widely discussed, especially by the critics of CT who have
> > missed that Chrome is requiring 2+ SCTs, and have instead focused on the
> > attacks possible with only 1 SCT.
>
> There are no security benefits until all certificates are required to be
> logged and a more severe browser treatment is applied to those certificates
> that CT compliant by all/most browsers. The bad guy will just obtain
> certificates from products which are not publically logged as part of
> issuance. Where is the security in that? We haven't lowered the bar - it
> remains exactly where it has been for all certificates. Only EV
> certificates are supposed to be logged, but if they are not logged they

> just don't receive the green EV treatment (which has nothing to do with

> security). There is no security penalty for not logging so all of the
> attacks discussed for logs are irrelevant from a security perspective
> (today).

Applying CT to EV strengthens EV's assertions, which presumably can only be
a good thing for CAs' marketing efforts. Not only have all of the extended
verification checks been done as required by the EV standards, but the
existence of those certs has *also* been made broadly public, providing an
additional level of verification that the certificate was not mistakenly or
fraudulently issued. It sounds at least as useful, from a security
perspective, as any other part of the EV requirements.

> What am I missing? CT appears to be purely an academic exercise until all
> SSL certificates must be logged and browsers provide security
> warnings/treatment when encountering non CT certificates.

I think that targeting CT at EV certificates initially is one of the
smartest parts of Chromium's plan. It provides for a phased introduction
period, with real motivation for CAs to get involved on a reasonable
timescale, with deadlines that are short enough to get people's
attention[1], without inflicting scary security warnings on users.

- Matt

[1] Honestly, if the announcement had been made in March this year that
TLS connections lacking SCTs would be marked as untrusted in Chromium as of
1 January 2020, would *any* CA have moved to do anything? I sincerely doubt
it. It's just too far away, with too many chances that something would
happen between now and 2020 to make the plan fail to materialise.

[Rob Stradling]

On 14/11/14 22:55, Matt Palmer wrote:

On Fri, Nov 14, 2014 at 11:31:54AM +0000, Rob Stradling wrote:

On 14/11/14 00:49, Matt Palmer wrote:

There really isn't any reason why more logs couldn't have been
setup by interested parties.

Hi Matt.  Setting up an RFC6962-compliant log is one thing, but
making it robust and scalable is something else.

It's not as though running a robust and scalable web service is an unsolved
problem, though.

In the unfortunate event that your average "robust and scalable web service" fails to meet its SLAs, things are grim, but what's the worst that can happen?

If a CT log fails to meet its MMD promise, it's game over for that log.  Period.

If, a year ago, it had been clear that the
certificate-transparency.org was not going to be production-ready in
time for the EV/CT launch, then we probably would have considered
writing our own log server code.  Oh well.

I'm sure the people behind the c-t.org codebase would have welcomed
additional contributions to help it reach its goals earlier.

Often the best approach to open-source is to cheer from the sidelines and leave the guys who are intimately acquainted with the project to actually write the code.

As I
understand it, at least the Izenpe log is using that codebase -- and I
assume Digicert's using it, too.  In that case, presumably it isn't *that*
far away from being robust and scalable.

From private conversations with Ben, that's not the impression I've got.

Ben, it would be great if you would comment on how production-ready the certificate-transaction.org codebase is right now.

BTW, I see that your Alpha log has now been officially added to
Chromium.  Congratulations!

I just hope Alpha turns out to be robust and scalable.  :-)

Well, I'd have more of an idea of that if anyone was actually submitting
certs to it... but I've done a fair amount of load-testing, and I'm pretty
confident that the scalability mechanisms are solid.  It helps that the
responses to most of the requests are *very* cacheable, and the database
update is async.

Well, since the independent log requirement remains and Alpha is the only non-Google log that intends to accept all EV roots, you can expect your log to see some action real soon now.  :-)

[Matt Palmer]

On Mon, Nov 17, 2014 at 09:24:38AM +0000, Rob Stradling wrote:
> Well, since the independent log requirement remains and Alpha is the
> only non-Google log that intends to accept all EV roots, you can
> expect your log to see some action real soon now. :-)

All I have to say is encapsulated in the last 15 seconds of this clip:

http://www.youtube.com/watch?v=ZWa7fsECAes

- Matt

--
Judging by this particular thread, many people in this group spent their
school years taking illogical, pointless orders from morons and having their
will to live systematically crushed. And people say school doesn't prepare
kids for the real world. -- Rayner, in the Monastery

[Rob Stradling]

On 17/11/14 22:25, Matt Palmer wrote:

On Mon, Nov 17, 2014 at 09:24:38AM +0000, Rob Stradling wrote:

Well, since the independent log requirement remains and Alpha is the
only non-Google log that intends to accept all EV roots, you can
expect your log to see some action real soon now.  :-)

All I have to say is encapsulated in the last 15 seconds of this clip:

http://www.youtube.com/watch?v=ZWa7fsECAes

Enjoy the ride.  :-)

[Ben Laurie]

On Mon Nov 17 2014 at 9:24:42 AM Rob Stradling <robs...@gmail.com> wrote:

As I
understand it, at least the Izenpe log is using that codebase -- and I
assume Digicert's using it, too.  In that case, presumably it isn't *that*
far away from being robust and scalable.

From private conversations with Ben, that's not the impression I've got.

Ben, it would be great if you would comment on how production-ready the certificate-transaction.org codebase is right now.

We believe the existing codebase is reasonably robust, however, we did not intend it to be used as-is for production services. There's a couple of core issues...

1. No horizontal scaling - the server runs on a single machine, there's no option to have multiple front-ends.

2. Not stress-tested - although we do have numerous tests for correct functionality, we have not ensured that the code holds up well under load.

So, there's some risk attached to running a log based on that code.

Certainly some actions can be taken to mitigate the risks. Here are some suggestions:

1. Back up the database really frequently - and keep each copy on multiple machines, ideally not all physically co-located - see https://www.sqlite.org/backup.html for backing up an SQLite database (note: I haven't tried this, so I don't know how long it might disable the server for). There isn't a way to reliably back up a FileDB (because state may change during a backup) currently, though it could be added.

2. Run on hardware built for reliability - and use RAID for disks.

3. Get familiar with building a new server from backups. If you have to do it, you won't have long.

4. Don't forget to back up the private key - in a safe place!

5. Do some serious load testing.

6. Be ready to migrate to our new codebase (which is a distributed system with a focus on safety and reliability) when it becomes available (there will be a migration tool for the data).

7. Hope that a bug is not unearthed that causes serious data loss (but see above re: backups).

Contributions to the coding are always welcome - if you don't want to mess with the core, tougher tests are a good way to help.

Given that we intend to have a migration path to robust code in the next few months (no promises!) I certainly wouldn't rule out using the existing code as a stopgap, but there's definitely a risk of it all going horribly wrong. I guess we have to practice striking off a log some day. :-)

[Rob Stradling]

Thanks Ben.

"there's definitely a risk of it all going horribly wrong" is precisely why we haven't been overly keen to use "the existing code as a stopgap"!


BTW, on the subject of "serious load testing"...

6962-bis currently says...
   "TLS clients receive SCTs alongside or in certificates...
    TLS clients MAY audit the corresponding log by requesting, and
    verifying, a Merkle audit proof for said certificate."

Will Chrom[e|ium] be doing this when your EV/CT plan comes into effect?

If millions of browsers are going to be hitting the logs directly, that puts the scalability requirements into a whole new ball park.

[Rick Andrews]

Ben, Ryan,

When do you expect to finalize these policy changes? While the number of qualified log servers is no longer an issue, there's still the independence clause.

The policy in effect right now (March EV CT Plan) says SCTs from three independent logs are required for a 27-month cert, and says "An independent log is one that does not share infrastructure or administrative access with another log used for the same certificate." This language is open to interpretation - are Google's three logs independent from each other? Since we're getting very close to deploying our CT capability, we seem to have no choice but to assume that Google's logs are independent of one another; hence we'll be putting two or three SCTs from Google's log servers in our certs. We trust that future versions of Chrome will treat these as qualified certificates.

[Ben Laurie]

On Tue Nov 18 2014 at 11:25:20 PM Rick Andrews <rick_a...@symantec.com> wrote:

Ben, Ryan,

When do you expect to finalize these policy changes? While the number of qualified log servers is no longer an issue, there's still the independence clause.

The policy in effect right now (March EV CT Plan) says SCTs from three independent logs are required for a 27-month cert, and says "An independent log is one that does not share infrastructure or administrative access with another log used for the same certificate." This language is open to interpretation - are Google's three logs independent from each other?

No. Whilst we could perhaps make some convoluted arrangement to avoid sharing at least some infrastructure/admin in Google's production systems that would be quite hard to do and also very hard to convince anyone else we had actually done it.

The "Operator" field in http://www.certificate-transparency.org/known-logs is intended to capture this information ("operated_by" array in JSON).

 

Since we're getting very close to deploying our CT capability, we seem to have no choice but to assume that Google's logs are independent of one another; hence we'll be putting two or three SCTs from Google's log servers in our certs. We trust that future versions of Chrome will treat these as qualified certificates.

There are now two independent qualified logs, and will soon be a third, so I can't agree that you have no choice.

 

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/c020576d-e91d-4e69-8ded-037b3110a1d6%40chromium.org.

[Rick Andrews]

Since we're getting very close to deploying our CT capability, we seem to have no choice but to assume that Google's logs are independent of one another; hence we'll be putting two or three SCTs from Google's log servers in our certs. We trust that future versions of Chrome will treat these as qualified certificates.

There are now two independent qualified logs, and will soon be a third, so I can't agree that you have no choice.

Ben, I respectfully disagree. We plan to start logging live certs in a few weeks, and the third log server (Digicert) won't be available until the end of December. For two year certs, our choices are a) use two Google servers and alpha.ctlogs, b) don't log at all and lose the EV treatment.

[Ben Laurie]

You also have stapled OCSP and the CT TLS extension...

To be clear, I accept that you have a problem with the policies as published, which motivates some of the changes I have proposed.

If those changes are made, do you still have a problem?

[Rick Andrews]

You also have stapled OCSP and the CT TLS extension...

True, for customers who say they're ready to handle those, but no customers have expressed that to us.

To be clear, I accept that you have a problem with the policies as published, which motivates some of the changes I have proposed.

If those changes are made, do you still have a problem?

No, if those changes are made, I think we're able to issue qualified certificates. Thanks for your efforts to update the policy.

[Ryan Sleevi]

On Tue, Nov 11, 2014 at 6:06 AM, 'Ben Laurie' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

Current version: http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0

I propose the following changes, which I hope will address the various concerns recently expressed:

Change:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Feb 2015."

To:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Jan 2015."

Rationale: this is what the body of the document actually says and what we have been telling people we'll be doing all along. I have no idea why I failed to notice this, I guess I just stopped reading that first paragraph. Sorry - I realise this has continued to cause confusion!

Indeed, I'm not sure how we missed this. I agree this brings consistency to the document.

 

Change:

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

To:

"On 1 Jan 2015 Chrome will create a whitelist of valid EV certificates already issued that would not otherwise qualify (see below) issued by CAs participating in CT from all qualifying logs."

Rationale: allow CAs to embed SCTs from not-yet-qualified logs without disqaulifying the certs from whitelisting. Also allows CAs to start issuing embedded certs early with little risk.

Sounds reasonable.

 

Change:

"At least the number of SCTs shown in Table 1, each from an independent log that was qualifying at the time of issue, are embedded in the certificate. "

To:

"At least the number of SCTs shown in Table 1, each from an independent log that was either qualifying at the time of issue or later became qualified, are embedded in the certificate. "

Rationale: Allow CAs to embed SCTs from not-yet-qualified logs. If those logs then qualify, the SCTs count towards the required totals.

I am lightly uncomfortable with this change. In my experience reviewing audits for CAs, the gap of time between key creation and operationalization has left a hole for a variety of "test" certificates to be created that otherwise violate the CA's stated policies or operations. Such logs will lack client gossip or monitoring, which may create opportunities for malfeasance in the interim.

That said, any such malfeasance should be (eventually) detectable. However, one suggested change for wording would be "that were either qualified at the time of issue or had applied for inclusion and was being actively monitored" (although more wordsmithing is needed to incorporate Matt Palmer's much-needed tweaking). This helps balance the need for monitoring with the flexibility that some CAs may need.

 

Add a new section above "Timeouts":

"Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else."

Rationale: whilst a number of logs are under development or are currently in the process of qualifying, this has taken a little longer than originally anticipated, and so relaxing the independence requirement until a few more logs come online seems appropriate.

I'm not entirely comfortable with this date.

As has been noted elsewhere on this thread, CAs have been aware of the tentative requirements for some time (see, for example, https://cabforum.org/pipermail/public/2013-September/002233.html ), and the final requirements since mid-March ( https://cabforum.org/pipermail/public/2014-March/003064.html ) .

Even in the absence of a finalized CT Log Inclusion Policy (announced 26 June - see https://cabforum.org/pipermail/public/2014-June/003536.html ), there has been significant notice to CAs about the expectations regarding logging, with ample opportunity to work on developing log servers if the existing log capabilities did not meet their needs. It is rather telling that the first log that has been accepted, meeting all of the policy requirements, was a log developed not by a CA, but by an independent third-party.

Of the two logs being evaluated (as Matt Palmer's is now included), Digicert ( https://code.google.com/p/chromium/issues/detail?id=419255 ) and Izenpe ( https://code.google.com/p/chromium/issues/detail?id=431700 ) both have stated that during their testing phase, they do not plan to be accepting additional roots. If they do add any additional roots, they will need to update their bugs accordingly.

As has also been noted on this thread, pushing this date back further creatives incentives to delay in investing in infrastructure and deployment of additional logs.

Indeed, these are all issues that were anticipated by the policy, both in draft and final form, which has provided OCSP Stapling as an alternative for CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been aware of this as a mechanism since RFC 6962 was published (June 2013), and from the many discussions prior to this, and could have prioritized work on improving and communicating with their customers on the many positive benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

Rather than 1 July, which seems both rather significant a delay, I'd like to suggest a more balanced date of either 1 April or 30 days following the inclusion of a third, independently-operated log, whichever comes first. Does this sound reasonable?

[Richard Salz]

> Indeed, these are all issues that were anticipated by the policy, both in
> draft and final form, which has provided OCSP Stapling as an alternative for
> CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been
> aware of this as a mechanism since RFC 6962 was published (June 2013), and
> from the many discussions prior to this, and could have prioritized work on
> improving and communicating with their customers on the many positive
> benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

I don't see how that helps very much. Does stapling change the quota
requirements?
If there are not enough logs that you can submit to (i.e., that will
accept your root), then stapling won't work either. And if there are,
it seems like a non-trivial engineering effort to require an OCSP
responder, which previously only needed to check local/internal
revocation data, to now maintain a database of additional data to
include. It can be done, of course -- it's just code, and it's
arguably simpler than modifying an existing certiciation workflow --
but I don't think it's fair to brush it off as if it were nothing.

And again, if there aren't enough logs out there, stapling does
nothing. And by my reading of the spec and [trans] mailing list
discussions, I took stapling to be a temporary thing until SCT
embedding was done. Apparently that's not correct, but it sure does
(did) seem like a reasonable interpretation of things.

[Rob Stradling]

On 20/11/14 15:46, Richard Salz wrote:

<snip>

And again, if there aren't enough logs out there, stapling does nothing. And by my reading of the spec and [trans] mailing list discussions, I took stapling to be a temporary thing until SCT embedding was done. Apparently that's not correct, but it sure does (did) seem like a reasonable interpretation of things.

There are no plans to deprecate any of the 3 SCT distribution mechanisms (certificate extension, OCSP response extension, SCT TLS extension), so to label any of them as "temporary" is misleading IMHO.

[Ben Laurie]

On Thu Nov 20 2014 at 4:00:19 AM Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue, Nov 11, 2014 at 6:06 AM, 'Ben Laurie' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

Current version: http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0

I propose the following changes, which I hope will address the various concerns recently expressed:

Change:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Feb 2015."

To:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Jan 2015."

Rationale: this is what the body of the document actually says and what we have been telling people we'll be doing all along. I have no idea why I failed to notice this, I guess I just stopped reading that first paragraph. Sorry - I realise this has continued to cause confusion!

Indeed, I'm not sure how we missed this. I agree this brings consistency to the document.

 

Change:

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

To:

"On 1 Jan 2015 Chrome will create a whitelist of valid EV certificates already issued that would not otherwise qualify (see below) issued by CAs participating in CT from all qualifying logs."

Rationale: allow CAs to embed SCTs from not-yet-qualified logs without disqaulifying the certs from whitelisting. Also allows CAs to start issuing embedded certs early with little risk.

Sounds reasonable.

 

Change:

"At least the number of SCTs shown in Table 1, each from an independent log that was qualifying at the time of issue, are embedded in the certificate. "

To:

"At least the number of SCTs shown in Table 1, each from an independent log that was either qualifying at the time of issue or later became qualified, are embedded in the certificate. "

Rationale: Allow CAs to embed SCTs from not-yet-qualified logs. If those logs then qualify, the SCTs count towards the required totals.

I am lightly uncomfortable with this change. In my experience reviewing audits for CAs, the gap of time between key creation and operationalization has left a hole for a variety of "test" certificates to be created that otherwise violate the CA's stated policies or operations. Such logs will lack client gossip or monitoring, which may create opportunities for malfeasance in the interim.

That said, any such malfeasance should be (eventually) detectable.

As you say, it would be detectable. What's more, it becomes detectable as soon as the cert becomes usable (i.e. when the log qualifies), so I can't see that the situation is any worse than using a qualified log. In fact, it is slightly better, because the MMD will already have passed (or some of it will, for really recent certs at the time of qualification).

 

However, one suggested change for wording would be "that were either qualified at the time of issue or had applied for inclusion and was being actively monitored" (although more wordsmithing is needed to incorporate Matt Palmer's much-needed tweaking).

Its been a long thread, could you say which tweaking you had in mind?

I think "applied for inclusion" is fine to add, though perhaps a little pointless - there's not much mileage in including SCTs from logs that are not applying for inclusion!

"being actively monitored" is a little more vague - by who? how do we know?

 

This helps balance the need for monitoring with the flexibility that some CAs may need.

 

Add a new section above "Timeouts":

"Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else."

Rationale: whilst a number of logs are under development or are currently in the process of qualifying, this has taken a little longer than originally anticipated, and so relaxing the independence requirement until a few more logs come online seems appropriate.

I'm not entirely comfortable with this date.

As has been noted elsewhere on this thread, CAs have been aware of the tentative requirements for some time (see, for example, https://cabforum.org/pipermail/public/2013-September/002233.html ), and the final requirements since mid-March ( https://cabforum.org/pipermail/public/2014-March/003064.html ) .

Even in the absence of a finalized CT Log Inclusion Policy (announced 26 June - see https://cabforum.org/pipermail/public/2014-June/003536.html ), there has been significant notice to CAs about the expectations regarding logging, with ample opportunity to work on developing log servers if the existing log capabilities did not meet their needs. It is rather telling that the first log that has been accepted, meeting all of the policy requirements, was a log developed not by a CA, but by an independent third-party.

Of the two logs being evaluated (as Matt Palmer's is now included), Digicert ( https://code.google.com/p/chromium/issues/detail?id=419255 ) and Izenpe ( https://code.google.com/p/chromium/issues/detail?id=431700 ) both have stated that during their testing phase, they do not plan to be accepting additional roots. If they do add any additional roots, they will need to update their bugs accordingly.

As has also been noted on this thread, pushing this date back further creatives incentives to delay in investing in infrastructure and deployment of additional logs.

Indeed, these are all issues that were anticipated by the policy, both in draft and final form, which has provided OCSP Stapling as an alternative for CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been aware of this as a mechanism since RFC 6962 was published (June 2013), and from the many discussions prior to this, and could have prioritized work on improving and communicating with their customers on the many positive benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

Rather than 1 July, which seems both rather significant a delay, I'd like to suggest a more balanced date of either 1 April or 30 days following the inclusion of a third, independently-operated log, whichever comes first. Does this sound reasonable?

Almost: I think we need to have more than three independent logs, or there's no redundancy at all for max-length EV certs - so I'd say the number should be at least four. Five would make me more comfortable.

 

[Peter Bowen]

On Thu, Nov 20, 2014 at 7:46 AM, Richard Salz <rich...@gmail.com> wrote:
>> Indeed, these are all issues that were anticipated by the policy, both in
>> draft and final form, which has provided OCSP Stapling as an alternative for
>> CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been
>> aware of this as a mechanism since RFC 6962 was published (June 2013), and
>> from the many discussions prior to this, and could have prioritized work on
>> improving and communicating with their customers on the many positive
>> benefits of OCSP Stapling, one of which includes EV treatment in a CT world.
>
> I don't see how that helps very much. Does stapling change the quota
> requirements?

From my reading of the Chrome EV/CT policy, providing SCTs via OCSP
stapling or the TLS extension means you only have provide two,
regardless of the duration of the validity period. After all, Adam's
plucky certificate doesn't need to worry about one of the IDs becoming
invalid during its journey around the world, as the IDs are constantly
refreshed.

[Doug Beattie]

Ryan,

Kirk's question on this statement triggered a follow-up question:

"At least the number of SCTs shown in Table 1, each from an independent log that was qualifying at the time of issue, are embedded in the certificate. "

For a 1-year EV certificate we need at least 2 SCTs. If we add a 3rd, does that need to be from a 3rd log provider, even though it's a bonus SCT?  In other words, if we put in SCTs from Alpha, Aviator and Pilot would the certificate be accepted or not?

Doug

On Wed, Nov 19, 2014 at 11:00 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue, Nov 11, 2014 at 6:06 AM, 'Ben Laurie' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

Current version: http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0

[Ben Laurie]

On Thu Nov 20 2014 at 3:46:03 PM Richard Salz <rich...@gmail.com> wrote:

> Indeed, these are all issues that were anticipated by the policy, both in
> draft and final form, which has provided OCSP Stapling as an alternative for
> CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been
> aware of this as a mechanism since RFC 6962 was published (June 2013), and
> from the many discussions prior to this, and could have prioritized work on
> improving and communicating with their customers on the many positive
> benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

I don't see how that helps very much.  Does stapling change the quota
requirements?
If there are not enough logs that you can submit to (i.e., that will
accept your root), then stapling won't work either.

Stapling/TLS extensions allow a lower number of SCTs because they can be updated if logs become untrusted, unlike certs.

 

And if there are,
it seems like a non-trivial engineering effort to require an OCSP
responder, which previously only needed to check local/internal
revocation data, to now maintain a database of additional data to
include. It can be done, of course -- it's just code, and it's
arguably simpler than modifying an existing certiciation workflow --
but I don't think it's fair to brush it off as if it were nothing.

And again, if there aren't enough logs out there, stapling does
nothing. And by my reading of the spec and [trans] mailing list
discussions, I took stapling to be a temporary thing until SCT
embedding was done.  Apparently that's not correct, but it sure does
(did) seem like a reasonable interpretation of things.

There are many reasons stapling is desirable beyond CT, so its definitely not a temporary thing from our POV. As Rob says, none of the mechanisms are temporary.

 

[Ben Laurie]

On Thu Nov 20 2014 at 4:14:50 PM Doug Beattie <douglas...@gmail.com> wrote:

Ryan,

Kirk's question on this statement triggered a follow-up question:

"At least the number of SCTs shown in Table 1, each from an independent log that was qualifying at the time of issue, are embedded in the certificate. "

For a 1-year EV certificate we need at least 2 SCTs. If we add a 3rd, does that need to be from a 3rd log provider, even though it's a bonus SCT?  In other words, if we put in SCTs from Alpha, Aviator and Pilot would the certificate be accepted or not?

Yes, it would. That is "each from an independent log" applies to the minimum number. Bonus SCTs are just that ... a bonus. :-)

At least, according to my reading and reasoning, but I admit this could perhaps be clearer.

[Kirk R. Hall]

Ben, here is a further suggested edit for the Google CT plan – drop the “independent” CT log requirement entirely for the first half of 2015.  Continue to require the same number of SCTs as in your original plan (including both from CT logs that have been accepted by Google, and those that are pending), but don’t be concerned as to whether or not they are independent. 

I realize you have already planned to relax the independence rule for six months in your modification proposal – only two of the SCTs must be “independent” – but at this point we don’t know how well any CT log will function in actual full production, and CAs will be grabbing SCTs wherever they can get them in order to comply with CT's requirements.  After six months, we will have data on use, plus maybe more CT logs to choose from.

Starting CT for EV certs on Jan. 1 – even without an “independence” requirement for the first six months – will be a great improvement over EV certs today with no CT, so you are giving up very little, and probably helping to avoid potential CT failure in the early weeks by opening up more combinations of CT logs to CAs.  Later, you can impose a requirement of two independent CT logs, and eventually three independent logs (if three SCTs are required in the cert).

So I’m suggesting you modify your proposed edits to the CT requirements to read as follows:

Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs. 

For certificates issued between 1 July and 31 December 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else.

[After Dec. 31, 2015, the original language requiring three independent CT logs would apply.]

What do you think?

On Tuesday, November 11, 2014 6:06:03 AM UTC-8, Ben Laurie wrote:

Current version: http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0

I propose the following changes, which I hope will address the various concerns recently expressed:

Change:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Feb 2015."

To:

"In order to improve the security of Extended Validation (EV) certificates, Google Chrome intends to require Certificate Transparency (CT) for all EV certificates issued after 1 Jan 2015."

Rationale: this is what the body of the document actually says and what we have been telling people we'll be doing all along. I have no idea why I failed to notice this, I guess I just stopped reading that first paragraph. Sorry - I realise this has continued to cause confusion!

Change:

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

To:

"On 1 Jan 2015 Chrome will create a whitelist of valid EV certificates already issued that would not otherwise qualify (see below) issued by CAs participating in CT from all qualifying logs."

Rationale: allow CAs to embed SCTs from not-yet-qualified logs without disqaulifying the certs from whitelisting. Also allows CAs to start issuing embedded certs early with little risk.

Change:

"At least the number of SCTs shown in Table 1, each from an independent log that was qualifying at the time of issue, are embedded in the certificate. "

To:

"At least the number of SCTs shown in Table 1, each from an independent log that was either qualifying at the time of issue or later became qualified, are embedded in the certificate. "

Rationale: Allow CAs to embed SCTs from not-yet-qualified logs. If those logs then qualify, the SCTs count towards the required totals.

[Ryan Sleevi]

On Thu, Nov 20, 2014 at 7:46 AM, Richard Salz <rich...@gmail.com> wrote:

> Indeed, these are all issues that were anticipated by the policy, both in
> draft and final form, which has provided OCSP Stapling as an alternative for
> CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been
> aware of this as a mechanism since RFC 6962 was published (June 2013), and
> from the many discussions prior to this, and could have prioritized work on
> improving and communicating with their customers on the many positive
> benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

I don't see how that helps very much.  Does stapling change the quota
requirements?

Yes. It reduces it from 3 SCTs to 2 SCTs for certs >= 15 months. 

 

If there are not enough logs that you can submit to (i.e., that will
accept your root), then stapling won't work either. And if there are,
it seems like a non-trivial engineering effort to require an OCSP
responder, which previously only needed to check local/internal
revocation data, to now maintain a database of additional data to
include. It can be done, of course -- it's just code, and it's
arguably simpler than modifying an existing certiciation workflow --
but I don't think it's fair to brush it off as if it were nothing.

And again, if there aren't enough logs out there, stapling does
nothing. And by my reading of the spec and [trans] mailing list
discussions, I took stapling to be a temporary thing until SCT
embedding was done.  Apparently that's not correct, but it sure does
(did) seem like a reasonable interpretation of things.

There are enough qualifying logs for stapling. There isn't (but likely will be) for embedding. 

[Ryan Sleevi]

There are indeed no plans to deprecate embedding SCTs. However, embedding SCTs is fundamentally more risky than stapling, because once issued, it cannot be changed. Stapling provides a robust means for ongoing transparency, but requires server operators to support it.

Thus embedding is conceptually transitional until stapling becomes ubiquitous, after which stapling will be the "preferred" method. Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.

[Ryan Sleevi]

https://groups.google.com/a/chromium.org/d/msg/ct-policy/Ij8K3jLIcs4/v8nZs0R3XrQJ

Matt's suggested wording:

"At least the number of SCTs shown in Table 1, each from an independent log that is qualified at the time of TLS handshake, or was qualified at the time  the SCT was issued."

Integrated wording:

"At least the number of SCTs shown in Table 1, each from an independent log that is qualified at the time of TLS handshake, or was qualified at the time the SCT was issued or later became qualified."

 

 

I think "applied for inclusion" is fine to add, though perhaps a little pointless - there's not much mileage in including SCTs from logs that are not applying for inclusion!

"being actively monitored" is a little more vague - by who? how do we know?

By us, as part of the log inclusion policy. We know because there will be a bug on file for inclusion and it will be in the monitoring phase.

 

 

This helps balance the need for monitoring with the flexibility that some CAs may need.

 

Add a new section above "Timeouts":

"Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else."

Rationale: whilst a number of logs are under development or are currently in the process of qualifying, this has taken a little longer than originally anticipated, and so relaxing the independence requirement until a few more logs come online seems appropriate.

I'm not entirely comfortable with this date.

As has been noted elsewhere on this thread, CAs have been aware of the tentative requirements for some time (see, for example, https://cabforum.org/pipermail/public/2013-September/002233.html ), and the final requirements since mid-March ( https://cabforum.org/pipermail/public/2014-March/003064.html ) .

Even in the absence of a finalized CT Log Inclusion Policy (announced 26 June - see https://cabforum.org/pipermail/public/2014-June/003536.html ), there has been significant notice to CAs about the expectations regarding logging, with ample opportunity to work on developing log servers if the existing log capabilities did not meet their needs. It is rather telling that the first log that has been accepted, meeting all of the policy requirements, was a log developed not by a CA, but by an independent third-party.

Of the two logs being evaluated (as Matt Palmer's is now included), Digicert ( https://code.google.com/p/chromium/issues/detail?id=419255 ) and Izenpe ( https://code.google.com/p/chromium/issues/detail?id=431700 ) both have stated that during their testing phase, they do not plan to be accepting additional roots. If they do add any additional roots, they will need to update their bugs accordingly.

As has also been noted on this thread, pushing this date back further creatives incentives to delay in investing in infrastructure and deployment of additional logs.

Indeed, these are all issues that were anticipated by the policy, both in draft and final form, which has provided OCSP Stapling as an alternative for CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been aware of this as a mechanism since RFC 6962 was published (June 2013), and from the many discussions prior to this, and could have prioritized work on improving and communicating with their customers on the many positive benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

Rather than 1 July, which seems both rather significant a delay, I'd like to suggest a more balanced date of either 1 April or 30 days following the inclusion of a third, independently-operated log, whichever comes first. Does this sound reasonable?

Almost: I think we need to have more than three independent logs, or there's no redundancy at all for max-length EV certs - so I'd say the number should be at least four. Five would make me more comfortable.

We're on track for three (Google, SSLWatcher, tentatively DigiCert). We have a request for a fourth (Izenpe), although it seems to be having issues. There's talk of a fifth (Nordunet). To meet that, Nordunet (or another) would need to be apply by 1 January, or a new log applied. 

[Ben Laurie]

Ah - I'd actually incorporated Matt's suggested wording in my master copy (as I said in my reply to Matt's message) - not sure that "later became qualified" adds anything, since its either included in "qualified at the time of TLS handshake" or involves predicting the future.

 

 

 

I think "applied for inclusion" is fine to add, though perhaps a little pointless - there's not much mileage in including SCTs from logs that are not applying for inclusion!

"being actively monitored" is a little more vague - by who? how do we know?

By us, as part of the log inclusion policy. We know because there will be a bug on file for inclusion and it will be in the monitoring phase.

 

 

This helps balance the need for monitoring with the flexibility that some CAs may need.

 

Add a new section above "Timeouts":

"Temporary Relaxation of Independence

For certificates issued before 1 July 2015, no matter how many SCTs are required they must come from different logs at least two of which are independent. For example, if three SCTs are required, two could come from two logs operated by the same entity, and one from a log operated by someone else."

Rationale: whilst a number of logs are under development or are currently in the process of qualifying, this has taken a little longer than originally anticipated, and so relaxing the independence requirement until a few more logs come online seems appropriate.

I'm not entirely comfortable with this date.

As has been noted elsewhere on this thread, CAs have been aware of the tentative requirements for some time (see, for example, https://cabforum.org/pipermail/public/2013-September/002233.html ), and the final requirements since mid-March ( https://cabforum.org/pipermail/public/2014-March/003064.html ) .

Even in the absence of a finalized CT Log Inclusion Policy (announced 26 June - see https://cabforum.org/pipermail/public/2014-June/003536.html ), there has been significant notice to CAs about the expectations regarding logging, with ample opportunity to work on developing log servers if the existing log capabilities did not meet their needs. It is rather telling that the first log that has been accepted, meeting all of the policy requirements, was a log developed not by a CA, but by an independent third-party.

Of the two logs being evaluated (as Matt Palmer's is now included), Digicert ( https://code.google.com/p/chromium/issues/detail?id=419255 ) and Izenpe ( https://code.google.com/p/chromium/issues/detail?id=431700 ) both have stated that during their testing phase, they do not plan to be accepting additional roots. If they do add any additional roots, they will need to update their bugs accordingly.

As has also been noted on this thread, pushing this date back further creatives incentives to delay in investing in infrastructure and deployment of additional logs.

Indeed, these are all issues that were anticipated by the policy, both in draft and final form, which has provided OCSP Stapling as an alternative for CAs that were, for a variety of reasons, unable to embed SCTs. CAs have been aware of this as a mechanism since RFC 6962 was published (June 2013), and from the many discussions prior to this, and could have prioritized work on improving and communicating with their customers on the many positive benefits of OCSP Stapling, one of which includes EV treatment in a CT world.

Rather than 1 July, which seems both rather significant a delay, I'd like to suggest a more balanced date of either 1 April or 30 days following the inclusion of a third, independently-operated log, whichever comes first. Does this sound reasonable?

Almost: I think we need to have more than three independent logs, or there's no redundancy at all for max-length EV certs - so I'd say the number should be at least four. Five would make me more comfortable.

We're on track for three (Google, SSLWatcher, tentatively DigiCert). We have a request for a fourth (Izenpe), although it seems to be having issues. There's talk of a fifth (Nordunet). To meet that, Nordunet (or another) would need to be apply by 1 January, or a new log applied.

This is true.

 

[Rob Stradling]

On 21/11/14 13:51, 'Ben Laurie' via Certificate Transparency Policy wrote:

<snip>

Matt's suggested wording:

"At least the number of SCTs shown in Table 1, each from an independent log that is qualified at the time of TLS handshake, or was qualified at the time  the SCT was issued."

Integrated wording:

"At least the number of SCTs shown in Table 1, each from an independent log that is qualified at the time of TLS handshake, or was qualified at the time the SCT was issued or later became qualified."

Ah - I'd actually incorporated Matt's suggested wording in my master copy (as I said in my reply to Matt's message) - not sure that "later became qualified" adds anything, since its either included in "qualified at the time of TLS handshake" or involves predicting the future.

Ben, the "later became qualified" language is helpful for this sequence of events: a cert is issued with an embedded SCT from a not-yet-qualified log; then the log becomes qualified; then the log is struck off; then the TLS handshake occurs; then the cert expires.

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

[Ben Laurie]

Ah, fair point. I'll add it. Though now I wonder what "is qualified at the time of TLS handshake" adds. :-)

[Rob Stradling]

On 20/11/14 21:37, Ryan Sleevi wrote:

On Thu, Nov 20, 2014 at 7:50 AM, Rob Stradling <robs...@gmail.com> wrote:

On 20/11/14 15:46, Richard Salz wrote:

<snip>

And again, if there aren't enough logs out there, stapling does nothing. And by my reading of the spec and [trans] mailing list discussions, I took stapling to be a temporary thing until SCT embedding was done. Apparently that's not correct, but it sure does (did) seem like a reasonable interpretation of things.

There are no plans to deprecate any of the 3 SCT distribution mechanisms (certificate extension, OCSP response extension, SCT TLS extension), so to label any of them as "temporary" is misleading IMHO.

There are indeed no plans to deprecate embedding SCTs. However, embedding SCTs is fundamentally more risky than stapling, because once issued, it cannot be changed. Stapling provides a robust means for ongoing transparency, but requires server operators to support it.

Thus embedding is conceptually transitional until stapling becomes ubiquitous, after which stapling will be the "preferred" method.

I fear that OCSP stapling will never become truly ubiquitous.  Even when the feature is available in the server software, some server operators don't want to allow outbound connections from their servers.

Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.

Ryan, could you explain this statement?
Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
Or what?

For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?

What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?

Thanks.

[Rob Stradling]

Good point.  :-)

So how about changing it to...
"At least the number of SCTs shown in Table 1, each from an independent log that was qualified at the time the SCT was issued or later became qualified."

?

[Rob Stradling]

On 24/11/14 10:47, Rob Stradling wrote:

On 24/11/14 10:32, Ben Laurie wrote:

<snip>

Ben, the "later became qualified" language is helpful for this sequence of events: a cert is issued with an embedded SCT from a not-yet-qualified log; then the log becomes qualified; then the log is struck off; then the TLS handshake occurs; then the cert expires.

Ah, fair point. I'll add it. Though now I wonder what "is qualified at the time of TLS handshake" adds. :-)

Good point.  :-)

So how about changing it to...
"At least the number of SCTs shown in Table 1, each from an independent log that was qualified at the time the SCT was issued or later became qualified."

?

If I embed 3 SCTs - from Pilot, Aviator and Alpha - in a 1-year EV cert, is that cert CT qualified?

The "Qualified Certificate" section of the EV/CT plan says that I only need to embed 2 SCTs in this cert, so 3 is certainly enough to satisfy the "At least the number of SCTs shown in Table 1" part.

However, that cert would not meet the "each from an independent log" part, because Pilot and Aviator are not independent.  :-(

The text needs to make it clear that whilst a certain minimum number of SCTs must be from independent logs, it is not forbidden to have additional SCTs that are not from independent logs.

It might make sense to define and use the term "Independent SCTs".

[Ben Laurie]

I couldn't figure out how to do that without being even more confusing.

I propose we add this after Table 1:

"Note that, so long as the above conditions are met by some combination of SCTs presented in the handshake, additional SCTs, regardless of origin, are permitted."

[Rob Stradling]

On 24/11/14 12:09, Ben Laurie wrote:

On Mon Nov 24 2014 at 11:19:15 AM Rob Stradling <robs...@gmail.com> wrote:

On 24/11/14 10:47, Rob Stradling wrote:

On 24/11/14 10:32, Ben Laurie wrote:

<snip>

Ben, the "later became qualified" language is helpful for this sequence of events: a cert is issued with an embedded SCT from a not-yet-qualified log; then the log becomes qualified; then the log is struck off; then the TLS handshake occurs; then the cert expires.

Ah, fair point. I'll add it. Though now I wonder what "is qualified at the time of TLS handshake" adds. :-)

Good point.  :-)

So how about changing it to...
"At least the number of SCTs shown in Table 1, each from an independent log that was qualified at the time the SCT was issued or later became qualified."

?

If I embed 3 SCTs - from Pilot, Aviator and Alpha - in a 1-year EV cert, is that cert CT qualified?

The "Qualified Certificate" section of the EV/CT plan says that I only need to embed 2 SCTs in this cert, so 3 is certainly enough to satisfy the "At least the number of SCTs shown in Table 1" part.

However, that cert would not meet the "each from an independent log" part, because Pilot and Aviator are not independent.  :-(

The text needs to make it clear that whilst a certain minimum number of SCTs must be from independent logs, it is not forbidden to have additional SCTs that are not from independent logs.

It might make sense to define and use the term "Independent SCTs".

I couldn't figure out how to do that without being even more confusing.

Yeah, that's why I didn't propose any text.  :-)

I propose we add this after Table 1:

"Note that, so long as the above conditions are met by some combination of SCTs presented in the handshake, additional SCTs, regardless of origin, are permitted."

Thanks.  That'll do.  :-)

[Rob Stradling]

On 18/11/14 09:53, Rob Stradling wrote:

On 17/11/14 22:25, Matt Palmer wrote:

On Mon, Nov 17, 2014 at 09:24:38AM +0000, Rob Stradling wrote:

Well, since the independent log requirement remains and Alpha is the
only non-Google log that intends to accept all EV roots, you can
expect your log to see some action real soon now.  :-)

All I have to say is encapsulated in the last 15 seconds of this clip:

http://www.youtube.com/watch?v=ZWa7fsECAes

Enjoy the ride.  :-)

Matt, the ride is already a bit bumpy.  ;-)

I'm seeing HTTP 400 errors from https://alpha.ctlogs.org/ct/v1/get-entries.  Seems to have started over the weekend.
get-sth still works fine though, so hopefully this is a relatively minor and easily fixable glitch.

[Matt Palmer]

Hi Rob,

On Mon, Nov 24, 2014 at 01:38:52PM +0000, Rob Stradling wrote:
> I'm seeing HTTP 400 errors from
> https://alpha.ctlogs.org/ct/v1/get-entries. Seems to have started
> over the weekend.
> get-sth still works fine though, so hopefully this is a relatively
> minor and easily fixable glitch.

Well, that's not cool. Can you give me the exact request(s) that were
failing? I can see a bunch of 400s against get-entries, but I surmise they
were failing because they were trying to make requests past the end of the
list. Other requests coming in at around the same time, for lower `end`
values, were being served OK. The body of the 400 responses should always
give you a reasonable idea of why a request was rejected, by the way -- if
it isn't obvious why a given request was rejected, let me know and I'll
improve the response.

- Matt

--
A woman in liquor production / Owns a still of exquisite construction.
The alcohol boils / Through magnetic coils.
She says that it's "proof by induction."
-- http://limerickdb.com/?34

[Rob Stradling]

Hi Matt.  I haven't tried making any requests beyond the end of the list.

Thanks for your tip about the body of the 400 responses.  Here's an example...

$ openssl s_client -connect alpha.ctlogs.org:443 -servername alpha.ctlogs.org -quiet 2>/dev/null
GET /ct/v1/get-entries?start=0&end=0 HTTP/1.1   
Host: alpha.ctlogs.org

HTTP/1.1 400 Bad Request
Server: nginx/1.2.1
Date: Tue, 25 Nov 2014 10:41:32 GMT
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Status: 400 Bad Request

13
start not specified
0

[Doug Beattie]

Ben and Ryan,

There have been a number of suggestions for wording updates to the Google CT policy which I think you've accepted.  When will there be an official update so the baseline is in one clean document?

I also recommend that we relax the "independent" requirement for the first six months until there are sufficient logs available and their production use has been fully validated.  Using 2 or 3 different logs should be considered "independent enough" for the debut of CT and we can then lock down the requirements in the summer of 2015 ater we've proven that the first set of logs can handle the production demands.

I'd also like Google to state their future (draft/preliminary) plans, even if there no firm dates for upcoming requirements.  The use of Stapling, Must staple, CT for DV/OV certs, CAA etc. and their value in improving the UI for Chrome users so the entire community can align with the dates and feature sets.  As an example, we could update our OCSP infrastructure to add stapling, but if browsers don't use OCSP for some/all certificate types, then it's a waste of engineering resources.  The same goes for filling up the logs with DV certs or implementing CAA.  We could do this, but understanding the Google plans regarding these new features would help motivate us and define an industry schedule/plan and build the applicable business case for the work.

Doug

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/54730CAA.6050707%40gmail.com.

[Ryan Sleevi]

On Tue, Nov 25, 2014 at 4:29 AM, Doug Beattie <douglas...@gmail.com> wrote:

Ben and Ryan,

There have been a number of suggestions for wording updates to the Google CT policy which I think you've accepted.  When will there be an official update so the baseline is in one clean document?

I also recommend that we relax the "independent" requirement for the first six months until there are sufficient logs available and their production use has been fully validated.  Using 2 or 3 different logs should be considered "independent enough" for the debut of CT and we can then lock down the requirements in the summer of 2015 ater we've proven that the first set of logs can handle the production demands.

This is still being discussed, as seen from this thread. I don't think we've reached a suitable conclusion regarding the independence requirement, as you can see above.

 

I'd also like Google to state their future (draft/preliminary) plans, even if there no firm dates for upcoming requirements.  The use of Stapling, Must staple, CT for DV/OV certs, CAA etc. and their value in improving the UI for Chrome users so the entire community can align with the dates and feature sets.  As an example, we could update our OCSP infrastructure to add stapling, but if browsers don't use OCSP for some/all certificate types, then it's a waste of engineering resources.  The same goes for filling up the logs with DV certs or implementing CAA.  We could do this, but understanding the Google plans regarding these new features would help motivate us and define an industry schedule/plan and build the applicable business case for the work.

Doug

Regarding these latter points (which aren't tied to CT), you can see I started a separate thread already on a more appropriate mailing list (security-dev@) - https://groups.google.com/a/chromium.org/d/msg/security-dev/jmbbIgmGbdk/xU8pR8fxYOYJ

To avoid forking that thread, I'll refrain from responding to the rest of your points (which aren't related to CT policy), other than I'd be happy to continue there.

[Michael Klieman]

Ryan, Ben just replied to my separate message where he confirmed that the independence requirement would be relaxed until April 1, 2015 (and he clarified that 3 SCTs are still needed for 2 year EV certs) -- and that EV certs logged per the above will continue to receive the green bar treatment in Chrome (absent any other security checks that impact the display).

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvZocPE8eJiW8fyj%2BqMC8k9TpzouQwG9999gmuzAOLY1Vw%40mail.gmail.com.

[Ryan Sleevi]

Michael,

Just to be clear, Ben's response was not a confirmation - especially as written. It was a clarification of what is being discussed.

When a chance to the policy is announced to this list, it will be quite clear that the policy has changed. Until then, the policy HAS NOT changed - it is merely being discussed.

I'm surprised you took Ben's response as a confirmation of policy changes, as it most certainly was not.

[Michael Klieman]

Ryan, when Ben responded, "we're relaxing the _indendepence_ requirement", I took that as a decision. Based on your response  it's unclear to me how, when, and by whom official decisions will be made regarding the CT policy. Can you clarify this.

[Ben Laurie]

On Tue Nov 25 2014 at 6:09:36 PM Michael Klieman <Michael...@symantec.com> wrote:

Ryan, when Ben responded, "we're relaxing the _indendepence_ requirement",

Apologies if I was unclear. I was discussing the proposed revisions.

 

I took that as a decision. Based on your response  it's unclear to me how, when, and by whom official decisions will be made regarding the CT policy. Can you clarify this.

As Ryan has said, when the policy is changed, we will announce that here and post the new policy to the website. It will not be an aside in an email thread. :-)

BTW, I am about (I hope) to post a final redlined version of the discussed changes.

[Matt Palmer]

Hi Rob,

Aha! Got it. Some new proxy configuration I added was playing silly
buggers with the query params. I've explained to it the error of its ways,
and made a note to improve my monitoring there so I'm the first one to
notice it in future.

Thanks for the clear example failure; it really helped me run the problem to
earth.

- Matt

> --
> You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
> To post to this group, send email to ct-p...@chromium.org.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/54745E0F.8000902%40gmail.com.

--
Java. The elegant simplicity of C++. The blazing speed of Smalltalk.
-- From http://c2.com/cgi/wiki?SmalltalkMinusMinus

[Rob Stradling]

Thanks Matt.  Works for me now.  :-)

[Rob Stradling]

Hi Matt.

My parser can't parse this precertificate entry:
wget "https://alpha.ctlogs.org/ct/v1/get-entries?start=201012&end=201012"

But it can parse precertificate entries from other logs, such as:
wget "https://ct.googleapis.com/pilot/ct/v1/get-entries?start=3905104&end=3905104"

It's late here and I'm a bit bleary-eyed, but IINM the problem is that the PrecertChainEntry.pre_certificate field is completely missing in "extra_data".

RFC6962 section 4.6 says...
         extra_data:  The base64-encoded unsigned data pertaining to the
            log entry.  In the case of an X509ChainEntry, this is the
            "certificate_chain".  In the case of a PrecertChainEntry,
            this is the whole "PrecertChainEntry".

But what I think you've implemented is this imaginary requirement: 'In the case of a PrecertChainEntry, this is the "precertificate_chain" '.

I hope this is just a cosmetic issue with get-entries!

[Matt Palmer]

Hi Rob,

You're probably right in your guess about how I've misread the spec. I'll
dig into it now, and let you know when I think I've got it nailed.

I'm less confident about the correctness of all the precert code, because
it's not well-exercised (or exercisable), and I can't fire test certs at
pilot/aviator to compare behaviour, because I'm not a CA. It wouldn't
surprise me if you manage to find other "misunderstandings" in the precert
handling code.

- Matt

> >>>To unsubscribe from this group and stop receiving emails from it, send an email toct-policy...@chromium.org.
> >>>To post to this group, send email toct-...@chromium.org.

> >>>To view this discussion on the web visithttps://groups.google.com/a/chromium.org/d/msgid/ct-policy/54745E0F.8000902%40gmail.com.
> >
>

--
I can only guess that the designer of the things had a major Toilet Duck
habit and had managed to score a couple of industrial-sized bottles of the
stuff the night before.
-- Tanuki

[Ben Laurie]

On Fri Dec 05 2014 at 12:22:58 AM Matt Palmer <mpa...@hezmatt.org> wrote:

Hi Rob,

You're probably right in your guess about how I've misread the spec.  I'll
dig into it now, and let you know when I think I've got it nailed.

I'm less confident about the correctness of all the precert code, because
it's not well-exercised (or exercisable), and I can't fire test certs at
pilot/aviator to compare behaviour, because I'm not a CA.

a) You could run a test instance of the open source log.

b) I think we'd be happy to include a test root from non-CAs in our test log.

 

> >>>To unsubscribe from this group and stop receiving emails from it, send an email toct-policy+unsubscribe@chromium.org.

> >>>To post to this group, send email toct-...@chromium.org.
> >>>To view this discussion on the web visithttps://groups.google.com/a/chromium.org/d/msgid/ct-policy/54745E0F.8000902%40gmail.com.
> >
>

--
I can only guess that the designer of the things had a major Toilet Duck
habit and had managed to score a couple of industrial-sized bottles of the
stuff the night before.
                -- Tanuki

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20141205002253.GF22403%40hezmatt.org.

[Matt Palmer]

Hi Rob,

I've made as much of a fix to alpha as I can -- unfortunately, due to the
way I was processing the requests, I can't reconstruct the precerts that
were submitted, meaning that the pre_certificate field of the
PrecertChainEntry will be empty (the field is still there, it's just
zero-length). Precerts submitted from now should be processed correctly.

- Matt

> >>>To unsubscribe from this group and stop receiving emails from it, send an email toct-policy...@chromium.org.
> >>>To post to this group, send email toct-...@chromium.org.

> >>>To view this discussion on the web visithttps://groups.google.com/a/chromium.org/d/msgid/ct-policy/54745E0F.8000902%40gmail.com.
> >
>

--
"After years of studying math and encountering surprising and
counterintuitive results, I came to accept that math is always reasonable,
by my intuition of what is reasonably is not always reasonable."
-- Steve VanDevender, ASR