[cabfpub] What is actually meant by "SHA-1-using certificates"?
N. Atilla Biler
atilla.biler at turktrust.com.tr
Tue Aug 26 05:27:47 MST 2014
Maybe an important point for Google to clarify at this moment is what is actually meant by "SHA-1-using certificates" in the following text under the link
“The following changes to Chromium's handling of SHA-1 are proposed:
- All SHA-1-using certificates that are valid AFTER 2017/1/1 are treated insecure, but without an interstitial. That is, they will receive a degraded UI indicator, but users will NOT be directed to click through an error page.
- Additionally, the mixed content blocker will be taught to treat these as mixed content, which WILL require a user action to interact with.
- All SHA-1-using certificates that are valid AFTER 2016/1/1 are treated as insecure, but without an interstitial. They will receive a degraded UI indicator, but will NOT be treated as mixed content.”
Meaning that “the certificates signed by SHA-1” is another thing, meaning that “the certificates signed by SHA-1 plus the certificates signed by SHA-2 but having SHA-1 roots or intermediate CAs in the chain” is another thing. And the second meaning even boosts the burden on the CAs.
A comment in one of Kirk’s mails (found below) says that “Starting with Chrome 39, in about 12 weeks (mid-November), when Chrome encounters an SSL certificate that is SHA-1, or a SHA-256 certificate with a SHA-1 intermediate in the chain, the user will see a deprecated security UI.”
However, in one of your comments under the chromium entry in the above link, you mention that “Only the leaf certificates notAfter is considered (and independent of leaf signature algorithm), but if it matches the criteria, then all the validated signatures in the chain (i.e. excluding the root) are considered. No new intermediates are required, unless you are issuing long-lived SHA-256 certs that chain to a SHA-1 intermediate.”
Could you please clarify this point for all the CAs in the Forum to prevent any misunderstandings at this point…
N. Atilla BILER
Business Development Manager
Address: Hollanda Cad. 696.Sok. No:7 Yildiz 06550 Cankaya / ANKARA - TURKEY
Phone : +90 (312) 439 10 00
Mobile : +90 (530) 314 24 05
Fax : +90 (312) 439 10 01
E-mail : <mailto:atilla.biler at turktrust.com.tr> atilla.biler at turktrust.com.tr
Web : <http://www.turktrust.com.tr/> www.turktrust.com.tr
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: 25 Ağustos 2014 Pazartesi 17:51
To: Dean Coclin
Subject: Re: [cabfpub] Agenda for Beijing F2F 16-18 September 2014
sudden -> recent
very little notice -> six months notice
I'm not sure that there is much to discuss, however, at least not within the Forum. Chromium has announced plans for UI changes that had previously been discussed at length in the Forum during our F2F in February. There is already a venue for discussing these changes, one which permits and encourages full public participation, and we welcome further contributions.
I suspect that such a conversation in the Forum, with or without Google's participation, would thus be nonproductive, unless the proposal is that we reexamine codifying these dates in the BRs, a move we would certainly welcome.
On Aug 25, 2014 7:13 AM, "Dean Coclin" <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:
I think another timely topic is Google’s sudden SHA-1 announcement. Although it appears no one from Google will be attending, perhaps we can schedule it at a time when they can dial in. It seems that this will have a huge customer impact with very little notice.
From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ] On Behalf Of Ben Wilson
Sent: Sunday, August 24, 2014 1:23 PM
To: CABFPub (public at cabforum.org <mailto:public at cabforum.org> ) (public at cabforum.org <mailto:public at cabforum.org> )
Subject: [cabfpub] Agenda for Beijing F2F 16-18 September 2014
Here is the agenda for our upcoming Face-to-Face Meeting in Beijing on 16 - 18 September 2014.
Please provide your feedback and comments.
Also, if you have a topic you’d like to discuss, the following open slots are available:
Slot 9 (30 min Wed p.m.)
Slot 12 (60 min Thurs a.m.)
Slot 14 (45 min Thurs p.m.)
Slot 15 (45 min Thurs p.m.)
Slot 16 (45 min Thurs p.m.)
WORKING GROUP MEETINGS –
(Tue) 16 Sept 2014
Welcome, Prelim Matters, Antitrust Statement, Logistics, Assign Note-Takers, etc.
Extended Validation Working Group Discussions
Open Items List to be Distributed
Code Signing Working Group Discussions
Review Comments received to
Public Comment Draft of Baselines for Code Signing
Certificate Policy Revisions Working Group Discussions
Review Computer and Network Security - Sections 6.5 to 6.7 of RFC 3647 and NISTIR
Continue CP Revisions Working Group Discussions
Adjourn for the Day
(Wed) 17 Sept 2014
Recap of Prelim Matters and Logistics
Antitrust Statement and Assign Note-Takers
Recap of Working Group Discussions (EV, Code Signing, and CP Security Review)
Apple, Google, Opera, Microsoft, Mozilla
Report from ETSI
Iñigo Barreira / Arno Fiedler
Report from WebTrust
Discussion of SM2 Algorithm
Discussion of Critical Extension to Technically Constrain SSL for Non-Browsers
Continuation of Discussion on Methods to Reduce Scope of Some of the Baseline Requirement Provisions (For Legacy Apps, IPSec, Non-Browser SSL)
Overview of Information Sharing - Why and How do We Share Information?
Functional Elements of a Solution, e.g. CABF Centre Database for Malware Signing Blacklist
Open Slot and Daily Wrap-Up
Adjourn for the Day
Social Event at Local Chinese Restaurant
(Thur) 18 June 2014
Preliminary Logistics and Assign Note Takers
Revisit Yesterday's Discussion on Information Sharing
Discuss Scope of CA/Browser Forum Work, Purpose, Bylaws, Project Lifecycle Revisions, Working Group Charters, Changes
Future Improvements to the Implementation of SSL/TLS
Placeholder to discuss communication / coordination among CAs and Browsers on Plans for Future Evolution of SSL/TLS
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org>
Gönderen: "kirk_hall at trendmicro.com <mailto:kirk_hall at trendmicro.com> " <kirk_hall at trendmicro.com <mailto:kirk_hall at trendmicro.com> >
Tarih:22 Ağu 2014 19:15
Konu: [Caution: Message contains Redirect URL content] [cabfpub] New Google policy on SHA-1 deprecation next 6-112 weeks
Alıcı: "CABFPub (public at cabforum.org <mailto:public at cabforum.org> )" <public at cabforum.org <mailto:public at cabforum.org> >
For those CA/Browser Forum members who were not on the Forum conference call yesterday, I wanted to forward information that Google disclosed during the call that will affect all CAs.
Google has announced a policy to deprecate many SHA-1 certificates and some SHA-256 certificated currently in use in the next 6-12 weeks (upon the release of Chrome version 39):
Here is how we understand this.
Starting with Chrome 39, in about 12 weeks (mid-November), when Chrome encounters an SSL certificate that is SHA-1, or a SHA-256 certificate with a SHA-1 intermediate in the chain, the user will see a deprecated security UI. Specifically:
* If the SSL cert expires after 1/1/2016 but before 2017, then the user will see a padlock with a red line though it (and no green bar for EV certificates) and the page will be served up as normal with no user action.
* If the SSL certificate expires after 1/1/2017, then the user will see the padlock with a red line through it, AND the page will be treated as mixed content and the user will need to perform an action to proceed.
* Again, this will affect all SHA-1 certificates and all SHA-256 certificates issued from a SHA-1 intermediate certificate, no matter when such certificates were issued or deployed.
* Per Google, SHA-1 roots can still be used, but all certificates in the chain must be SHA-256 to avoid the negative UI.
Google has told CAs that their affected customers have two choices over the next 6-12 weeks to avoid the negative UIs for their websites.
* Customers can replace their SHA-1 certs that expire in 2016 or 2017 with new SHA-1 certs that expire no later than 12/31/2015 (same for new SHA-256 certs issued from a SHA-1 intermediate), and they will get the regular UI trust symbols in Chrome, or
* Customers can replace their SHA-1 certs (or SHA-256 certs issued from a SHA-1 intermediate) with SHA-256 certs issued from SHA-256 intermediates, which can expire in 2016 or 2017 and will receive the regular UI trust symbols in Chrome.
Kirk R. Hall
Operations Director, Trust Services
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public