RE: Symantec Update on SubCA Proposal

2017-08-14 Thread Jeremy Rowley via dev-security-policy
Hi Jakob, 

Your below description raises two questions of general interest (though not of 
interest to the Mozilla root program):

1. Will DigiCert establish cross-signatures from the old/historic
   Symantec roots to continuing DigiCert roots and subCAs?

[JR]  We won’t be cross-signing from DigiCert to Symantec.  For cross-signs the 
other way, we plan on supporting the community’s needs and would love to hear 
more online and offline about what cross-signs to DigiCert are needed for 
compatibility and interoperability. Mozilla proposed distrusting Symantec’s 
roots in 2018 so we’ll work towards that goal. Once it’s removed, the one-way 
trust from Symantec to DigiCert will fall out of scope.  Prior to that, the 
cross-sign will be operated per the BRs and subject to the Google and Mozilla 
proposals.

2. Will DigiCert continue those Symantec services that were not trusted
   by Mozilla/Google and which have no functional alternative elsewhere.

This includes a number of situations where Microsoft and other
   companies are enforcing that things are signed exclusively by specific
   Symantec issuance systems.  Known examples include: The original SHA-1
   time stamping service for code signing (needed for compatibility with
   older Windows and Internet Explorer versions).  The special signing
   portal for Windows Mobile (the original product line, not the new
   renamed Windows 10 Phone product line).  The "hosted" signing service
   for Android Apps.  Possibly any remnants of the Geotrust-based
   services for the old Nokia platforms (Symbian S60 etc.). Etc.

[JR] As you mentioned, none of these are trusted by Mozilla or Google so that 
discussion is better held elsewhere.  However, I can say that we plan to 
support Symantec communities to the extent possible.  The only planned 
deprecation is the Symantec publicly-trusted Web PKI.  

Jeremy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-08-14 Thread Jakob Bohm via dev-security-policy

Your below description raises two questions of general interest (though
not of interest to the Mozilla root program):

1. Will DigiCert establish cross-signatures from the old/historic
  Symantec roots to continuing DigiCert roots and subCAs?

2. Will DigiCert continue those Symantec services that were not trusted
  by Mozilla/Google and which have no functional alternative elsewhere.

   This includes a number of situations where Microsoft and other
  companies are enforcing that things are signed exclusively by specific
  Symantec issuance systems.  Known examples include: The original SHA-1
  time stamping service for code signing (needed for compatibility with
  older Windows and Internet Explorer versions).  The special signing
  portal for Windows Mobile (the original product line, not the new
  renamed Windows 10 Phone product line).  The "hosted" signing service
  for Android Apps.  Possibly any remnants of the Geotrust-based
  services for the old Nokia platforms (Symbian S60 etc.). Etc.


NOTICE TO SOME READERS: Please read the first paragraph of this mail!

On 14/08/2017 06:03, Jeremy Rowley wrote:

Hi wizard,

Although DigiCert will acquire the assets related to Symantec’s CA business, 
DigiCert is not required to use those assets in its business operations.  We 
are organizing the operations of DigiCert to meet the requirements established 
in the Managed CA proposal. This includes having all validation and issuance 
performed through DigiCert’s existing PKI and using DigiCert processes 
accompanied by DigiCert leadership.

Our interpretation of the Google and Mozilla requirements is similar to yours – 
that the goal is to migrate from Symantec’s existing PKI to a third party while 
implementing systematic and operational controls over the issuing and 
validation processes.  Post close, we plan to continue towards these objectives 
using the path adopted by the browsers in the Managed CA process. This path 
includes regular audits during the transition, a migration away from Symantec’s 
issuing and validation systems, and implementation of operational controls to 
prevent mis-issuance.  Our plan is to transition completely away from the 
Symantec issuance platform and validation processes by December 1 and work 
towards the distrust dates set by Mozilla for the end of 2018.

The Managed CA requirements seemed designed to (1) give Symantec time to 
reengineer processes and systems and (2) work towards rebuilding trust in the 
Symantec’s operations.  The acquisition eliminates the need to reengineer the 
process and makes the question of restoring trust moot.  With only DigiCert 
performing the validation and operating the CA, the risks identified to be 
fixed by the Managed CA proposal are remediated as of closing.

Of course, we’re always open to feedback and additional ideas on how to build 
community trust.  Feel free to message us or submit follow-up questions and 
ideas about how we can answer the community’s concerns.


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of wizard--- via dev-security-policy
Sent: Friday, August 11, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Update on SubCA Proposal

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla.

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan.

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated.

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:

