RE: Symantec Update on SubCA Proposal
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
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
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
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
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
> -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
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
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
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
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
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
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: Symantec Update on SubCA Proposal
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
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
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
