Announcement: Requiring Certificate Transparency in 2017

[Ryan Sleevi]

This past week at the 39th meeting of the CA/Browser Forum, the Chrome team announced plans that publicly trusted website certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency policy in order to be trusted by Chrome. 

The Chrome Team believes that the Certificate Transparency ecosystem has advanced sufficiently that October 2017 is an achievable and realistic goal for this requirement.

This is a significant step forward in the online trust ecosystem. The investments made by CAs adopting CT, and Chrome requiring it in some cases, have already paid tremendous dividends in providing a more secure and trustworthy Internet. The use of Certificate Transparency has profoundly altered how browsers, site owners, and relying parties are able to detect and respond to misissuance, and importantly, gives new tools to mitigate the damage caused when a CA no longer complies with community expectations and browser programs.

While the benefits of CT are clear, we recognize that some CAs, browsers, or site operators may have use cases they feel are not fully addressed by Certificate Transparency, and so may have concerns over the October 2017 date. We encourage anyone who feels this way to bring their concerns to the IETF’s Public Notary Transparency WG (TRANS) so that these use cases can be discussed and cataloged. The information for this WG, and the documents it works on, is available at https://datatracker.ietf.org/wg/trans/charter/.

Although the date is a year away, we encourage any participants that wish to have their use cases addressed to bring them forward as soon as possible during the next three months. This will ensure that the IETF, the CA/Browser Forum, and the broader community at large have ample time to discuss the challenges that may be faced, and find appropriate solutions for them. Such solutions may be though technical changes via the IETF or via policy means such as through the CA/Browser Forum or individual browsers’ root program requirements.

We will continue outreach to CAs in trust stores used by Chrome to ensure that they are prepared and that there is minimal user disruption.

To further support these investments in Certificate Transparency, the Chrome team will be discussing a proposed new HTTP header at next month’s IETF meeting that would allow sites to opt-in to having CT requirements enforced in advance of this deadline.

Similarly, we welcome and encourage all CAs to voluntarily request that browsers enforce CT logging of their new certificates before this deadline. Doing so enhances CT's ability to protect users, detect misissuance, and in the unfortunate event that misissuance does occur, to confirm the scope of misissuance. This may allow browsers to take more targeted steps to remediate the problem than otherwise possible, thus minimizing any negative impact to their users.

[Doug Beattie (Globalsign)]

Ryan,

When will Google be updating the CT policy (May 2016) to include this update?  The policy remains somewhat EV centric and does not state chrome treatment of non EV certificates that are not compliant (and I assume EV certificate treatment will change from not showing the green bar to not being trusted in October).

Also, can name constrained CAs with the applicable number of SCTs (5?) enable the SSL certificates to be treated as compliant when they don't contain any SCTs per RFC 6962-biz?  If so, then the definition of "CT Qualified" should be expanded to cover this case.

Even though this might be a bit early (since there are ongoing discussion of RFC 6962-biz and CAs are being solicited for their input), having the currently proposed CT policy clearly stated would help us understand the baseline and provide more meaningful comments.

Doug

[Ryan Sleevi]

On Oct 26, 2016 5:26 AM, "Doug Beattie (Globalsign)" <douglas...@gmail.com> wrote:
>
> Ryan,
>
> When will Google be updating the CT policy (May 2016) to include this update?  The policy remains somewhat EV centric and does not state chrome treatment of non EV certificates that are not compliant (and I assume EV certificate treatment will change from not showing the green bar to not being trusted in October).
>

Hi Doug,

Perhaps you're thinking of a different version? The policy very much defines what is CT Qualified, and does not treat EV as the only form of CT Qualified.

That is, I do not believe any policy uodate is needed, because we are not changing the definition or acceptance criteria of the existing term.

> Also, can name constrained CAs with the applicable number of SCTs (5?) enable the SSL certificates to be treated as compliant when they don't contain any SCTs per RFC 6962-biz?  If so, then the definition of "CT Qualified" should be expanded to cover this case.

No. That is not part of RFC6962 and, as mentioned in the F2F discussions on redaction - and the IETF - not something in 6962-bis that we believe is required to be supported.

>
> Even though this might be a bit early (since there are ongoing discussion of RFC 6962-biz and CAs are being solicited for their input), having the currently proposed CT policy clearly stated would help us understand the baseline and provide more meaningful comments.

I believe it already is clearly specified, but would happy to understand your concerns further. Could you re-read and perhaps point out specific areas you feel are unclear? Certainly, if it is not listed, it is not supported - and that is not accidental.