-Original Message-
From: dev-security-policy [

RE: Symantec Update on SubCA Proposal

2017-08-13 Thread Jeremy Rowley via dev-security-policy
Hi wizard,

Although DigiCert will acquire the assets related to Symantec’s CA business, 
DigiCert is not required to use those assets in its business operations.  We 
are organizing the operations of DigiCert to meet the requirements established 
in the Managed CA proposal. This includes having all validation and issuance 
performed through DigiCert’s existing PKI and using DigiCert processes 
accompanied by DigiCert leadership.  

Our interpretation of the Google and Mozilla requirements is similar to yours – 
that the goal is to migrate from Symantec’s existing PKI to a third party while 
implementing systematic and operational controls over the issuing and 
validation processes.  Post close, we plan to continue towards these objectives 
using the path adopted by the browsers in the Managed CA process. This path 
includes regular audits during the transition, a migration away from Symantec’s 
issuing and validation systems, and implementation of operational controls to 
prevent mis-issuance.  Our plan is to transition completely away from the 
Symantec issuance platform and validation processes by December 1 and work 
towards the distrust dates set by Mozilla for the end of 2018.  

The Managed CA requirements seemed designed to (1) give Symantec time to 
reengineer processes and systems and (2) work towards rebuilding trust in the 
Symantec’s operations.  The acquisition eliminates the need to reengineer the 
process and makes the question of restoring trust moot.  With only DigiCert 
performing the validation and operating the CA, the risks identified to be 
fixed by the Managed CA proposal are remediated as of closing.

Of course, we’re always open to feedback and additional ideas on how to build 
community trust.  Feel free to message us or submit follow-up questions and 
ideas about how we can answer the community’s concerns. 

Thanks!

Jeremy



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of wizard--- via dev-security-policy
Sent: Friday, August 11, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Update on SubCA Proposal

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla. 

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan. 

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated. 

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just like to give the community a heads up that Chrome’s plan 
> > remains to put up a blog post echoing our recent announcement on 
> > blink-dev [1], but in the meantime, we are reviewing the facts 
> > related to Symantec’s sale of their PKI business to DigiCert [2].
> >
> > Recently, it has come to our attention that Symantec may have 
> > selected DigiCert from the RFP process to become a Managed CA 
> > Partner. As defined in Google’s first Managed CA proposal [3], then 
> > supported by Symantec’s commitment to “[cover] all aspects of the 
> > SubCA proposal” [4], and finally reiterated in Google’s final 
> > proposal [1], the requireme

Re: Symantec Update on SubCA Proposal

2017-08-12 Thread Nick Lamb via dev-security-policy
One good thing we should be able to hope for from a change in ownership even if 
the personnel and equipment are the same or a great deal in common: improved 
management oversight. In my view the most worrying underlying problem at 
Symantec was the inadequate oversight. Senior management at the corporation 
just can't have been giving this the attention it needs. The sale takes them 
out of the picture. That's not a great story for Symantec's shareholders, who 
might reasonably assume that similarly inadequate oversight will continue for 
the other activities of the business - but it's good news for the Relying 
Parties.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-08-12 Thread wizard--- via dev-security-policy
Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla. 

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan. 

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated. 

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just like to give the community a heads up that Chrome’s plan remains to
> > put up a blog post echoing our recent announcement on blink-dev [1], but
> > in the meantime, we are reviewing the facts related to Symantec’s sale of
> > their PKI business to DigiCert [2].
> >
> > Recently, it has come to our attention that Symantec may have selected
> > DigiCert from the RFP process to become a Managed CA Partner. As defined
> > in Google’s first Managed CA proposal [3], then supported by Symantec’s
> > commitment to “[cover] all aspects of the SubCA proposal” [4], and finally
> > reiterated in Google’s final proposal [1], the requirement has always been
> > that the Managed Partner Infrastructure be operated by an independent
> > and non-affiliated CA while Symantec worked to rebuild the web
> > community's confidence.
> >
> > Based on this information, we have a series of questions that we’d like
> > Symantec to address for public discussion:
> >
> > 1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner
> > under the RFP process? If so, in light of DigiCert’s acquisition of 
> > Symantec’s
> > PKI business and Symantec’s substantial equity investment in DigiCert, can
> > you explain how you believe selecting DigiCert as the Managed CA Partner
> > meets the stated requirement of being an independent and non-affiliated
> > organization?
> >
> 
> Before we initiated our SubCA RFP process in May, Google provided Symantec 
> with a list of Certificate Authorities, including DigiCert, which met the 
> eligibility requirements of a Managed CA under the SubCA proposal.   Symantec 
> conducted a thorough SubCA RFP process and believes DigiCert can credibly 
> meet browser requirements and timelines.
> 
> Symantec decided it was in the best interests of all of its stakeholders to 
> sell its Website Security and related PKI solutions to DigiCert. To ensure 
> business continuity for customers, Symantec entered into a SubCA arrangement 
> with DigiCert simultaneous with entry into the definitive acquisition 
> agreement to account for the possibility that the acquisition may not close 
> by December 1, 2017.
> 
> Regardless of whether the acquisition closes before December 1, 2017 or not, 
> there is never a circumstance under which DigiCert will be an 'affiliate' of 
> Symantec with respect to acting as Symantec's Managed CA under the SubCA 
> proposal.  Symantec currently has no ownership interest in or ability 
> (contractual or otherwise) to control the operations of DigiCert, nor does 
> either party otherwise constitute an 'affiliate' of the other, as such term 
> is defined in the CA-Browser Forum Baseline Requirements (v 1.4.9).
> 
> At the clos

Re: Symantec Update on SubCA Proposal

2017-08-11 Thread Steve Medin via dev-security-policy
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Devon O'Brien via dev-security-policy
> Sent: Wednesday, August 09, 2017 12:24 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: Symantec Update on SubCA Proposal
>
> Hello m.d.s.p.,
>
> I'd just like to give the community a heads up that Chrome’s plan remains to
> put up a blog post echoing our recent announcement on blink-dev [1], but
> in the meantime, we are reviewing the facts related to Symantec’s sale of
> their PKI business to DigiCert [2].
>
> Recently, it has come to our attention that Symantec may have selected
> DigiCert from the RFP process to become a Managed CA Partner. As defined
> in Google’s first Managed CA proposal [3], then supported by Symantec’s
> commitment to “[cover] all aspects of the SubCA proposal” [4], and finally
> reiterated in Google’s final proposal [1], the requirement has always been
> that the Managed Partner Infrastructure be operated by an independent
> and non-affiliated CA while Symantec worked to rebuild the web
> community's confidence.
>
> Based on this information, we have a series of questions that we’d like
> Symantec to address for public discussion:
>
> 1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner
> under the RFP process? If so, in light of DigiCert’s acquisition of Symantec’s
> PKI business and Symantec’s substantial equity investment in DigiCert, can
> you explain how you believe selecting DigiCert as the Managed CA Partner
> meets the stated requirement of being an independent and non-affiliated
> organization?
>

Before we initiated our SubCA RFP process in May, Google provided Symantec with 
a list of Certificate Authorities, including DigiCert, which met the 
eligibility requirements of a Managed CA under the SubCA proposal.   Symantec 
conducted a thorough SubCA RFP process and believes DigiCert can credibly meet 
browser requirements and timelines.

Symantec decided it was in the best interests of all of its stakeholders to 
sell its Website Security and related PKI solutions to DigiCert. To ensure 
business continuity for customers, Symantec entered into a SubCA arrangement 
with DigiCert simultaneous with entry into the definitive acquisition agreement 
to account for the possibility that the acquisition may not close by December 
1, 2017.

Regardless of whether the acquisition closes before December 1, 2017 or not, 
there is never a circumstance under which DigiCert will be an 'affiliate' of 
Symantec with respect to acting as Symantec's Managed CA under the SubCA 
proposal.  Symantec currently has no ownership interest in or ability 
(contractual or otherwise) to control the operations of DigiCert, nor does 
either party otherwise constitute an 'affiliate' of the other, as such term is 
defined in the CA-Browser Forum Baseline Requirements (v 1.4.9).

At the closing of the acquisition, Symantec is being paid in both cash and 
stock, with the latter comprising a 30% ownership interest in the common equity 
of DigiCert, which allows for Symantec stockholders to benefit from the 
potential value created by the DigiCert business after the closing. This 
minority ownership position, which shall not be received by Symantec until the 
closing of the acquisition, represents a financial investment in DigiCert.  
This financial investment does not give Symantec control over DigiCert's CA 
technology, operations or business, and therefore we believe that it satisfies 
the spirit of the non-affiliate status that the browser community was seeking 
to achieve through the SubCA proposal.

It is Symantec's understanding that all certificates issued by DigiCert on or 
after December 1, 2017 and the closing of the acquisition will chain to 
DigiCert's existing public roots. If the acquisition closes before December 1, 
2017, then no certificates will ever be issued by DigiCert as a Managed CA of 
Symantec because DigiCert will not be issuing certificates under a new ICA that 
chains to a new Symantec PKI.  Rather, in this instance, certificates will 
either (i) be issued off of Symantec’s existing PKI, which is permitted under 
the SubCA proposal until November 30, 2017, or (ii) be issued off of DigiCert’s 
existing PKI.  The actual timing of the acquisition closing relative to the 
parties’ operational integration planning schedule will determine whether 
certificates are issued under both scenarios or just the latter.

If the acquisition does not close before December 1, 2017, then DigiCert has 
agreed to serve as Symantec's Managed CA partner as of December 1, 2017, but 
will not be an 'affiliate' during this pre-closing period for the reasons 
explained above.

> 2. Were any additional CAs selected to be a Managed CA Partner from the
> list of 

Re: Symantec Update on SubCA Proposal

2017-08-09 Thread Devon O'Brien via dev-security-policy
Hello m.d.s.p.,

I'd just like to give the community a heads up that Chrome’s plan remains to 
put up a blog post echoing our recent announcement on blink-dev [1], but in the 
meantime, we are reviewing the facts related to Symantec’s sale of their PKI 
business to DigiCert [2].

Recently, it has come to our attention that Symantec may have selected DigiCert 
from the RFP process to become a Managed CA Partner. As defined in Google’s 
first Managed CA proposal [3], then supported by Symantec’s commitment to 
“[cover] all aspects of the SubCA proposal” [4], and finally reiterated in 
Google’s final proposal [1], the requirement has always been that the Managed 
Partner Infrastructure be operated by an independent and non-affiliated CA 
while Symantec worked to rebuild the web community's confidence. 

Based on this information, we have a series of questions that we’d like 
Symantec to address for public discussion:

1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner under 
the RFP process? If so, in light of DigiCert’s acquisition of Symantec’s PKI 
business and Symantec’s substantial equity investment in DigiCert, can you 
explain how you believe selecting DigiCert as the Managed CA Partner meets the 
stated requirement of being an independent and non-affiliated organization? 

2. Were any additional CAs selected to be a Managed CA Partner from the list of 
trusted CAs that Symantec “felt best met the browser requirements”?

[1]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ
[2]http://investor.symantec.com/About/Investors/press-releases/press-release-details/2017/DigiCert-to-Acquire-Symantecs-Website-Security-and-Related-PKI-Solutions/default.aspx
[3]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
[4]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/6iZUc7kOCAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-27 Thread Alex Gaynor via dev-security-policy
Just to be explicit: your count includes certificates which, with high
probability have already been replaced, because it does not subtract names
for which new certificates have been issued?

I realize it may seem like I'm putting a lot of emphasis on this one
number, but given that it's the basis for your assertion about the relative
difficulty for different distrust dates, I think it's quite significant.
Given that your methodology appears to over-count (to the advantage of
laxer distrust policies!), and cannot be independently verified, it really
boils down to "trust us to do right by the security of the WebPKI". Not to
put too fine a point on it, but we're in this situation because of
Symantec's history of _not_ acting in the interests of the security of the
WebPKI. It seems to me you could improve the transparency of this process
by logging all DV certs from this time frame to CT.

Alex

On Thu, Jul 27, 2017 at 11:53 AM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> > On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy
> > wrote:
> >
> > > Symantec has proposed timing changes that are consistent with the
> scope of
> > > distrust of the original SubCA proposal as proposed by Google and
> endorsed
> > > by Mozilla, which requires premature replacement of over 234,000
> > > certificates based on our proposed May 1, 2018 distrust date for
> > > certificates issued before June 1, 2016, and optimizes for replacement
> > > certificates to be issued off the new Managed CA(s) infrastructure
> > > (avoiding the requirement for double early replacement for the same
> > > original validity period). We believe our proposal minimizes
> disruption to
> > > websites and web end-users while meeting the spirit of Google’s and
> > > Mozilla’s prior commentary on their intent regarding the SubCA
> proposal,
> > > which is to limit the issuance of Symantec certificates under
> Symantec’s
> > > existing infrastructure and governance.
> > >
> >
> > Hi Rick,
> >
> > Given the importance of this 234,000 number, I was curious to explore.
> > Using the list of certificates Peter Bowen previously put together (
> > https://groups.google.com/a/chromium.org/d/msg/blink-dev/
> eUAKwjihhBs/aQqYZX6oBgAJ),
> > I ran a small script to filter out ones that expire before May 2018, or
> > were issued after June 2016. Using this methodlogy, I got a count of
> 166k,
> > a deviation of ~70k from your number. My 166k includes any certificates
> > that have been replaced since Peter put together the list in April, so in
> > that sense it likely reflects an over estimate of the number of certs
> > needing to be replaced.
> >
> > Can you say a little more on how you came to this number?
> >
> > Cheers,
> > Alex
>
> Our reference to over 234,000 certificates is based on our internal
> records of all active, unrevoked certificates that we issued prior to June
> 1, 2016 that expire after May 1, 2018. The dataset you reference relies on
> CT logs, which includes all active EV certificates Symantec has issued
> before June 1, 2016, but does not include all active, unrevoked OV and DV
> certificates Symantec has issued before June 1, 2016.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-26 Thread Jakob Bohm via dev-security-policy

On 25/07/2017 22:28, Rick Andrews wrote:

...

You are correct in that most customers are indeed not prepared to 
deal with potential crises in the SSL system. We have all witnessed 
this first hand with Heartbleed, the replacement of SHA1

certificates, etc. A four month replacement window for a forced
replacement of this magnitude is unprecedented and we know that
things will break. In the recent CA survey, most major CAs reported
that replacing certificates annually is something that many
organizations are not prepared for – a conclusion that is reinforced
by the recent CA/Browser Forum vote rejecting ballot 185, which
proposed to limit the maximum validity of SSL/TLS certificates
issued by all CAs to 13 months. Do you have data leading you to
believe that this replacement can be executed with limited Internet
ecosystem disruption, particularly amongst the largest enterprises
globally whose certificates would be impacted? If so, we would welcome
seeing that data/rationale. The issues that we have all witnessed
with other forced replacement events on much longer timelines indicate 
that the community is not yet at a place of automation to deal with 
such a transition, especially in a short timeframe. In this case, 
forcing a distrust date of December 1, 2017 (vs. our May 1, 2018 
distrust date recommendation) for certificates issued prior to 
June 1, 2016 increases the total number of premature replacement

certificates that would be need to be issued by approximately 50%
and gives website operators substantially less time (4 months vs.
9 months) in which to plan and execute such a replacement. A 
December 1, 2017 distrust date for certificates issued prior to

June 1, 2016 would introduce a known, actual, material risk to the
Internet ecosystem given the industry’s prior experience with forced
mass replacement episodes. We do not think the perceived benefit of
accelerating distrust for Symantec certificates issued before
June 1, 2016 from May 1, 2018 to December 1, 2017 (5 months of
validity) can possibly justify the significant ecosystem disruption 
that is likely to result from not accepting our proposed May 1, 2018

distrust date for certificates issued before June 1, 2016. We agree
with your public comments on June 19, 2017 that it is not
constructive to get into a date-based "negotiation" over the SubCA
proposal. We have worked backwards from our best estimate for how
long it would take us and our Managed CA partner(s) to implement the
SubCA proposal in a manner that allows for an orderly transition of
Symantec’s existing PKI infrastructure for SSL/TLS certificates to
a Managed CA(s) while minimizing disruption to websites and web
end-users, and have proposed aggressive, yet achievable deadlines
accordingly. As such, while we are willing to go down the SubCA path
overall, we strongly believe that this must be done in a way that
aims to minimize website disruption.



Where exactly was it suggested to distrust certificates issued before
Jun 1, 2016 on December 1, 2017?

So far most of the discussion seems to have been about distrusting
Symantec certs issued after December 1, 2017, at least as I read it.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-26 Thread Alex Gaynor via dev-security-policy
On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Symantec has proposed timing changes that are consistent with the scope of
> distrust of the original SubCA proposal as proposed by Google and endorsed
> by Mozilla, which requires premature replacement of over 234,000
> certificates based on our proposed May 1, 2018 distrust date for
> certificates issued before June 1, 2016, and optimizes for replacement
> certificates to be issued off the new Managed CA(s) infrastructure
> (avoiding the requirement for double early replacement for the same
> original validity period). We believe our proposal minimizes disruption to
> websites and web end-users while meeting the spirit of Google’s and
> Mozilla’s prior commentary on their intent regarding the SubCA proposal,
> which is to limit the issuance of Symantec certificates under Symantec’s
> existing infrastructure and governance.
>

Hi Rick,

Given the importance of this 234,000 number, I was curious to explore.
Using the list of certificates Peter Bowen previously put together (
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/aQqYZX6oBgAJ),
I ran a small script to filter out ones that expire before May 2018, or
were issued after June 2016. Using this methodlogy, I got a count of 166k,
a deviation of ~70k from your number. My 166k includes any certificates
that have been replaced since Peter put together the list in April, so in
that sense it likely reflects an over estimate of the number of certs
needing to be replaced.

Can you say a little more on how you came to this number?

Cheers,
Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-26 Thread Nick Lamb via dev-security-policy
On Tuesday, 25 July 2017 21:29:06 UTC+1, Rick Andrews  wrote:
> The details of this process would probably be best served in a separate 
> thread. Essentially, such a process would involve a quick assessment by the 
> community on the context and merits of the request by the customer

You want us to do Symantec's job, for which Symantec will get paid, in order to 
preserve Symantec's ongoing revenue stream despite Symantec screwing up badly 
to get themselves into this mess ?

Counter proposal: When a customer runs into such a remarkable "exception", 
Symantec pays them $5000 or fully refunds their last year of Symantec services, 
whichever is more, and encourages them to go use the money to choose a 
different CA where they might not need "exceptions" all the time. Maybe you can 
get Symantec's lawyers to make acceptance of the $5000 conditional on agreeing 
not to sue once they understand how much trouble Symantec's incompetence has 
caused for them.

> We may be more aligned on this point than your response suggests. We are in 
> agreement with you that we will cease issuing certificates under the existing 
> infrastructure and governance on December 1, 2017. At that point you could 
> stop accepting the issuance of new certificates off the existing 
> infrastructure and PKI. (See our last reply to this thread where we confirmed 
> this point, but asked for an exception process.) Our point here is that if 
> you also make December 1, 2017 the "distrust date" for all certificates 
> issued off of Symantec’s current PKI before June 1, 2016 then, in effect, you 
> will be forcing all customers to "double down" on the existing Symantec PKI

No there is no need to "double down". Your customers can and should switch to a 
CA which doesn't have a long history of "problems" due to inadequate oversight. 
Trying to retain your customer base is a commercial problem for Symantec, not a 
Web PKI trust problem. This is not "Keep Symantec being like, totally stoked 
about, like, the general vibe and stuff".

> We look forward to the broader community weighing in on this. We urge the 
> community to validate our points, especially the website operators that are 
> being forced to execute this plan. The implementation of a forced plan that 
> introduces material risks on an unrealistic timeline is inappropriate and 
> dangerous.

The underlying cause here is Symantec. This isn't a systemic problem, it's a 
Symantec problem, the only "website operators" affected are those who foolishly 
trusted Symantec to run a CA properly. A reasonable question for such website 
operators to ask would be: Where's the press release listing all the board 
members and other core leadership who were terminated as a result of their 
failure to execute their only task, providing oversight for the business so 
that it doesn't blunder into such problems ? Where's the communication from 
Symantec warning me that their failings may cause my business massive 
inconvenience and I should begin planning now to move to a different CA to 
avoid that ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-24 Thread Gervase Markham via dev-security-policy
Hi Rick,

Some more thoughts on your post. I continue to invite community
commentary on the issues we are discussing.

On 21/07/17 07:00, Rick Andrews wrote:
> In our June 1 post, we stated that we would update the community after the 
> end of the month. 

Indeed. I was more referring to the suggestions made in the meeting with
Mozilla about when the public statement would be forthcoming. But no matter.

> Correct. However, as we indicated in our update, with a change of
> this magnitude we believe that there will likely be material
> compatibility and interoperability issues that will only come to
> light once server operators begin the transition to the Managed CA
> issued certificates. Recognizing this, we recommend that we establish
> a clear process to evaluate exception requests that includes
> consultations with the browsers to handle such corner cases.
Operators who have initial difficulty with the transition can, of
course, stay on their certificates issued from the old infrastructure.
(It's worth noting that if all of those customers had recently renewed
their certificates, as my proposal suggests, then there would not be a
problem with their existing-infra certs expiring while they were
attempting to make the transition.)

How would you see such an exception process working, and how would it be
implemented technically?

> While this is true under the terms of the SubCA proposal, we do not
> believe this is consistent with the spirit of Google’s and Mozilla’s
> prior commentary on their intent regarding the SubCA proposal, which
> is to limit the issuance of Symantec certificates under Symantec’s
> existing infrastructure and governance.
I'm not sure how you reach that conclusion. We want to end new issuance
in December, you want it to continue until next May. How are our dates
more inconsistent than yours with a desire to limit the issuance of
Symantec certificates under the existing infrastructure and governance?
We want to limit it earlier.

> dates.  Accordingly, our intention and expectation is that the
> majority of certificates issued before June 1, 2016 that will need to
> be replaced before their expiration under the current SubCA proposal
> will occur after the Managed CA is implemented. This will ensure
> there are no limitations on the replacement certificates that are
> issued to affected customers, which limits the substantial risks of
> implementation problems if our customers are not given the
> appropriate time to plan and execute their certificate replacements.
It may be appropriate for the limitations on current-infra issuance
lifetime in the plan to be adjusted by a few months such that a
certificate issued now can continue to work until the full distrust date
of November 1st, 2018. This would effectively mean that there are no
(additional) limitations on the replacement certificates.

> In our post we explained our rationale of why this period needs to be
> a minimum of 9 months. It is important for the community to note the
> significant operational burden and compatibility / interoperability
> risks that our customers will face if they have to replace their
> certificates once, let alone twice.
Why do you see a compatibility and interoperability risk in the process
of replacing a certificate with an identical certificate except that is
a) definitely logged to CT, and b) has a later expiry date?

