On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+steve_medin=symantec....@lists.mozilla.org] On Behalf Of > > Jakob Bohm via dev-security-policy > > Sent: Tuesday, July 18, 2017 4:39 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: [EXT] Symantec Update on SubCA Proposal > > > > > > Just for clarity: > > > > (Note: Using ISO date format instead of ambiguous local date format) > > > > How many Symantec certs issued prior to 2015-06-01 expire after 2018- > > 06-01, and how does that mesh with the alternative date proposed > > below: > > > > On 18/07/2017 21:37, Steve Medin wrote: > > > Correction: Summary item #3 should read: > > > > > > 3. May 1, 2018 > > > a. Single date of distrust of certificates issued prior to > 6/1/2016. > > (changed from August 31,2017 for certificates issued prior to 6/1/2015 > and > > from January 18, 2018 for certificates issued prior to 6/1/2016). > > > > > Over 34,000 certificates were issued prior to 2015-06-01 and expire after > 2018-06-01. This is in addition to almost 200,000 certificates that would > also need to be replaced under the current SubCA proposal assuming a May 1, > 2018 distrust date. We believe that nine months (from August 1, 2017 to May > 1, 2018) is aggressive but achievable for this transition — a period > minimally necessary to allow for site operators to plan and execute an > orderly transition and to reduce the potential risk of widespread ecosystem > disruption. Nevertheless, we urge the community to consider moving the > proposed May 1, 2018 distrust date out even further to February 1, 2019 in > order to minimize the risk of end user disruption by ensuring that website > operators have a reasonable timeframe to plan and deploy replacement > certificates. > That's pretty close to saying that nothing should happen, since almost all the certificates will have expired by then. That certainly is the least disruptive, but it seems contrary to the intent of the proposal. -- Eric > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