[Ryan Sleevi]

Somehow ct-policy got lost

On Wed, Oct 26, 2016 at 2:18 PM, Doug Beattie <douglas...@gmail.com> wrote:

On Wed, Oct 26, 2016 at 11:01 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

Hi Doug,

Perhaps you're thinking of a different version? The policy very much defines what is CT Qualified, and does not treat EV as the only form of CT Qualified.

That is, I do not believe any policy uodate is needed, because we are not changing the definition or acceptance criteria of the existing term.

Chrome's current policy only provides a clear statement of penalties for EV (no green banner) and does not amend/change that with a statement that all non-compliant certificates will not be trusted, as of October, 2017.  In order to understand the full policy, people will need to merge your statement in this thread into the Chrome CT policy to get the full picture.  I'd suggest adding an item 5 to your list: As of <date> Google will not trust SSL certificates that are not CT qualified in accordance with the criteria below.

Nit-pick: The footnote and the "Important Note" both imply something special about EV certificates or that this policy applies only to EV certificates.  I'd recommend deleting them.

> Also, can name constrained CAs with the applicable number of SCTs (5?) enable the SSL certificates to be treated as compliant when they don't contain any SCTs per RFC 6962-biz?  If so, then the definition of "CT Qualified" should be expanded to cover this case.

No. That is not part of RFC6962 and, as mentioned in the F2F discussions on redaction - and the IETF - not something in 6962-bis that we believe is required to be supported.

Your statement at the F2F about name redaction was clear, plus since it does not exist in the latest version of the RFC it's abundantly clear redaction is not supported - period (and discussion of that can take place on the trans list).  

