[cabfpub] Proposal for modified Google SHA-1 deprecation policy
Bruce Morton
bruce.morton at entrust.com
Mon Sep 8 20:28:03 UTC 2014
Hi Ryan, thanks for the response. Regarding the questions:
1. I understand that the will not see a page where they will need to take an action to proceed. Thank you.
2. On my second question, I might have made a mistake in the way I asked this. I am wondering if an enterprise has a private trusted CA where the root certificate is not distributed by the browser, if the Chrome trust indications will still occur. Sorry if your past response already answered this.
Thanks, Bruce.
From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, September 08, 2014 3:12 PM
To: Bruce Morton
Cc: CABFPub
Subject: Re: [cabfpub] Proposal for modified Google SHA-1 deprecation policy
On Mon, Sep 8, 2014 at 11:45 AM, Bruce Morton <bruce.morton at entrust.com<mailto:bruce.morton at entrust.com>> wrote:
Hi Ryan,
Thanks for then update. I have a couple of questions that I hope you can help with.
1. When a site gets the indications that it is “affirmatively insecure”, will the user have to take an action to get to the web page? Will the user see a page similar to the attached?
That's not what we communicated.
2. Will the Chrome indications work for certificates that are not validated to public trusted roots? We have enterprises that also run their own dedicated CA and want to know if those certificates will also receive the trust indications.
As explained on the extensive (135+ message) thread in the Chromium Forum, this applies to enterprises, and indeed, is one of the key motivations for this graduated UI, since enterprises were a primary challenge in deprecating SHA-1.
Thanks, Bruce.
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 Ryan Sleevi
Sent: Friday, September 05, 2014 4:23 PM
To: Chema López González
Cc: CABFPub
Subject: Re: [cabfpub] Proposal for modified Google SHA-1 deprecation policy
This is now posted and public at http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
On Sep 5, 2014 12:01 AM, "Chema López González" <clopez at firmaprofesional.com<mailto:clopez at firmaprofesional.com>> wrote:
+1 to Adriano suggestion.
--
Chema López
Gestor de Proyectos - Departamento Técnico
AC Firmaprofesional, S.A.
Edificio ESADECREAPOLIS - 1B13
08173 Sant Cugat del Vallès, Barcelona.
T. 934 774 245
M. 666 429 224
On Wed, Sep 3, 2014 at 3:56 PM, Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>> wrote:
Adriano,
That is a great suggestions, have you heard from Ryan on this yet? I also
find it hard to locate and reference the current Google Chrome baseline
within the long thread in the google groups discussion.
Doug
> -----Original Message-----
> 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 Adriano Santoni - Actalis S.p.A.
> Sent: Friday, August 29, 2014 2:57 AM
> To: public at cabforum.org<mailto:public at cabforum.org>
> Subject: Re: [cabfpub] Proposal for modified Google SHA-1 deprecation
policy
>
> Ryan,
>
> apart from the discussion, it would be a good thing if you published your
plan on
> some Google's web site (like e.g.
> http://www.chromium.org/Home/chromium-security/root-ca-policy)
>
> It would be easier for CAs to show their customers in a more convincing
way
> what Google is going to do.
> In other words, publishing your intent on a web site would have a little
bit more
> officiality -- that would help CAs.
>
> How about that?
>
> Thank you
> Adriano
>
>
>
> Il 29/08/2014 04:13, Ryan Sleevi ha scritto:
> >
> > Hi Kirk,
> >
> > I feel like I have sufficiently explained our concerns and motivations
> > throughout this thread, with both you and other CAs, that it should be
> > readily apparent that this neither meets our goals nor helps our users.
> >
> > I appreciate your thoughtful consideration in writing it.
> >
> > Best,
> > Ryan
> >
> > On Aug 28, 2014 7:04 PM, "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
> > <mailto:kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>>" <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
> > <mailto:kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>>> wrote:
> >
> > Ryan and Chris - here is a serious proposal for a modified Google
> > SHA-1 policy. It meets all of your stated goals. Please give it
> > some consideration.
> >
> > 1. SHA-1 certs issued on or after [Nov. 1, 2014] that expire on or
> > after January 1, 2017 get a double whammy bad UI in Google upon
> > issuance - red slash and nasty click-throughs. (This will stop
> > issuance of 2017 SHA-1 certs this fall.)
> >
> > 2. SHA-1 certs issued before [Nov. 1, 2014] that expire on or
> > after January 1, 2017 get a double whammy bad UI in Google
> > starting [March 1, 2015] - red slash only and nasty
> > click-throughs. (This will force existing websites with 2017
> > SHA-1 certs to change them within the next six months).
> >
> > Result: All 2017 SHA-1 certs will be gone by next March 2015 -
> > which certainly meets your goals. Customers with existing 2017
> > certs can get through this holiday season, CAs can get the message
> > out.
> >
> > Advantages:
> >
> > 1. CAs that have never issued 2017 certs, and never will (like
> > Trend Micro) and their customers are not affected - that's
> > appropriate, as we have never been a part of this problem.
> >
> > 2. CAs that have issued three year SHA-1 certs expiring in 2017
> > will stop by this fall.
> >
> > 3. CAs that have issued 2017 certs in the past (and their
> > customers) will be affected, but will have six months to adjust.
> > That will be a much smaller number of customers affected than if
> > those with 2016 certs are forced to change their certs twice (in
> > 2014 and again in 2015).
> >
> > 4. All SHA-1 certs will likely be gone by next spring.
> >
> > I don't think Google should spend much time worrying about how CAs
> > communicate with their customers about the need to move to SHA-256
> > before 2017 - that's for us to worry about, and we are all
> > strongly incentivized to get the message out (selling a 2017 cert
> > that doesn't work creates legal problems, and none of us wants to
> > be dealing with angry SHA-1 customers in late 2016 who have to
> > switch to SHA-256). We may also be able to get behind Google's
> > policy if it is revised - something that isn't the case today.
> >
> > You mentioned somewhere that you worried that simply deprecating
> > SHA-1 certs as of 2017 could create a big customer service burden
> > on Google as of late 2016 or early 2017. I don't think that's the
> > case with this new proposed policy, as all the negative UI effects
> > will happen in 2014-15. Plus, I predict Google will be deluged
> > with customer service complaints under your current policy, when
> > thousands of websites start showing as "untrusted" in the next
> > 6-12 weeks. Why not make life easier for Google with a revised
> > policy?
> >
> > So what do you think? Can we make a change to the policy that is
> > focused on the real problem (2017 certs)?
> >
> > Thanks for your consideration.
> >
> > */Kirk R. Hall/*
> >
> > Operations Director, Trust Services
> >
> > Trend Micro
> >
> > 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.
> >
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org<mailto:Public at cabforum.org>
> > https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org<mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140908/c5f3cc35/attachment-0003.html>
More information about the Public
mailing list