You may argue that it's a customer operational burden but again, if
customers have difficulty replacing their SSL certs in a 4-month
timeframe, then they are not well positioned to deal with a number of
potential crises in the SSL system, such as compromise (and distrust) of
an intermediate, or compromise of their webservers.

> Our recommendation for replacing certificates issued before June 1,
> 2016 by May 1, 2018 (and preferably by February 1, 2019) enables a
> single shift to our new PKI for SSL/TLS certificates and eliminates
> any necessity for organizations to replace their certificates
> multiple times.
As noted above, I am not particularly impressed by arguments that
"replacing our certificates twice in 2-3 years is too hard".

It's also worth noting that in the timeline you propose, organizations
would have only 5 months (Dec 1 2017 - May 1 2018), including the
holiday period, to test and deploy the actual certificates they would be
using from the Managed CAs - those which do carry compatibility risk.
And it's only 3 months if they want to replace with fully-validated
non-DV certificates. My plan allows 9 uninterrupted months for that,
which gives significantly more scope to deal with unexpected
compatibility problems caused by new algorithms, new chains, etc. etc.
If customers are asking for time to manage a transition to a new
hierarchy, and that is your key concern, the plan I am proposing gives
them significantly more of it than yours does.

> The practical effect of this suggestion is to require up to two early
> replacements for affected customers of certificates 

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Rick Andrews via dev-security-policy
On Friday, July 21, 2017 at 12:39:54 PM UTC-7, Peter Bowen wrote:
> Steve,
> 
> I think this level of public detail is very helpful when it comes to
> understanding the proposal.
> 
> On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy
> wrote:
> > 1)  December 1, 2017 is the earliest credible date that any RFP 
> > respondent can provide the Managed CA solution proposed by Google, assuming 
> > a start date of August 1, 2017. Only one RFP respondent initially proposed 
> > a schedule targeting August 8, 2017 (assuming a start date of June 12, 
> > 2017). We did not deem this proposal to be credible, however, based on the 
> > lack of specificity around our RFP evaluation criteria, as compared to all 
> > other RFP responses which provided detailed responses to all aspects of the 
> > RFP, and we have received no subsequent information from this bidder to 
> > increase our confidence.
> 
> You note that this assumes a start date of June 12.   A later email
> from Rick Andrews says "Our proposed dates assume we are able to
> finalize negotiation of contracts with the selected Managed CA
> partner(s), [...] by no later than July 31, 2017."
> 
> Presumably the June 12 date is long gone.  However if one assumes the
> delta of 57 days from start to delivery stands, this would put
> delivery at September 26, 2017.  This is two months sooner than the
> December 1 date.  This seems like a pretty big difference.  Given you
> are asking to delay the timeline based on other RFP respondents being
> unable to hit earlier dates, it seems prudent to ask whether the you
> attempted to investigate the proposal from the bidder who proposed
> August 8.

