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."
--
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.
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.
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.
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.
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 15th. 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.
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.
--
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.
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...
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.
There really isn't any reason why more logs couldn't have been setup by interested parties.
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.
--
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.
> Although the exercise is purely academic until all certs are logged
I don't understand this. Why isn't it just a good thing?
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.
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
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.
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.
--
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.
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 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?
Current version: http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlan19Mar2014.pdf?attredirects=0I 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 IndependenceFor 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.
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.
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=0I 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 IndependenceFor 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?
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
> 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.
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?
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?
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.
> 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.
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 IndependenceFor 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.
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 IndependenceFor 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.
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.
-- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
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.
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.
On 24/11/14 10:32, Ben Laurie wrote:
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."
?
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.
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."
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. :-)
--
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.
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
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.
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.
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.
> >>>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.