[cabfpub] Google decision to impose a negative UI for SHA-1 certificates in 6-12 weeks

Ryan Sleevi sleevi at google.com
Mon Aug 25 15:55:47 MST 2014

Happy to continue discussing this in the proper forum, which, as has been
noted in the past, is

In which the relevant bits for the minutes were already provided.

On Mon, Aug 25, 2014 at 3:46 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>   Ryan, you have indicated in a couple of emails that Google warned CAs
> six months ago about its plans for SHA-1.  I assume you mean at the
> CA/Browser Forum meeting at Google’s office in February?  If so, I have
> pasted in the minutes below – it’s not clear to me from these minutes that
> Google was going to require users with SHA-1 certificates expiring after
> 2015 to replace those certs in 2014 or have a negative UI in Google.
> The Minutes from the meeting speak for themselves, but my general
> recollection of the discussion is as follows.
> ·         Everyone acknowledged that Microsoft was dropping support for
> SHA-1 as of January 1, 2017 (and no new SHA-1 certs could be issued
> starting Jan. 1, 2016 to help prepare for this change), but Microsoft said
> it might move the date forward or backward, depending on circumstances.
> Everyone was in support of eliminating SHA-1.
> ·         We discussed putting a sunset date for SHA-1 in the Baseline
> Requirements, but  given that Microsoft said it might change the sunset
> date, it made little sense to fix a date in the BRs that could then be
> changed based on Microsoft’s future decisions.
> ·         Google indicated it also supported SHA-1 phase-out.
> ·         We then discussed different ways to notify users and complete
> the transition of all sites to SHA-2 (or better) by the start of 2017.
> My company, Trend Micro, only issues one- and two-year certs, and we have
> already modified our systems so that no customer can get a SHA-1
> certificate that expires after Dec. 31, 2016.  So we don’t need any help in
> getting all our customers to SHA-2 by 2017.  But Google’s new policy means
> we now have to move a large group of our customers to new one-year SHA-1
> certs (or SHA-2 certs for those customers whose systems can work with
> SHA-2) over the next 6-12 weeks, which was totally unexpected and in the
> case of our customers serves no real purpose.
>  You have mentioned that Google is trying to avoid a “flag day” on
> January 1, 2017 – a worthy goal, but that was never going to happen for any
> of our customers.  By forcing most SSL certificate customers to change out
> all their SHA-1 certs in the next 6-12 weeks, Google is more or less
> creating a “flag day” in the next 6-12 weeks, for relatively little benefit.
> *Wouldn’t it make more sense for Google to impose its rules in a later
> Chrome release (after Chrome 39) – such as six months from now – to avoid
> this upcoming flag day*?  Google can apply its policy of showing a
> negative UI for SHA-1 certs that expire in 2016 and 2017 (so Google will
> accomplish its stated goals of making users start the change soon, and not
> wait until the end of 2016), but will be giving users more time to adjust.
> Please understand that CAs have virtually no trouble in issuing /
> reissuing short term SHA-1 certs and new SHA-2 certs to their customers, so
> by pushing out the date of Google’s new policy by six months Google would
> not be doing CAs a favor.  However, no matter how hard CAs try to tell
> customers what’s coming from Google in the next few weeks, not all
> customers will be able to respond in Google’s preferred time frame.  What’s
> the harm in moving this flag day out a few months so users have more time
> to react?
> Here are the minutes from the February Forum meeting:
>  Wednesday, 19 February 2014 Browser News
> *Mozilla (Brian Smith):*
> 1. Working on changing to new cert verification library for FF30 which
> will be released in 16 weeks “Path bldg. for cert chains in a more
> sensible way”. Helps increase compatibility and will allow them to add new
> features in certs like CT.
> 2. Half way done in implementing “must staple” extension. Working to
> revise Phil Baker’s IETF draft and getting it published. Overall goal:
> make OCSP staple secure. This will help promote OCSP stapling as a good
> solution against key compromise. OCSP fetching discussion going on now.
> 7% of handshakes use OCSP stapling. Would like to increase to 100%.
> 3. The new path building logic will be an option in FF29. They will
> recommend that each CA test against their own certs
> 4. FF29 to remove most or all of 1024 bit roots. CA’s need to get back to
> Mozilla with any significant impact CAs that have legacy roots that have
> been cross signed would be affected. Mozilla will accept requests from CAs
> to build in intermediates into Mozilla if that will help prevent many web
> sites from breaking (contact Brian).
> 5. Timeline for FF29: April 29th (remove 1024 roots and new path building
> code optional). FF30: June 10th (new path building code enabled for all)
> 6. No decision made yet on SHA-1 deprecation. Awaiting feedback from CAs
> on MSFT proposal.
> *Google Chrome (Ryan Sleevi)*
> 1. Transitioning away from NSS to OpenSSL stack except on Windows and
> Android. Win will continue with Crypto API Effect on moving to
> OpenSSL-parsing rules. No special UI for bridge certs but will support them.
> 2. Looking at programmatic enforcement of BRs
> 3. CT reqt to be discussed later
> 4. Chrome does not support internal server names from public roots (this
> has been true for some time now). Will not show lock.
> *Microsoft (Tom Albertson)*
> 1. SHA-1 announcement published ***
> *SHA1 Sunsetting / Grandfathering Strategy*
> Ben: We should work on a path forward to make sure everyone is aware of
> the current plan to eliminate SHA-1. We might want to see if there is a way
> to allow exceptions for an initial grandfather period, along with the
> sunset period when everything gets turned off, because there are likely to
> be some that will object to a hard deadline.
> Tom: Removal of roots may have some affect.
> Richard: Four million users in China are relying on Windows XP, SP2, which
> cannot use SHA2.
> Brian: If browsers enforced SHA2, then end users would stop approaching
> CAs asking for SHA1 certificates.
> When large, popular websites start using SHA2, then everyone will want to
> upgrade their browsers.
> Brian: With TLS 1.2, the client can send the server a list of algorithms
> it supports, and maybe we could get server vendors to start adding an
> ability to select SHA1 vs. SHA2 based on what the TLS 1.2 client sends,
> like what has been done for EC certificates vs. RSA certificates. This
> might work with markets with localized issues like China and Japan. Also,
> large ecommerce sites have economies of scale to create customized code to
> serve SHA1 to SHA1 clients and SHA2 to SHA2 clients, so maybe we should
> make them aware of this possibility. They would be willing to do more work
> than the general population of server administrators.
> Robin: We cannot, however, partition the Internet into different zones -
> SHA1 vs. SHA2.
> Dean: How does this work on the browser side?
> Brian: In Firefox, the user gets a warning that says, “we cannot verify
> that this was issued by a trusted issuer.” Then we let users click through
> it – we basically treat it as an invalid signature.
> Dean: What about Chrome?
> Ryan: You will get an invalid certificate, based on whether it uses
> CryptoAPI. Whether it is over-rideable depends on whether it is an invalid
> server certificate, then no, but if it is an untrusted server certificate,
> then yes, it is over-rideable.
> Dean: What about Internet Explorer?
> Tom: You will not be able to have an https connection.
> Ben: Regardless of whether all of the browsers implement SHA1 sunsetting,
> there will still be users who do not upgrade their browsers, so the issue
> is how do we gracefully transition, because regardless of the cutoff date,
> there will be a tail that follows after that date. We should be looking for
> statistics – who has moved, why haven’t people moved to SHA2, etc., and
> based on that we could see whether any grandfathering rule makes sense,
> because no CA wants to violate a rule.
> Chris: As a general rule, we seem to have a double sunset. We take a date
> to our customers, and they start to implement it. Then our customers come
> back to us with news about their problems, or their customers’ problems.
> And then through an organic process we come up with a grandfather policy.
> Wayne: I wonder if we should be setting deadlines at this point. Microsoft
> has a date and a time next year at which to re-evaluate the policy, and
> then we have our users and a security policy we’re trying to implement
> without breaking things, so that is when we should evaluate between
> breaking things and the sunset.
> Brian: If we wait too long, then we’ll have some CAs who have the
> situation under control and those that don’t. Then, if things change, those
> CAs who have handled the transition responsibly will feel they are being
> treated unfairly. For instance, a CA issuing a certificate without OCSP
> could sell certificates more cheaply in violation of the rules. By June
> 2015, we need to be able to say that we have identified all of the
> potential issues.
> Chris: We need to have a process for future migrations. So, if Microsoft
> says, “we need to move over to this specification, but until customers
> begin to feel the pain, we don’t know what all of the issues are. Then,
> when they complain, we give them a temporary, 1-year reprieve while a
> better solution is developed.
> Brian: We should definitely consider shortening the lifetimes of SHA1
> certificates—they shouldn’t be longer than a year. So, we need to put into
> the Baseline Requirements a maximum lifetime for a certificate with a SHA1
> signature.
> Bob: We’re trying to reduce our risk, because we want to reduce the number
> of certificates with SHA1 and the negative impact that will occur when it
> is known that SHA1 is insecure.
> Richard: We should issue the user two certificates. That way, at the
> appropriate time, the user can just switch over from their SHA1 certificate
> to their SHA2 certificate.
> Rick: I like that idea, and we’re also considering that approach. It’s
> easier for us and for the customer, so we’d prefer that strategy rather
> than shortening lifetime.
> Bob: We need to have the customer experience pain with a SHA1 certificate,
> or it won’t work.
> Brian: What is the problem with limiting SHA1 to one year?
> Rick: We have a number of platforms for selling certificates, and let’s
> say a customer buys a three-year certificate, and we deliver a SHA2
> certificate, and they tell us that a SHA2 certificate doesn’t work. It’s
> much easier just to say, here are your two certificates. There is no longer
> a need to refund because we’ve at least given them what they’ll need over
> that three-year period.
> Brian: It still doesn’t make sense to be selling and giving customers
> something that you know will not work two years from now.
> Rick: If Microsoft re-evaluates in June 2015, it could push the date out.
> Tom: It is most likely that the date will stay right where it is.
> Rick: It is possible, so that’s why.
> Tom: It’s not really a date that we’re going to be looking at the
> fragility of SHA1. Because we know SHA1 is already fragile. We are looking
> at the actual exposure to customers. We are trying to figure out who gets
> harmed by using SHA1. Right now, we don’t see enough harm to justify
> pushing out the date. I recommend getting your customers started on SHA2
> now, that way, it will reduce your refunds.
> Rick: We are pushing SHA2.
> Brian: What do you think about my idea that changing server software to
> recognize that the server supports SHA2 and then serving up one certificate
> or another based on that?
> Tom: Anything we can do to promote SHA2 is a good thing, like TLS 1.2.
> Ryan Sleevi: It’s tricky. It requires action by both people on the server
> side and client side. With Chrome, we’ve seen some issues. For instance
> with ECDSA certificates, on OSX 8 verification of certificates was broken
> but TLS worked, so you have to engage in snipping to try and figure out
> what is going on. Is the TLS handshake issue coming from a Safari
> configuration or from Chrome? And there are other issues with certificate
> verification and relying on the OS. It goes back to attempting what we
> believe is a balanced approach for the user experience by telling the user
> that we don’t have full confidence in this site but allowing the user to
> proceed, but this may become more serious over time. So we’ll transition
> the user by not giving an EV indication. We’re also not going to require
> users to click through warnings.
> Brian: I can understand the ECC issue because Chrome has to support
> Windows XP that doesn’t have ECC, but as far as I know, Chrome doesn’t run
> on any platform that doesn’t support SHA2. So, when you’re running on SP 2,
> what do you do with the supported signature algorithms field of the TLS
> handshake for TLS 1.2?
> Ryan: Probably the wrong thing. [image: Description: :-)]
> Brian: Presumably, you could fix that, too.
> Ryan: Yes, we can, and we hope to resolve that in TLS 1.3, although
> supporting TLS 1.2 has been messy enough.
> Ben: Assuming the Microsoft date is not going to change, can we take that
> as a given and work around the variables that we can change and identify
> what is not going to change?
> Kirk: As Chris noted, there are two sunsets--the stated one and the panic
> one. The one thing to think about is whether Microsoft is really going to
> just turn SHA1 off so it doesn’t work. The sunset is January 2017. We could
> say that we couldn’t sell any SHA1 cert after July1 of the previous year so
> people try to get into panic mode and then give them 30-day certificates.
> Ryan: We have had discussions with cryptographers about this, “oh crap,
> panic mode” and probable collisions and without giving CAs false hope,
> there might be things that browsers could do to pre-identify potential
> collisions based on certain characteristics and that might provide a little
> bit more of a transition phase. We might be able to look at those in SHA1
> and block those certificates.
> Ben: Whatever we do should not allow customers or other CAs wiggle out by
> not having to do it. It should be above board and strict and
> programmatically enforced, and just start people toward that pain point
> without CAs having to be the police on it, because there would be chances
> of undercutting it.
> Wayne: What I’ve heard here today has changed my opinion, instead of
> assuming that all CAs are smart enough not to issue SHA1 certificates that
> expire after January 1, 2017, we should have a policy that says starting
> January 1, 2015, you’re not allowed to issue a certificate with a SHA1
> algorithm that expires after January 1, 2017. When I read Microsoft policy,
> that’s what I get, but that’s not really what it says. Maybe that is a way
> to move it forward.
> Brian: That’s almost exactly what I recommended that Firefox do, except I
> said 2014. I don’t see why we should keep accepting certificates after
> there has been time for CAs to adjust, that have a validity period that
> ends after January 1, 2017. If CAs say they need 6 months, to implement
> some changes before they are ready to do that, then that type of policy is
> very reasonable, not just for CA/B Forum to put in the BRs, but for
> browsers to start enforcing that on January 1, 2015.
> Doug: I prefer to not set a certain date because when you’re selling
> certificates, it is hard to set the price for an 18-month or 20-month
> certificate. I think that we set maximum validity periods on certain dates.
> For instance, say April 2014 is a 2-year max validity SHA1 certificate, but
> not an end date—it’s easier to program for a 2-year or a 1-year certificate.
> Wayne: My interpretation the way I hear what you are saying is after
> January 1, 2015, with my system is that I will no longer be able to sell a
> SHA1 Certificate to a customer for more than 1 year. But at the same time,
> other CAs might have different systems, but they are stuck with that.
> Brian: I understand what you’re saying.
> Chris: There’s a pro and con to what you’re saying, we want to be careful,
> but we can actually communicate this to our customers all at the same time
> in terms of policy. We could just pick a hard date.
> Brian: It makes a lot of sense for the software developers to look at the
> cryptographic concerns that have been raised and determine that based on
> these concerns, as far as securing our products goes, we stop accepting
> these certificates after this date, based on what we know, and create some
> kind of document for it. IETF is already working on that anyway, and then
> say, here is an open standard that we are going to implement. For CAs
> selling certificates to customers, then you have an open, public
> recommendation that you can point people to. Put the blame on the software
> companies.
> Rick: I agree with Doug and I disagree with Wayne. We can tell customers
> that we can sell them a SHA1 certificate that goes beyond January 1, 2017,
> but on that date your Windows box will stop trusting it. We are already
> giving that warning to customers, so it is superfluous to tell customers
> also that before then the browsers will stop trusting it. There is already
> a built in sunset date. I’d like to have the flexibility to issue beyond
> that date with the understanding that I’ll communicate with my customers.
> It just makes it a lot easier to comply.
> Ryan: It is possible that the certificate will work well beyond the sunset
> date if they are not on a system with Windows update.
> Kirk: What about a requirement that you tell a customer if you sell them a
> SHA1 certificate with an expiration date beyond 2017 it probably will not
> work on a certain applications? That sounds like it would cover what
> Symantec is already doing and it should reduce the number of customer
> support calls if we give that notice.
> Ben: What if with that motion we included some type of endorsement or
> recognition of Microsoft’s date? Then we’re self-regulating without having
> to enforce a requirement.
> Ryan: We’ve seen examples in the Forum of exceptions, but here we have an
> opportunity to work with root programs and state what has been determined
> as best practice. This could be folded into audit requirements and if you
> can’t meet the requirement then you can work with the root program for
> additional time in which to comply.
> Bob: CAs should not be selling three-year SHA1 certificates at this point.
> We shouldn’t leave a policy that allows CAs to pre-sell SHA1 certificates.
> Dean: It’s not because we are trying to sell SHA1 certificates, it is that
> customers want to buy them. Customers want to buy three-year certificates;
> they do not want to buy one-year certificates.
> Bob: The point is that you have to stop selling three-year SHA1
> certificates.
> Doug: Not necessarily. They can get a replacement certificate for free,
> only it’s a SHA2. At their leisure, they can upgrade to a SHA256.
> Rick: Clearly, after January 1, 2017, we cannot sell a SHA1 certificate of
> any duration. Our current path is best. We sell them a three-year SHA2
> certificate. If they come back and say they need a SHA1 certificate, we
> give them a three-year SHA1 certificate, and we tell them, at some point,
> you’ll probably need to switch back to the SHA2 certificate.
> Ryan: I understand where Bob is coming from on a policy perspective, but
> wouldn’t it be better to provide a warning to customers.
> Rick: That’s what we’re doing.
> Dean: Even NIST didn’t have a SHA2 certificate.
> Brian: If we cannot agree within the Forum, then individual root programs
> should announce what they intend to do. The advantage of doing it within
> the Forum is that there is consistency and everyone knows what to expect.
> As I understand the reason for the Baseline Requirements, they were to give
> CAs more consistency across browser root program policies.
> Ben: We could follow the Symantec approach and then just revoke
> certificates at that date, and it isn’t that auditable, but at least it
> gives people a date to look at, or on the other hand, maybe people want
> SHA1 certificates beyond that date, and we just leave it up to the browsers
> to turn SHA1 support off on January 1, 2017, and then who would want one of
> those certificates.
> Kirk: I see Rick’s point, why not allow people to use it past 2017.
> Rick: That’s not my point.
> Kirk: Well, I see the reasoning behind warning the user and giving them
> both a SHA1 and SHA2 certificate.
> Ryan: This pushes support to the browsers because when a site operator
> does not switch over to SHA2 people will say the browser doesn’t work. So,
> regardless of the sunset date, we’ll have to start taking away your
> security benefits soon, but it would be better to find a solution based on
> policy. If we cannot come to agreement on policy, like Brian said, then we
> are going to have different approaches, but we cannot have a situation
> where we’re going to allow CAs to run SHA1 certificates up the wire and
> pass the cost on to the browsers. The reality is that when a site breaks,
> it is not the site operator that suffers, it’s the users, and users don’t
> contact the site operator, they contact the browser or they go on social
> media and complain.
> Moudrick: We need a date for not issuing them and we need a date for not
> recognizing them.
> Ryan: That’s why we need these dates—to balance these burdens.
> Dean: The Microsoft policy has two dates. It says stop issuing SHA1 on 1
> January 2016 and that on 1 January 2017 it will stop recognizing SHA1
> certificates.
> Rick: That’s why I’m saying we need flexibility.
> Chris: The two certificates solves the refund-revenue-recognition problem.
> There is no return policy because they have something they can move over to.
> Ben: Why can’t we just adopt the Microsoft policy as the Baseline
> Requirements rule?
> Chris: Don’t we have to go with that? I was hoping we could coordinate a
> unified voice. The meeting in 2015 is not going to result in any change.
> Ryan: It is all fine that we as a CA/Browser Forum can agree on something,
> but we need to get the attention of site operators and users on this. If
> January 2016 is the date that CAs cease issuing SHA1 certificates, but site
> operators are installing 3-year certificates until then, we’re going to see
> problems when they have forgotten about it. If we cannot resolve this in
> the CA/Browser Forum, it will be something the browsers will start working
> on to get that messaging out.
> Chris: Rick, could you start putting a pain point out to customers
> starting January 2015?
> Rick: I don’t know. On one of our retail platforms, the customer buys the
> certificate based on lifetime first and then they have to choose whether it
> is SHA1 or SHA2.
> Chris: It would be great if we can all come to consensus on this together.
> Doug: I agree with Rick, because it confuses the customer because they
> want to buy a three-year certificate and they fear anything but SHA1.
> Ryan: We have known about concern with SHA1 since 2009.
> Bob: So we should be experimenting now, not in 2016.
> Ben: It sounds like most of us have some hybrid solution in place already.
> Brian: One of the reasons we should work on this now is to reduce our
> support costs in 2017. Our goal isn’t to cause anyone pain or inconvenience
> now, but to ensure that in 2017 any inconvenience or pain is as close to
> zero as possible and to make this fair to every CA, because if it is coded
> in the browser, then there are no exceptions, and everyone can plan
> accordingly. Whatever way, some CAs are going to experience some pain in
> transitioning to whatever the migration plan is implemented.
> Rick: We need to lead by example, and all CA/Browser Forum members should
> lead by example by installing SHA2 on our own websites.
> Brian: I’m not saying we all move to SHA2, I’m saying we shouldn’t have
> certificates valid into 2017 with SHA1.
> Ryan: There are market realities for why we’re all still using SHA1, but
> we need to find ways to ratchet up SHA2 so that other software vendors,
> site operators, and industry players see the move to SHA2.
> Brian: Browser checks will be implemented regardless of what the Forum
> decides, but I think the purpose of this discussion is come up with a
> unified policy statement about this issue. I believe that if we adopt
> language similar to what Microsoft has said, then CAs will have something
> to point customers to as an industry-wide standard as background for
> explaining one way or another
> Dean: I agree, but I don’t think we need to go beyond with additional
> requirements. We can’t have additional, different browser requirements.
> Iñigo: Is this for just SSL?
> Tom: No. All certificates.
> Richard: In China, the big challenge is that online trade is in the
> billions of dollars and end users will have a problem.
> Brian: But these big sites that do large amounts of business will be able
> to come up with solutions for their end users that are still on SHA1.
> Bob: Ryan has said that in Chrome they will implement a countdown meter
> that tells end users that in X days the website will stop working because
> the server has not migrated from SHA1.
> Richard: But maybe government support in China will help.
> Chris: If we can decide something here, then that will be of help with
> that.
> Ben: For a ballot, is there anything more we need to say?
> Dean: Let’s put the Microsoft language into a draft ballot and circulate
> it for discussion and comment.
> Kirk: Let’s prepare a nice PDF white paper like what we have for the
> deprecation of internal server names for the Forum that explains what is
> going to happen. Microsoft has a list of devices that don’t support SHA2,
> which we can include in the white paper as appendix. The white paper would
> say, check the list now and if you’re device is on the list, switch that
> device out now because it won’t work with SHA2.
> Ben: Good idea, because we have to remember to do outreach on this.
> *Kirk R. Hall*
> Operations Director, Trust Services
> Trend Micro
> +1.503.753.3088
> 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.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140825/4c762e01/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 168 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20140825/4c762e01/attachment-0001.png 

More information about the Public mailing list