Please see our response to Alex Gaynor.
 
> Given that one of the requirements stated by Google is that the SubCA
> operator had to have roots that have been in the Google trust store
> for several years, it seems unusual that any eligible respondent would
> not be "credible" out of the gate.
> 
> Did you ask them to provide more information and details to help
> determine if it was a "credible" offer?

There is a difference between a prospective SubCA being capable of performing 
the activities of a Managed CA under the SubCA proposal and having a realistic 
plan to do so. We concluded the RFP response from the sole respondent who 
proposed a 2-month timeline was not credible because it failed to meet a 
minimum bar of providing us with sufficient information to evaluate the 
bidder’s ability to satisfy RFP requirements or meaningfully compare / contrast 
the bidder’s response with all other RFP respondents.  There were other 
attributes relating to this bidder’s proposal beyond its lack of content in 
addressing RFP evaluation criteria that reinforced our conclusion that the bid 
was not credible.

> > 2)  We are using several selection criteria for evaluating RFP 
> > responses, including the depth of plan to address key technical integration 
> > and operational requirements, the timeframe to execute, the ability to 
> > handle the scope, volume, language, and customer support requirements both 
> > for ongoing issuance and for one-time replacement of certificates issued 
> > prior to June 1, 2016, compliance program and posture, and the ability to 
> > meet uptime, interface performance, and other SLAs. Certain RFP respondents 
> > have distinguished themselves based on the quality and depth of their 
> > integration planning assumptions, requirements and activities, which have 
> > directly influenced the dates we have proposed for the SubCA proposal.
> >
> > 3)  The RFP was first released on May 26, 2017. The first round of 
> > bidder responses was first received on June 12, 2017.
> 
> In the 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
> message, it was implied that Symantec was aware of the SubCA plan and
> dates since at least May 12.  Given the plan to sign an agreement by
> July 31, the August 8 date seems rather impossible. Did Symantec push
> back on the August 8 date at that point?

Yes, Symantec pushed back on the August 8 date in its earliest discussions with 
both Google and Mozilla after the SubCA proposal was made. We pushed back on 
the dates again publicly on June 1st.  We have now done the work of executing a 
robust RFP process that included multiple parties and involved multiple working 
sessions to arrive at dates that are both aggressive and achievable for the 
size and scale of our CA operations. 

