<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Ryan,<br>
<br>
I share some (if not most) of the concerns clearly detailed by
Rick.<br>
<br>
The first proposition (certificate with 3 SCTs) for a certificate
to be CT qualified is obviously the best one if we want to see a
fast CT adoption, and thus get some quick benefit from CT. But it
also is the most scary on CA software. We're currently evaluating
how we can modify our software (luckily we have our own) with the
lowest security impact, but neither is completely satisfactory:<br>
<ul>
<li>2 certificates with the same serial number under the same CA
is absolutely out of question; the issuer+serialNumber unicity
is a strong requirement, nobody has ever asked for it to be
removed, Mozilla recently has asked CAs to check for this
unicity; we have additional security measures to ensure it</li>
<li>the pre-cert produced under a sub-CA may be a solution, but
it requires that the issuing CA is not constrained with a
pathLenConstraint=0 (unless you allow for a "nearly-sub-CA"),
and this constraint is also a protection for us (that way, an
online CA can't be asked to produce a CA cert)</li>
</ul>
<br>
The second proposition (SCT in stapled OCSP response) allows for a
shared responsibility between CAs and webservers, so while the
impact on CA software is lower (some work effort is to be done on
OCSP responders, fresh SCTs need to be regularly fetched), the
adoption might be lower due to need for server support. Hopefully
OCSPStapling is technically there, just not deployed.<br>
<br>
The third proposition (SCT in TLS extension) won't be seen soon.<br>
<br>
CT is a good idea. We don't have the same concerns about privacy
(or haven't encountered the need for it) as Symantec, so being
transparent and having some giant audit log is positive. It's not
technically finished, some details need more work; the
responsibilities/audit part hasn't been addressed at all.<br>
<br>
As Rick wrote it, I think CT is not yet ready to be mandated.<br>
<br>
<pre class="moz-signature" cols="72">--
Erwann ABALEA
</pre>
Le 24/09/2013 12:50, Ryan Sleevi a écrit :<br>
</div>
<blockquote
cite="mid:CACvaWvbGOT6gd9rJ=4UZNtoiaHfd7+pgwAz9=VZUYv=o01NK-g@mail.gmail.com"
type="cite">
<p dir="ltr">Indeed, as we finalize dates and implementation, a
corresponding policy update will follow.</p>
<p dir="ltr">At this time, we're soliciting feedback on the plans
regarding Certificate Transparency, and wanted to provide broad
notice to interested parties - in addition to individual efforts
to reach out to CAs that are EV enabled within Google Chrome.</p>
<p dir="ltr">Cheers,<br>
Ryan</p>
<div class="gmail_quote">On Sep 24, 2013 3:42 AM, "Rick Andrews"
<<a moz-do-not-send="true"
href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Ryan,<br>
<br>
Since not all CAs are members of the CA/Browser Forum, will
you be publishing this to a Chrome policy web site? I see <a
moz-do-not-send="true"
href="https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy"
target="_blank">https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy</a>;
I presume that's your policy page?<br>
<br>
-Rick<br>
<br>
> -----Original Message-----<br>
> From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>
> On Behalf Of Ryan Sleevi<br>
> Sent: Tuesday, September 24, 2013 3:09 AM<br>
> To: CABFPub<br>
> Subject: [cabfpub] Upcoming changes to Google Chrome's
certificate<br>
> handling<br>
><br>
> I'm writing this message to provide notice to members of
the<br>
> CA/Browser Forum about exciting changes we have planned
for future<br>
> releases of Google Chrome and Google Chrome OS, in
addition to the<br>
> Chromium projects these products are based upon, in the
hope of<br>
> minimizing any surprises or inconvenience these may
cause.<br>
><br>
> We look forward to continuing to work with members of the
CA/Browser<br>
> Forum to improve online security, and welcome feedback
regarding these<br>
> plans.<br>
><br>
> Regards,<br>
> Ryan Sleevi, Chris Palmer, Adam Langley, and Ben Laurie
on behalf of<br>
> the Google Chrome team<br>
><br>
><br>
> * Changes to Cryptographic Algorithm Minimum
Requirements:<br>
><br>
> As specified in Appendix A of the Baseline Requirements,
31 December<br>
> 2013 is the sunset period for the issuance of
certificates containing<br>
> RSA key sizes less than 2048 bits. Beginning in early
2014, Chrome<br>
> will begin warning users who attempt to access sites with
certificates<br>
> issued by publicly-trusted CAs, that meet the Baseline
Requirements'<br>
> effective date, and with key sizes smaller than those
specified in<br>
> Appendix A.<br>
><br>
> The anticipated logic is as follows:<br>
> - The end-entity certificate has a notBefore date after
the Effective<br>
> Date of 1 July 2012 of the Baseline Requirements<br>
> - AND the end-entity certificate has a notAfter date
after 31 December<br>
> 2013<br>
> - AND<br>
> - EITHER the end-entity certificate has a key size
weaker than those<br>
> specified in Appendix A (eg: RSA key that is less than
2048 bits)<br>
> - OR an intermediate certificate in the validated chain
has a key<br>
> size weaker than those specified in Appendix A (eg: an
RSA key that is<br>
> less than 2048 bits)<br>
><br>
> While we would like to extend this requirement to also
include root<br>
> certificates with sizes of less than 2048 bits,
unfortunately not all<br>
> Root Programs have been updated to remove 1024-bit root
certificates.<br>
> This exception for root certificates is temporary, and
all CAs must<br>
> immediately ensure that they are providing appropriately
strong root<br>
> certificates to Root Programs. Note that future versions
of Google<br>
> Chrome and Google Chrome OS MAY remove trust for root
certificates<br>
> with RSA keys less than 2048 bits, independent of
platform<br>
> configuration, as described at<br>
> <a moz-do-not-send="true"
href="http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-"
target="_blank">http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-</a><br>
> Removal-of-Trust<br>
> , so this should not be seen as a permanent exception.<br>
><br>
> While it would be ideal if this caused no issues for
users, our<br>
> current data suggests the enforcement of minimum key
sizes will impact<br>
> small percentage of sites - roughly, less than 0.1% of
sites surveyed<br>
> - due to CAs failing to adopt the technical requirements
of the<br>
> Baseline Requirements at the effective date. We want to
ensure that<br>
> CAs are aware of the upcoming changes and working with
their customers<br>
> to ensure that the CA is capable of passing a Baseline
Requirements<br>
> audit.<br>
><br>
> In addition, we anticipate applying these restrictions to
so called<br>
> 'legacy' certificates at a to-be-determined later date,
as part of the<br>
> natural sunsetting of weaker key sizes and algorithms. A
hard cut date<br>
> for such certificates has not yet been determined.<br>
><br>
> Note that these programmatic checks will also cover the
DSA and ECDSA<br>
> minimum size requirements, as also specified in Appendix
A, but our<br>
> data suggests this should cause no disruptions.<br>
><br>
><br>
> * Improving the Security of EV Certificates<br>
><br>
> All values in [] are TBD.<br>
><br>
> In order to improve the security of Extended Validation
(EV)<br>
> certificates, Google Chrome intends to require
Certificate<br>
> Transparency (CT) for all EV certificates issued after
[date TBD].<br>
><br>
> Once we have gained experience with EV certificates we
will publish a<br>
> plan to bring CT to all certificates.<br>
><br>
> We are soliciting feedback on the following plan.<br>
> - Google is already running a pilot CT log.<br>
> - By Dec 2013 Google will deploy three geographically
diverse<br>
> production CT logs which will accept all certificates
issued by CAs<br>
> accepted by any major browser (which are [Chrome,
Internet Explorer<br>
> versions [?], Safari, Firefox and Opera]).<br>
> - Google invites other organisations to deploy CT logs in
order to<br>
> improve robustness.<br>
> - On [date TBD] Chrome will begin providing CT status
information<br>
> through the UI.<br>
> - By [date TBD] all EV certificates with validity periods
beyond [date<br>
> TBD] should be logged in at least [one] qualifying log
(see below).<br>
> - On [date TBD] Chrome will create a whitelist of valid
EV<br>
> certificates already issued without an embedded SCT
[issued by CAs<br>
> participating in CT] from all qualifying logs.<br>
> - On [date TBD] Chrome will cease to show the EV
indicator for<br>
> certificates not in the whitelist and not CT qualified
according to<br>
> the criteria below.<br>
><br>
> Qualifying Logs<br>
><br>
> A log is qualified if its URL, public key and Maximum
Merge Delay<br>
> (MMD) are known to and accepted by Chrome.<br>
><br>
> Chrome will accept a log's URL, public and MMD key if<br>
> - The log has not been shown to have acted in bad faith.<br>
> - The log is run by an entity believed to be capable of
keeping the<br>
> log up at least [99.9%] of the time.<br>
> - The log has an MMD of no more than [24 hours].<br>
> - The log conforms to RFC 6962.<br>
><br>
> Qualifying Certificate<br>
><br>
> A certificate is CT qualified if the TLS handshake it is
presented in<br>
> satisfies at least one of<br>
> - [Three] or more SCTs from different qualifying logs [or
logs that<br>
> once were qualifying] [operated by distinct entities] are
embedded in<br>
> the certificate.<br>
> - [One] or more SCTs are embedded in a stapled OCSP
response as<br>
> specified in RFC 6962.<br>
> - [One] or more SCTs are sent via the RFC 6962 TLS
extension.<br>
><br>
> And at least one SCT for the certificate validates and
was issued by a<br>
> qualifying log.<br>
><br>
> Timeouts<br>
><br>
> Chrome will regularly synchronise its list of qualifying
logs with<br>
> Google's servers. If the last successful synchronisation
was more<br>
> than [10 weeks] ago, the client will [stop checking CT]
and [cease to<br>
> show EV indications].<br>
><br>
> Google will keep an authoritative list of qualifying logs
and post<br>
> changes to that list on the public CA/B Forum mailing
list.<br>
> _______________________________________________<br>
> Public mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>