The use of the intermediate CA certificate is supported in the RFC, section 4.2 (unless it's been removed since the -19 version), and is not called out in the Google Policy.  Since this is new in the -bis version, I wanted to understand if it would be supported within the Google CT policy as of October 2017 (will there even be 6962-bis compliant logs by then? this might be a non-question).  Name constrained CAs don't need to be disclosed so they already have a reduced reporting requirement.  It seems reasonable to  me that we can permit them to be posted in a sufficient number of CT logs and used in lieu of including SCTs in the issued certificates.  Either you post/disclose the CA which would not normally be required, or don't disclose the CA and post all issued certificates.  I apologize if the rational was provide at the F2F and this is a repeat.

>
> Even though this might be a bit early (since there are ongoing discussion of RFC 6962-biz and CAs are being solicited for their input), having the currently proposed CT policy clearly stated would help us understand the baseline and provide more meaningful comments.

I believe it already is clearly specified, but would happy to understand your concerns further. Could you re-read and perhaps point out specific areas you feel are unclear? Certainly, if it is not listed, it is not supported - and that is not accidental.

As listed above, I think an item 5 would help so that the policy specifically says that SSL certificates not compliant with the CT Policy will not be trusted by Chrome as of October 2017.  A foot note indicating that name constrained Intermediate CA certificates cannot be posted in lieu of the SSL certificates would also help clarify the policy (if that is the Google policy). I don't expect you to enumerate all items in the rfc that you don't support, but this is one that is central to the policy.

[Ryan Sleevi]

On Wed, Oct 26, 2016 at 3:34 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Wed, Oct 26, 2016 at 2:18 PM, Doug Beattie <douglas...@gmail.com> wrote:

Chrome's current policy only provides a clear statement of penalties for EV (no green banner) and does not amend/change that with a statement that all non-compliant certificates will not be trusted, as of October, 2017.  In order to understand the full policy, people will need to merge your statement in this thread into the Chrome CT policy to get the full picture.  I'd suggest adding an item 5 to your list: As of <date> Google will not trust SSL certificates that are not CT qualified in accordance with the criteria below.

Hi Doug,

It's actually rather different. Our goal with the CT Policy document is to clearly document what constitutes CT Qualified, as introduced in the first sentence. The two subsequent paragraphs further explain places where CT Qualified might be used, but we explicitly and intentionally wanted to decouple the documentation of what is CT Qualified from any policies related to expectations of CT Qualification. That is, it's structured this way precisely to provide clear and unambiguous guidance about what constitutes an appropriately disclosed certificate.

Indeed, I think we'll update the policy to remove the description of the implementation, which is out of date, and that may hopefully resolve that initial concern.

 

Your statement at the F2F about name redaction was clear, plus since it does not exist in the latest version of the RFC it's abundantly clear redaction is not supported - period (and discussion of that can take place on the trans list).  

The use of the intermediate CA certificate is supported in the RFC, section 4.2 (unless it's been removed since the -19 version), and is not called out in the Google Policy.  Since this is new in the -bis version, I wanted to understand if it would be supported within the Google CT policy as of October 2017 (will there even be 6962-bis compliant logs by then? this might be a non-question). 

It hasn't been removed, but please see the discussion at https://mailarchive.ietf.org/arch/msg/trans/z4n6tFE5sq3s1KR79mfm1VIN8zE

As far as policy, you should be operating under the assumption that the current policy, as written - which uses 6962 - is the policy that will be in place in October 2017. That's not to say there won't or can't be changes, merely that you should not operate on any assumptions that it will be any different than what's explicitly stated.

 

Name constrained CAs don't need to be disclosed so they already have a reduced reporting requirement. 

That's with respect to Mozilla requirements.

 

It seems reasonable to  me that we can permit them to be posted in a sufficient number of CT logs and used in lieu of including SCTs in the issued certificates.  Either you post/disclose the CA which would not normally be required, or don't disclose the CA and post all issued certificates.  I apologize if the rational was provide at the F2F and this is a repeat.

Right, this is not something that, at present, we think is a good thing :)

 

As listed above, I think an item 5 would help so that the policy specifically says that SSL certificates not compliant with the CT Policy will not be trusted by Chrome as of October 2017.  A foot note indicating that name constrained Intermediate CA certificates cannot be posted in lieu of the SSL certificates would also help clarify the policy (if that is the Google policy). I don't expect you to enumerate all items in the rfc that you don't support, but this is one that is central to the policy.

Well, I would hope that the absence of support for name-constrained would be inferred given that only RFC 6962 is supported. If and when 6962-bis is supported, I certainly agree, it'd be useful to enumerate what parts, if any, of 6962-bis are supported.

I anticipate that we'd remove the places in the policy where the CT implementation is documented, precisely because our implementation continues to mature, and I wouldn't want to do a policy document update every time - as what matters is the policy.

If we did that - remove the discussion of implementation - would that help or hinder? It sounds like you're ideally looking for a document about what cases CT support is required - e.g. for EV, for Symantec, and for CNNIC, and, in the future, for all certs.

I do note this is slightly different than how we handled/announced EV (which coupled the statements in the policy document), but it was precisely because of those experiences we were trying to avoid that for this announcement. 

[Doug Beattie]

On Wed, Oct 26, 2016 at 6:35 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Wed, Oct 26, 2016 at 3:34 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

As far as policy, you should be operating under the assumption that the current policy, as written - which uses 6962 - is the policy that will be in place in October 2017. That's not to say there won't or can't be changes, merely that you should not operate on any assumptions that it will be any different than what's explicitly stated.

This clarification helps, thanks.

 

As listed above, I think an item 5 would help so that the policy specifically says that SSL certificates not compliant with the CT Policy will not be trusted by Chrome as of October 2017.  A foot note indicating that name constrained Intermediate CA certificates cannot be posted in lieu of the SSL certificates would also help clarify the policy (if that is the Google policy). I don't expect you to enumerate all items in the rfc that you don't support, but this is one that is central to the policy.

Well, I would hope that the absence of support for name-constrained would be inferred given that only RFC 6962 is supported. If and when 6962-bis is supported, I certainly agree, it'd be useful to enumerate what parts, if any, of 6962-bis are supported.

I anticipate that we'd remove the places in the policy where the CT implementation is documented, precisely because our implementation continues to mature, and I wouldn't want to do a policy document update every time - as what matters is the policy.

The policy is important, but the implementation is also important.  Depending on the implementation, CAs and/or their customers can make an educated decision about whether or not they want CT Qualified certificates.  Not showing the Green EV banner is a relatively small penalty for some customers while not trusting the certificate is much more severe.  Will there be a centralized place that describes the Chrome CT implementation that we will be able to convey to our customers for this purpose (without needing to track the latest status in multiple discussions or the chrome change log)?  I had been assuming this would be included in the Policy document (it was for EV).

[Ryan Sleevi]

On Thu, Oct 27, 2016 at 6:09 AM, Doug Beattie <douglas...@gmail.com> wrote:

Will there be a centralized place that describes the Chrome CT implementation that we will be able to convey to our customers for this purpose (without needing to track the latest status in multiple discussions or the chrome change log)?  I had been assuming this would be included in the Policy document (it was for EV).

The way EV was handled was rather exceptional, rather than the norm, which is why I've been hoping and trying to avoid repeating that.

For example, UI changes are not always communicated in advance, or they're communicated in conjunction with the release. That's not to say they always have to, just that the EV handling was rather unique on many fronts.

It sounds like your goal is not so much to have the implementation itself documented, so much as to have a path to communicate to your customers that Chrome is making these changes. Is that a fair summary of your concern?  If so, why does or does not this post suffice?

[Bruce Morton]

Ryan,

Will the Google CT policy allow certificates not to be CT logged? My assumption is that non-CT logging is not forbidden, however, the certificate will not be trusted by Chrome. My goal is to create a list of options for a certificate subscriber and understand the consequences.

Thanks, Bruce.

[Ryan Sleevi]

Hi Bruce,

That's correct. Certificates newly issued from publicly-trusted roots that are not logged will not be trusted by default.

For certificates that are not logged (or not logged in a manner compliant with the "CT Qualified" definition), options are:

- Migrate to a private trust anchor (managed by the CA or the enterprise; arguably, managed by the CA may be more secure)

- Utilize existing enterprise configuration features (Group Policy/Cloud Policy/Managed Preferences) to disable CT enforcement for specific URLs - https://www.chromium.org/administrators/policy-list-3#CertificateTransparencyEnforcementDisabledForUrls

As indicated in this post, if there are concrete reasons for non-logging, we'd love to discuss the use case within the IETF, to ensure it's considered as an input into the RFC 6962-bis finalization. If you/your customers aren't able to bring that feedback to the IETF, then we won't be able to ensure it's considered before launch.

--
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/539ee1fb-5827-4091-bd45-77bb4529ccd4%40chromium.org.

[Bruce Morton]

I want to define domain name privacy options if the certificates were issued from a publicly-trusted root, which would be:

a) Do not log