> In the original email that started this subthread, you said, "Some of
> the prospective Managed CAs have proposed supporting only a portion of
> our volume (some by customer segment, others by geographic focus), so
> we are also evaluating options that involve working with multiple
> Managed CAs."
> 
> Have you considered a staggered date system for different classes of
> certificates.  For example, I would assume that certificates that
> don't contain subject identity information 

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Rick Andrews via dev-security-policy
On Friday, July 21, 2017 at 12:07:02 PM UTC-7, Alex Gaynor wrote:
> On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin wrote:
> 
> > 1)  *December 1, 2017 is the earliest credible date that any RFP
> > respondent can provide the Managed CA solution proposed by Google, assuming
> > a start date of August 1, 2017. Only one RFP respondent initially proposed
> > a schedule targeting August 8, 2017 (assuming a start date of June 12,
> > 2017). We did not deem this proposal to be credible, however, based on the
> > lack of specificity around our RFP evaluation criteria, as compared to all
> > other RFP responses which provided detailed responses to all aspects of the
> > RFP, and we have received no subsequent information from this bidder to
> > increase our confidence.*
> >
> >
> Hi Steve,
> 
> Given that this represents nearly a 4 month difference in timelines, can
> you give us any more insight here as why you see such a large delta?
> 
> Alex

We have evaluated the rigor of the proposals with regard to integration between 
Symantec and the Managed CA(s) for all certificate lifecycle functions for 
retail, partner, and Enterprise RA models, supporting enrollment, all methods 
of domain verification, organization and extended validation vetting, 
re-authentication, replacement, renewal, cancelation, modification, revocation, 
CAA checking, CT logging, and CRL and OCSP response provisioning; the models 
for cross-team engagement and release planning; identification of any gaps and 
the plans to address; and the plans for end-to-end testing. The most aggressive 
of the RFP responses was the sole outlier in terms of timing (2 months to 
implementation) and offered the least amount of information in response to the 
RFP. There were other attributes relating to this bidder’s proposal beyond its 
lack of content in addressing RFP evaluation criteria that reinforced our 
conclusion that the bid was not realistic.  The difference between the most 
aggressive timing proposal when compared with the other RFP respondent plans 
was only about two months. All other RFP responses independently offered 
project plan timelines that spanned approximately 4-6 months. Symantec’s 
internal planning concluded that a 4 month timeline was aggressive but 
achievable.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Peter Bowen via dev-security-policy
Steve,

I think this level of public detail is very helpful when it comes to
understanding the proposal.

On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy
 wrote:
> 1)  December 1, 2017 is the earliest credible date that any RFP 
> respondent can provide the Managed CA solution proposed by Google, assuming a 
> start date of August 1, 2017. Only one RFP respondent initially proposed a 
> schedule targeting August 8, 2017 (assuming a start date of June 12, 2017). 
> We did not deem this proposal to be credible, however, based on the lack of 
> specificity around our RFP evaluation criteria, as compared to all other RFP 
> responses which provided detailed responses to all aspects of the RFP, and we 
> have received no subsequent information from this bidder to increase our 
> confidence.

You note that this assumes a start date of June 12.   A later email
from Rick Andrews says "Our proposed dates assume we are able to
finalize negotiation of contracts with the selected Managed CA
partner(s), [...] by no later than July 31, 2017."

Presumably the June 12 date is long gone.  However if one assumes the
delta of 57 days from start to delivery stands, this would put
delivery at September 26, 2017.  This is two months sooner than the
December 1 date.  This seems like a pretty big difference.  Given you
are asking to delay the timeline based on other RFP respondents being
unable to hit earlier dates, it seems prudent to ask whether the you
attempted to investigate the proposal from the bidder who proposed
August 8.

Given that one of the requirements stated by Google is that the SubCA
operator had to have roots that have been in the Google trust store
for several years, it seems unusual that any eligible respondent would
not be "credible" out of the gate.

Did you ask them to provide more information and details to help
determine if it was a "credible" offer?

> 2)  We are using several selection criteria for evaluating RFP responses, 
> including the depth of plan to address key technical integration and 
> operational requirements, the timeframe to execute, the ability to handle the 
> scope, volume, language, and customer support requirements both for ongoing 
> issuance and for one-time replacement of certificates issued prior to June 1, 
> 2016, compliance program and posture, and the ability to meet uptime, 
> interface performance, and other SLAs. Certain RFP respondents have 
> distinguished themselves based on the quality and depth of their integration 
> planning assumptions, requirements and activities, which have directly 
> influenced the dates we have proposed for the SubCA proposal.
>
> 3)  The RFP was first released on May 26, 2017. The first round of bidder 
> responses was first received on June 12, 2017.

In the 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
message, it was implied that Symantec was aware of the SubCA plan and
dates since at least May 12.  Given the plan to sign an agreement by
July 31, the August 8 date seems rather impossible. Did Symantec push
back on the August 8 date at that point?

In the original email that started this subthread, you said, "Some of
the prospective Managed CAs have proposed supporting only a portion of
our volume (some by customer segment, others by geographic focus), so
we are also evaluating options that involve working with multiple
Managed CAs."

Have you considered a staggered date system for different classes of
certificates.  For example, I would assume that certificates that
don't contain subject identity information would have less work for
migration integration than EV certificates.  Given that it is common
practice to have a different SubCA for different certificates types,
could you hit an earlier date for non-EV certificates and then later
have the EV SubCA ready?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Alex Gaynor via dev-security-policy
On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin 
wrote:

> 1)  *December 1, 2017 is the earliest credible date that any RFP
> respondent can provide the Managed CA solution proposed by Google, assuming
> a start date of August 1, 2017. Only one RFP respondent initially proposed
> a schedule targeting August 8, 2017 (assuming a start date of June 12,
> 2017). We did not deem this proposal to be credible, however, based on the
> lack of specificity around our RFP evaluation criteria, as compared to all
> other RFP responses which provided detailed responses to all aspects of the
> RFP, and we have received no subsequent information from this bidder to
> increase our confidence.*
>
>
Hi Steve,

Given that this represents nearly a 4 month difference in timelines, can
you give us any more insight here as why you see such a large delta?

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-21 Thread Gervase Markham via dev-security-policy
On 21/07/17 07:00, Rick Andrews wrote:
> In light of all of these implications, we respectfully request that Mozilla, 
> Google and the community consider the dates Symantec has proposed, which are 
> the results of our earnest and extensive efforts to implement the spirit of 
> the SubCA proposal. 

Thank you for the timeliness and completeness of your response. I am
travelling today, but will try and consider it over the weekend.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Update on SubCA Proposal

2017-07-21 Thread Rick Andrews via dev-security-policy
On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote:
> Hi Steve,
> 
> Thanks for posting this. I appreciate the level of detail provided,
> which is useful in giving us a basis for discussion. It's a little
> regrettable, though, that it was published a couple of weeks after we
> were led to expect it...

In our June 1 post, we stated that we would update the community after the end 
of the month. Considering the community’s request for detail in our response, 
we wanted our update to reflect our latest discussions with RFP respondents, 
which took place during the first two weeks of July.  These discussions have 
directly informed our proposed dates as described in our post.  We also felt it 
was important to collect feedback from both Google and Mozilla (which we have 
done) on our draft timing proposal before submitting it to the community for 
consideration given that Google and Mozilla authored / endorsed the SubCA 
proposal.

> One note before we start: Symantec's business dealings regarding its CA
> business are not of concern to Mozilla other than relating to the
> "change of ownership or control" provisions in Mozilla policy (policy
> 2.5 section 8). However, if dates are proposed or agreed for
> implementation of the consensus plan, we would not expect those dates to
> be renegotiated because of a change of ownership or control.
> 
> Am I right in saying that, in order to hit these dates you are
> proposing, you would strongly desire to get consensus on them by August 1st?

Symantec would like to reach consensus on the totality of the SubCA proposal, 
including final dates, as soon as possible.  This is in the best interest of 
all.  Our proposed dates assume we are able to finalize negotiation of 
contracts with the selected Managed CA partner(s), which incorporate final 
agreed-upon dates by the community, by no later than July 31, 2017.

> On 18/07/17 19:22, Steve Medin wrote:
> > New Certificate Issuance: We believe the dates for transition of validation 
> > and issuance to the Managed CA that are both aggressive and achievable are 
> > as follows:
> > 
> > - Implement the Managed CA by December 1, 2017 (changed from August 8, 
> > 2017);
> > 
> > - Managed CA performs domain validation for all new certificates by 
> > December 1, 2017 (changed from November 1, 2017); and
> > 
> > - Managed CA performs full validation for all certificates by February 1, 
> > 2018. Prior to this date, reuse of Symantec authenticated organization 
> > information would be allowable for certificates of <13 months in validity.
> 
> To summarise for those reading along: this represents a change of a
> little less than 4 months for the first date, 1 month for the second
> date, and the third date is as originally proposed.

This is correct. We have worked with our RFP respondents to put together an 
aggressive but achievable plan that delivers on the spirit of the original 
proposal.

> Steve: to be clear, this means that browsers could implement a block on
> certificates from Symantec's existing PKI as follows: after December
> 1st, 2017, they could dis-trust all certificates with a notBefore
> greater than December 1st 2017?

Correct. However, as we indicated in our update, with a change of this 
magnitude we believe that there will likely be material compatibility and 
interoperability issues that will only come to light once server operators 
begin the transition to the Managed CA issued certificates. Recognizing this, 
we recommend that we establish a clear process to evaluate exception requests 
that includes consultations with the browsers to handle such corner cases.

> Given the explanations Symantec has given as to why these dates are
> reasonable, and the effort required to stand up the new PKI, I am minded
> to accept them, particularly as they have managed to hit the third
> originally-proposed date on the nose. However, I am still open to
> community input.
> 
> > Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> > two major milestones that must be achieved after implementation of the 
> > Managed CA in order to replace unexpired certificates issued before June 1, 
> > 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> > proposal. Those include the full revalidation of certificate information 
> > and then the customer replacement of those certificates. 
> 
> That is not necessarily so. The customers could replace their
> certificates using new, CT-logged certificates from Symantec's old
> infrastructure. This doesn't require any revalidation or any change in
> the certificate chain, so should have excellent compatibility
> properties, and it's something that could begin today.

While this is true under the terms of the SubCA proposal, we do not believe 
this is consistent with the spirit of Google’s and Mozilla’s prior commentary 
on their intent regarding the SubCA proposal, which is to limit the issuance of 
Symantec 

Re: Symantec Update on SubCA Proposal

2017-07-20 Thread Gervase Markham via dev-security-policy
Hi Steve,

Thanks for posting this. I appreciate the level of detail provided,
which is useful in giving us a basis for discussion. It's a little
regrettable, though, that it was published a couple of weeks after we
were led to expect it...

One note before we start: Symantec's business dealings regarding its CA
business are not of concern to Mozilla other than relating to the
"change of ownership or control" provisions in Mozilla policy (policy
2.5 section 8). However, if dates are proposed or agreed for
implementation of the consensus plan, we would not expect those dates to
be renegotiated because of a change of ownership or control.

Am I right in saying that, in order to hit these dates you are
proposing, you would strongly desire to get consensus on them by August 1st?

On 18/07/17 19:22, Steve Medin wrote:
> New Certificate Issuance: We believe the dates for transition of validation 
> and issuance to the Managed CA that are both aggressive and achievable are as 
> follows:
> 
> - Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);
> 
> - Managed CA performs domain validation for all new certificates by December 
> 1, 2017 (changed from November 1, 2017); and
> 
> - Managed CA performs full validation for all certificates by February 1, 
> 2018. Prior to this date, reuse of Symantec authenticated organization 
> information would be allowable for certificates of <13 months in validity.

To summarise for those reading along: this represents a change of a
little less than 4 months for the first date, 1 month for the second
date, and the third date is as originally proposed.

Steve: to be clear, this means that browsers could implement a block on
certificates from Symantec's existing PKI as follows: after December
1st, 2017, they could dis-trust all certificates with a notBefore
greater than December 1st 2017?

Given the explanations Symantec has given as to why these dates are
reasonable, and the effort required to stand up the new PKI, I am minded
to accept them, particularly as they have managed to hit the third
originally-proposed date on the nose. However, I am still open to
community input.

> Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> two major milestones that must be achieved after implementation of the 
> Managed CA in order to replace unexpired certificates issued before June 1, 
> 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> proposal. Those include the full revalidation of certificate information and 
> then the customer replacement of those certificates. 

That is not necessarily so. The customers could replace their
certificates using new, CT-logged certificates from Symantec's old
infrastructure. This doesn't require any revalidation or any change in
the certificate chain, so should have excellent compatibility
properties, and it's something that could begin today. In fact, as I
understand it, Symantec has already been encouraging their customers to
do exactly this.

This would, of course, mean, that those certificates would need
replacing again at some point before the final total dis-trust of the
current Symantec PKI.

This activity would need to start during the December holiday season
when many organizations impose infrastructure blackout periods.  As
such, we believe that the only achievable timing for this transition is
after the holiday season. We understand that browsers may want to
technically enforce this transition and that multiple milestones may be
undesirable from a coding perspective. In order to accommodate a
simplified and cost efficient transition schedule (especially for
organizations that currently have certificates with notBefore dates of
both June 1, 2015 and June 1, 2016) and to allow impacted organizations
the time, as they will likely need to replace, test and operationalize
these replacement certificates in their infrastructure, we recommend
consolidating Chrome's distrust dates to a single date of May 1, 2018.
This would mean that Chrome's distrust of Symantec certificates issued
before June 1, 2015 would change from August 31, 2017 to May 1, 2018,
and that Chrome's distrust of Symantec certificates issued before June
1, 2016 would change from January 18, 2018 to May 1, 2018.

A key date for Mozilla is when we can tell our software to dis-trust any
certificate issued by the Symantec current PKI which was issued before
June 1st 2016, because certificates issued after that are guaranteed
(pretty much) to be in CT, and therefore are a bounded and known set.
Therefore pushing that date out to May 1st 2018 seems like a negative
from our perspective.

A two-stage strategy such as the one outlined above seems to us to be
worth investigating, as it would allow us to give Symantec more time to
transition its customers from the current to the new PKI (something
which might come with compatibility risk, as you have correctly noted)
without having to bear the risk of continuing to 

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy
1)  December 1, 2017 is the earliest credible date that any RFP respondent 
can provide the Managed CA solution proposed by Google, assuming a start date 
of August 1, 2017. Only one RFP respondent initially proposed a schedule 
targeting August 8, 2017 (assuming a start date of June 12, 2017). We did not 
deem this proposal to be credible, however, based on the lack of specificity 
around our RFP evaluation criteria, as compared to all other RFP responses 
which provided detailed responses to all aspects of the RFP, and we have 
received no subsequent information from this bidder to increase our confidence.

2)  We are using several selection criteria for evaluating RFP responses, 
including the depth of plan to address key technical integration and 
operational requirements, the timeframe to execute, the ability to handle the 
scope, volume, language, and customer support requirements both for ongoing 
issuance and for one-time replacement of certificates issued prior to June 1, 
2016, compliance program and posture, and the ability to meet uptime, interface 
performance, and other SLAs. Certain RFP respondents have distinguished 
themselves based on the quality and depth of their integration planning 
assumptions, requirements and activities, which have directly influenced the 
dates we have proposed for the SubCA proposal.

3)  The RFP was first released on May 26, 2017. The first round of bidder 
responses was first received on June 12, 2017.

4)  It is our longstanding policy not to comment on rumors or market 
speculation.





From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Wednesday, July 19, 2017 10:25 AM
To: Steve Medin <steve_me...@symantec.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal



Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   
(https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal).
   In this mail you wrote that "Last month, we released a Request for Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI). Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy
We believe our proposed dates reflect an aggressive but achievable period of 
time to implement the SubCA proposal and allow impacted organizations the time 
needed to replace, test and operationalize replacement certificates in their 
infrastructure to mitigate interoperability and compatibility risk associated 
with this premature replacement of certificates, which is consistent with the 
intent of the SubCA proposal. Our proposed dates are informed by the RFP 
responses and follow-up discussions we have had with our prospective Managed CA 
partners.





From: Eric Mill [mailto:e...@konklone.com]
Sent: Wednesday, July 19, 2017 3:43 PM
To: Steve Medin <steve_me...@symantec.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal







On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   > -Original Message-
   > From: dev-security-policy 