b) Log, but use wildcard certificate

c) Log, but use a certificate issued from a name contrained CA

For clarity can option a) be used with "Utilize existing enterprise configurations features to disable CT enforcement for specific URLs." I assume this would mean that Chrome in the enterprise would trust a non-CT logged certificate, which was issued from a publicly-trusted root.

Thanks again, Bruce.

On Monday, October 31, 2016 at 2:55:34 PM UTC-4, Ryan Sleevi wrote:

[Ryan Sleevi]

On Mon, Oct 31, 2016 at 12:21 PM, Bruce Morton <bruce....@entrust.com> wrote:

I want to define domain name privacy options if the certificates were issued from a publicly-trusted root, which would be:

a) Do not log

b) Log, but use wildcard certificate

c) Log, but use a certificate issued from a name contrained CA

For clarity can option a) be used with "Utilize existing enterprise configurations features to disable CT enforcement for specific URLs." I assume this would mean that Chrome in the enterprise would trust a non-CT logged certificate, which was issued from a publicly-trusted root.

Correct, if Chrome was running on an enterprise-owned device, and that enterprise used existing enterprise management tools to push that policy, then on those devices, Chrome would continue to trust that certificate, despite not complying with the policy.

Note that Option C is not compliant with Chrome's definition of CT Qualified. So it's indistinguishable from a) 

[Bruce Morton]

My definition was wrong, so I am not sure if this changes your reply. It should have said:

c) Log a name constrained CA intermediate certificate and issue certificates from this intermediate

Bruce.

[Peter Bowen]

On Mon, Oct 31, 2016 at 12:47 PM, Bruce Morton <bruce....@entrust.com> wrote:
> My definition was wrong, so I am not sure if this changes your reply. It
> should have said:
> c) Log a name constrained CA intermediate certificate and issue certificates
> from this intermediate

Chrome has made it clear that they, at this point, do not consider
that compliant with the Chrome CT policy. The end-entity certificates
are not logged in full so they will not be treated as validly logged.

Ryan has asked that use cases for allowing such privacy measures be
submitted to the IETF TRANS working group. As I understand it, the
process Chrome is asking CAs to follow is to first submit customer
requirements (not just "not disclosing the full FQDN" but why the
customer doesn't want the FQDN disclosed) then Chrome will evaluate
those use cases and see if they are deemed to be acceptable. If so,
they will consider technical solutions to solve the use case.

We discussed some use cases at the CA/Browser Forum meeting in Redmond
a few weeks ago, which I subsequently posted to the TRANS WG list.
There has been little discussion since, so I emailed the WG chairs
this morning asking if they viewed such discussion as in-scope for the
WG or if they want to just have the WG do the technical design.
Depending on the response, we can determine the correct venue to the
use-case discussion Chrome wants to have.

Thanks,
Peter