[mailto:dev-security-policy-<mailto:dev-security-policy->
   > 
bounces+steve_medin=symantec@lists.mozilla.org<mailto: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<mailto: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<mailto:dev-security-policy@lists.mozilla.org>
   https://lists.mozilla.org/listinfo/dev-security-policy







   --

   
konklone.com<https://clicktime.symantec.com/a/1/AAH-mYCdy7I540ZoJM0XkW-CDP-fn5bw0sk2P0x4Bvw=?d=U4j3hHTn-UxZ1ZOfHXB7r1lDEq3pYTpkBXJxYkQlk96LvJvpQVJPahGolj9IF9urhtYGsaK_9Mffi6158JvklYeFSEsWRIpnJD82JAbPyGBp6h78ufI4ZGIR8UZNoRVvgyVmB_Lq39lujhD-qOpO1y9E3I2BCtUkhiN98DyEsGpFxqp2JqPiLWxpjzBUBE3IqSdY8Pq0ezPKtY4XG0-7KydvGYIUGOlZJnVxW6_xEJseIlanIDcdA28GGtACgaVDc2QZBHhwpJ8TUK0GgpMW2fu3QdoLf2Fq_yOaeJe1F4AMkzBFTjbk9GF9TNfXVA4dVafUoWb5IFaE6uOy6B6cXKXbZIgX-Ya4lJ0dZ2ZjCSdJSLW2NfhVWxc-FScig3WKjyr-PsV_0lY0ODqzD8M1fhjT-XPzPQ%3D%3D=https%3A%2F%2Fkonklone.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


RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> David E. Ross via dev-security-policy
> Sent: Wednesday, July 19, 2017 12:48 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>
> On 7/19/2017 8:31 AM, Steve Medin 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.
> >
>
> It appears that Symantec wants to delay distrusting certificates until all
> existing subscriber certificates reach their inherent expiration dates.
>

Our proposed distrust date (May 1, 2018) is based on an aggressive but 
achievable period of time to allow impacted organizations the time needed to 
replace, test and operationalize replacement certificates in their 
infrastructure.  More than 234,000 certificates are required to be replaced 
before their expiration dates assuming a distrust date of May 1, 2018. In fact, 
we urge the community to consider moving this 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. This recommendation is echoed by our prospective 
Managed CA partners.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy
> -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: Wednesday, July 19, 2017 12:22 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> 
> On 19/07/2017 17:31, Steve Medin 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.
> >
> 
> So when and why did Symantec issue 34,000 WebPKI certificates valid
> longer than 3 years, that would expire after 2018-06-01 ?
> 
> Are these certificates issued before 2015-04-01 with validity periods longer
> than 39 months?
> 
> Are they certificates issued under "special circumstances" ?
> 
> Are they certificates with validity periods between 36 and 39 months?
> 
> 

The vast majority of these certificates were issued prior to April 1, 2015 and 
were subject to the 60 month rule that was in effect at the time of issuance. 
This population also includes several thousand that are for <39 month validity.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Eric Mill via dev-security-policy
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


Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread David E. Ross via dev-security-policy
On 7/19/2017 8:31 AM, Steve Medin 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.
> 

It appears that Symantec wants to delay distrusting certificates until
all existing subscriber certificates reach their inherent expiration
dates.

-- 
David Ross

<http://www.rossde.com/>
President Trump now denies there are any tapes that
recorded his conversations with ex-FBI Director Comey.
Between when Trump hinted there might be such tapes
and his denial, there was sufficient time to destroy
any tapes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Jakob Bohm via dev-security-policy

On 19/07/2017 17:31, Steve Medin 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.



So when and why did Symantec issue 34,000 WebPKI certificates valid
longer than 3 years, that would expire after 2018-06-01 ?

Are these certificates issued before 2015-04-01 with validity periods
longer than 39 months?

Are they certificates issued under "special circumstances" ?

Are they certificates with validity periods between 36 and 39 months?




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Steve Medin via dev-security-policy
> -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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Alex Gaynor via dev-security-policy
Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the
Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   (
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
).
   In this mail you wrote that "Last month, we released a Request for
Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI).
Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex

On Tue, Jul 18, 2017 at 3:37 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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).
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Steve Medin via dev-security-policy
> > Sent: Tuesday, July 18, 2017 2:23 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec Update on SubCA Proposal
> >
> > *Progress Update on SubCA RFP, Partner Selection, and Execution*
> >
> >
> >
> > Since June 1, Symantec has worked in earnest to operationalize the SubCA
> > proposal outlined by Google and Mozilla and discussed in community
> > forums.  The core of this proposal is to transfer the authentication and
> > issuance of certificates to a set of new SubCAs that are operated by
> > "Managed CAs", with the eventual end state being a move from the existing
> > Symantec PKI to a modernized platform. We are providing this update to
> > share our initial findings of our efforts to implement the SubCA
> proposal,
> > and as previously posted, propose aggressive but achievable dates for
> > certain aspects of the SubCA proposal.
> >
> >
> >
> > Last month, we released a Request for Proposal (RFP) that covered all
> > aspects of the SubCA proposal, including key management, technical
> > integration, staffing, training, compliance, support, and the end-to-end
> > coordination of operations. This RFP was sent to the CAs that we felt
> best
> > met the browser requirements and had the potential to successfully
> fulfill
> > the scope and volume of our CA authentication and issuance activities.
> >
> >
> >
> > After receiving RFP responses, we met with the prospective Managed CAs
> > to discuss and refine their proposed approach, clarify intent and answer
> > questions impacting their proposals, which addressed their approach to
> > and schedule for integration, staffing, compliance, support, and other
> > operational aspects.  Over the last two weeks, we have continued to
> receive
> > detailed responses from RFP respondents and hold meetings with the
> > prospective Managed CAs to review their proposals in order to select the
> > final Managed CA partner(s) that will be able to best execute on the plan
> > proposed by Google and Mozilla. We appreciate the CAs who have replied
> > and recognize that drafting the proposals required a tremendous amount
> > of time and effort as part of this accelerated process.
> >
> >
> >
> > We continue to work through implementation details with our prospective
> > Managed CA partners, to understand the depth of analysis that has gone
> > into their development schedules and staffing plans, and to assess the
> > feasibility of those plans.  We expect to complete the selection process
> > within the next 2 weeks. After selecting the final Managed CA
> partner(s), we
> > will work aggressively towards the execution of an agreement and
> > integration plan.
> >
> >
> >
> > As we finalize the selection process, our development team is actively
> > working towards the transition.  Currently, we are shifting from design
> to
> > implementation of a common set of APIs across platforms to simpli

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-18 Thread Jakob Bohm via dev-security-policy


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).


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
Steve Medin via dev-security-policy
Sent: Tuesday, July 18, 2017 2:23 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: [EXT] Symantec Update on SubCA Proposal

*Progress Update on SubCA RFP, Partner Selection, and Execution*



Since June 1, Symantec has worked in earnest to operationalize the SubCA
proposal outlined by Google and Mozilla and discussed in community
forums.  The core of this proposal is to transfer the authentication and
issuance of certificates to a set of new SubCAs that are operated by
"Managed CAs", with the eventual end state being a move from the existing
Symantec PKI to a modernized platform. We are providing this update to
share our initial findings of our efforts to implement the SubCA proposal,
and as previously posted, propose aggressive but achievable dates for
certain aspects of the SubCA proposal.



Last month, we released a Request for Proposal (RFP) that covered all
aspects of the SubCA proposal, including key management, technical
integration, staffing, training, compliance, support, and the end-to-end
coordination of operations. This RFP was sent to the CAs that we felt best
met the browser requirements and had the potential to successfully fulfill
the scope and volume of our CA authentication and issuance activities.



After receiving RFP responses, we met with the prospective Managed CAs
to discuss and refine their proposed approach, clarify intent and answer
questions impacting their proposals, which addressed their approach to
and schedule for integration, staffing, compliance, support, and other
operational aspects.  Over the last two weeks, we have continued to receive
detailed responses from RFP respondents and hold meetings with the
prospective Managed CAs to review their proposals in order to select the
final Managed CA partner(s) that will be able to best execute on the plan
proposed by Google and Mozilla. We appreciate the CAs who have replied
and recognize that drafting the proposals required a tremendous amount
of time and effort as part of this accelerated process.



We continue to work through implementation details with our prospective
Managed CA partners, to understand the depth of analysis that has gone
into their development schedules and staffing plans, and to assess the
feasibility of those plans.  We expect to complete the selection process
within the next 2 weeks. After selecting the final Managed CA partner(s), we
will work aggressively towards the execution of an agreement and
integration plan.



As we finalize the selection process, our development team is actively
working towards the transition.  Currently, we are shifting from design to
implementation of a common set of APIs across platforms to simplify the
integration with one or more Managed CAs.



Based on the RFP responses, internal planning, and discussions with RFP
respondents to date, we are still concerned with the implementation
timing. Based on both our own internal scoping and the RFP responses, we
see a practical, aggressive transition being achievable between early-
December and late-February, depending on the specific Managed CA(s) and
the unknowns that come with an effort of this magnitude.  This timeframe
is based on the Managed CAs' RFP responses regarding how long it will take
to integrate our existing customer portals (front-ends) with the Managed
CA validation and issuance systems. The transition timeline also
incorporates the effort required for the Managed CAs to build out support
for scalable domain validation (both automated and manual), CAA record
checking, CT logging, and certificate management functions.  The primary
factors we heard from potential Managed CA partners are the need to scale
their operations to the certificate volumes currently sup  ported by
Symantec, the need for integration, and the time required to prepare and
process key ceremonies on both ends.  Some of the prospective Managed
CAs have proposed supporting only a portion of our volume (some by
customer segment, others by geographic focus), so we are also evaluating
options that involve working with multiple Managed CAs.



*Timing Proposal Based on Key Activities*



Based on the key activities and customer dependencies associated with the
transition (additional details provided 

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-18 Thread Steve Medin via dev-security-policy
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).

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Steve Medin via dev-security-policy
> Sent: Tuesday, July 18, 2017 2:23 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec Update on SubCA Proposal
>
> *Progress Update on SubCA RFP, Partner Selection, and Execution*
>
>
>
> Since June 1, Symantec has worked in earnest to operationalize the SubCA
> proposal outlined by Google and Mozilla and discussed in community
> forums.  The core of this proposal is to transfer the authentication and
> issuance of certificates to a set of new SubCAs that are operated by
> "Managed CAs", with the eventual end state being a move from the existing
> Symantec PKI to a modernized platform. We are providing this update to
> share our initial findings of our efforts to implement the SubCA proposal,
> and as previously posted, propose aggressive but achievable dates for
> certain aspects of the SubCA proposal.
>
>
>
> Last month, we released a Request for Proposal (RFP) that covered all
> aspects of the SubCA proposal, including key management, technical
> integration, staffing, training, compliance, support, and the end-to-end
> coordination of operations. This RFP was sent to the CAs that we felt best
> met the browser requirements and had the potential to successfully fulfill
> the scope and volume of our CA authentication and issuance activities.
>
>
>
> After receiving RFP responses, we met with the prospective Managed CAs
> to discuss and refine their proposed approach, clarify intent and answer
> questions impacting their proposals, which addressed their approach to
> and schedule for integration, staffing, compliance, support, and other
> operational aspects.  Over the last two weeks, we have continued to receive
> detailed responses from RFP respondents and hold meetings with the
> prospective Managed CAs to review their proposals in order to select the
> final Managed CA partner(s) that will be able to best execute on the plan
> proposed by Google and Mozilla. We appreciate the CAs who have replied
> and recognize that drafting the proposals required a tremendous amount
> of time and effort as part of this accelerated process.
>
>
>
> We continue to work through implementation details with our prospective
> Managed CA partners, to understand the depth of analysis that has gone
> into their development schedules and staffing plans, and to assess the
> feasibility of those plans.  We expect to complete the selection process
> within the next 2 weeks. After selecting the final Managed CA partner(s), we
> will work aggressively towards the execution of an agreement and
> integration plan.
>
>
>
> As we finalize the selection process, our development team is actively
> working towards the transition.  Currently, we are shifting from design to
> implementation of a common set of APIs across platforms to simplify the
> integration with one or more Managed CAs.
>
>
>
> Based on the RFP responses, internal planning, and discussions with RFP
> respondents to date, we are still concerned with the implementation
> timing. Based on both our own internal scoping and the RFP responses, we
> see a practical, aggressive transition being achievable between early-
> December and late-February, depending on the specific Managed CA(s) and
> the unknowns that come with an effort of this magnitude.  This timeframe
> is based on the Managed CAs' RFP responses regarding how long it will take
> to integrate our existing customer portals (front-ends) with the Managed
> CA validation and issuance systems. The transition timeline also
> incorporates the effort required for the Managed CAs to build out support
> for scalable domain validation (both automated and manual), CAA record
> checking, CT logging, and certificate management functions.  The primary
> factors we heard from potential Managed CA partners are the need to scale
> their operations to the certificate volumes currently sup  ported by
> Symantec, the need for integration, and the time required to prepare and
> process key ceremonies on both ends.  Some of the prospective Managed
> CAs have proposed supporting only a portion of our volume (some by
> customer segment, others by geographic focus), so we are also evaluating
> options that involve working with multiple Managed CAs.
>
>
>
> *Timing Proposal Based

Symantec Update on SubCA Proposal

2017-07-18 Thread Steve Medin via dev-security-policy
*Progress Update on SubCA RFP, Partner Selection, and Execution*



Since June 1, Symantec has worked in earnest to operationalize the SubCA 
proposal outlined by Google and Mozilla and discussed in community forums.  The 
core of this proposal is to transfer the authentication and issuance of 
certificates to a set of new SubCAs that are operated by "Managed CAs", with 
the eventual end state being a move from the existing Symantec PKI to a 
modernized platform. We are providing this update to share our initial findings 
of our efforts to implement the SubCA proposal, and as previously posted, 
propose aggressive but achievable dates for certain aspects of the SubCA 
proposal.



Last month, we released a Request for Proposal (RFP) that covered all aspects 
of the SubCA proposal, including key management, technical integration, 
staffing, training, compliance, support, and the end-to-end coordination of 
operations. This RFP was sent to the CAs that we felt best met the browser 
requirements and had the potential to successfully fulfill the scope and volume 
of our CA authentication and issuance activities.



After receiving RFP responses, we met with the prospective Managed CAs to 
discuss and refine their proposed approach, clarify intent and answer questions 
impacting their proposals, which addressed their approach to and schedule for 
integration, staffing, compliance, support, and other operational aspects.  
Over the last two weeks, we have continued to receive detailed responses from 
RFP respondents and hold meetings with the prospective Managed CAs to review 
their proposals in order to select the final Managed CA partner(s) that will be 
able to best execute on the plan proposed by Google and Mozilla. We appreciate 
the CAs who have replied and recognize that drafting the proposals required a 
tremendous amount of time and effort as part of this accelerated process.



We continue to work through implementation details with our prospective Managed 
CA partners, to understand the depth of analysis that has gone into their 
development schedules and staffing plans, and to assess the feasibility of 
those plans.  We expect to complete the selection process within the next 2 
weeks. After selecting the final Managed CA partner(s), we will work 
aggressively towards the execution of an agreement and integration plan.



As we finalize the selection process, our development team is actively working 
towards the transition.  Currently, we are shifting from design to 
implementation of a common set of APIs across platforms to simplify the 
integration with one or more Managed CAs.



Based on the RFP responses, internal planning, and discussions with RFP 
respondents to date, we are still concerned with the implementation timing. 
Based on both our own internal scoping and the RFP responses, we see a 
practical, aggressive transition being achievable between early-December and 
late-February, depending on the specific Managed CA(s) and the unknowns that 
come with an effort of this magnitude.  This timeframe is based on the Managed 
CAs' RFP responses regarding how long it will take to integrate our existing 
customer portals (front-ends) with the Managed CA validation and issuance 
systems. The transition timeline also incorporates the effort required for the 
Managed CAs to build out support for scalable domain validation (both automated 
and manual), CAA record checking, CT logging, and certificate management 
functions.  The primary factors we heard from potential Managed CA partners are 
the need to scale their operations to the certificate volumes currently sup
 ported by Symantec, the need for integration, and the time required to prepare 
and process key ceremonies on both ends.  Some of the prospective Managed CAs 
have proposed supporting only a portion of our volume (some by customer 
segment, others by geographic focus), so we are also evaluating options that 
involve working with multiple Managed CAs.



*Timing Proposal Based on Key Activities*



Based on the key activities and customer dependencies associated with the 
transition (additional details provided at the end of this post), we believe 
that the following adjustments to the current SubCA proposal timelines are 
appropriate and necessary. These adjustments will allow us to work toward 
deadlines that are as close as possible to the original dates and take into 
account the full scope of the required implementation efforts while 
prioritizing moving to full authentication by the Managed CAs for new 
certificates.



New Certificate Issuance: We believe the dates for transition of validation and 
issuance to the Managed CA that are both aggressive and achievable are as 
follows:

- Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);

- Managed CA performs domain validation for all new certificates by December 1, 
2017 (changed from November 1, 2017); and

- Managed CA performs full validation for all