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 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 t
Re: Final Decision by Google on Symantec
With respect to the date of distrust of symantec certificates issues before June 1, 2016, I believe Mozilla has a third option: Remove indicators of trust (green lock, etc.) on December 1, 2017 for Symantec certificates issued prior to June 1, 2016 (but do not produce interstitials and do not actively distrust until April 17th 2018). Yes, this is somewhat more engineering work for Mozilla, but it strikes the right balance between usability and safety. Why? The underlying security rationale for an earlier distrust of certificates issued prior to June 1, 2016 is that there is no CT disclosure requirement for DV/OV. The lack of transparency afforded to issuances prior to June 1, 2016, inherently makes them "riskier" to end users given Symantec's demonstrated prior practices. The above strategy properly incorporates that additional risk in the trust decision, while not introducing the much larger potential compatibility issues of full distrust of old certificates on the same day that the managed CA becomes fully operational. Mozilla could even consider waiving the above if Symantec were to log *all* (including expired and revoked) certificates from prior to June 1, 2016 [with the enforcement being: if anyone in the world provides Mozilla with a copy of even a single certificate that is not in CT after Symantec says that they are, then the above, or something more stringent, immediately goes into effect]. Symantec has even provided a fairly accurate count of how many non-expired, non-revoked certificates prior to June 1, 2016 should be present as an initial sanity check. Note this strategy may also help eliminate compatibility problems April 17th 2018, since there will have been a large period of time where indicators of trust were removed (but otherwise remaining functional). On Friday, July 28, 2017 at 2:15:43 AM UTC-4, Gervase Markham wrote: > Google have made a final decision on the various dates they plan to > implement as part of the consensus plan in the Symantec matter. The > message from blink-dev is included below. > > Most of the dates have consensus - the dates for Symantec to implement > the Managed CA infrastructure are agreed by all, and the date for final > distrust of the old Symantec PKI is agreed by Google and Mozilla (to > within a week, at any rate). I proposed November 1st 2018. Google has > gone for October 23rd 2018; in practical terms, we would implement that > using Firefox 63 (October 16th) or 64 (November 27th). > > However, there is some difference in the proposals for the date on which > browsers should dis-trust Symantec certificates issued before June 1st, > 2016. This date is significant because after that, Symantec have been > required to log all their certs to CT and so there is much better > transparency of issuance practice. I proposed December 1st 2017. Google > strongly considered late January, but have finally chosen April 17th 2018. > > We now have two choices. We can accept the Google date for ourselves, or > we can decide to implement something earlier. Implementing something > earlier would involve us leading on compatibility risk, and so would > need to get wider sign-off from within Mozilla, but nevertheless I would > like to get the opinions of the m.d.s.p community. > > I would like to make a decision on this matter on or before July 31st, > as Symantec have asked for dates to be nailed down by then in order for > them to be on track with their Managed CA implementation timetable. If > no alternative decision is taken and communicated here and to Symantec, > the default will be that we will accept Google's final proposal as a > consensus date. > > Gerv > > Forwarded Message > Subject: Re: [blink-dev] Intent to Deprecate and Remove: Trust in > existing Symantec-issued Certificates > Date: Thu, 27 Jul 2017 17:16:06 -0700 > From: Darin Fisher > To: Darin Fisher > CC: blink-dev > > > > Representing Google Chrome and the Chromium open source project, what > follows is our final proposal on this matter. > > > We’d like to first thank the blink-dev community for your input on this > discussion. After taking this input into consideration along with the > latest responses from Symantec and Mozilla, we have produced the > following proposal that is intended to be our final plan of action on > this matter. > > > Chrome 66 will distrust Symantec-issued TLS certificates issued before > June 1, 2016: > > Chrome 66 will distrust Symantec-issued TLS certificates issued before > June 1, 2016, which is tentatively scheduled to hit Canary on January > 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of > Chrome users) on April 17, 2018. Affected site operators are strongly > encouraged to replace their TLS certificates before March 15, 2018 to > prevent breakage. Although this is significantly later than our initial > proposal of August 2017 and Mozilla’s proposal for late 2017 >
Re: Symantec response to Google proposal
On Tuesday, June 6, 2017 at 10:03:29 AM UTC-4, Gervase Markham wrote: > On 02/06/17 15:53, Gervase Markham wrote: > > https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal > > I'm slightly surprised to see no engagement here. I think many of us are worn out with the poor responses from Symantec, who seem to treat this as a matter easily resolved with negotiation rather than actually addressing the underlying technical and procedural concerns. Symantec's slow responsiveness, attempt to limit community input by hosting responses outside the natural conversation threads (PDFs, blog posts that don't load on locked down browsers, etc), and apparent attempts to shield was should be a transparent process under the guise of "commercial secrets" would be cause for full loss of trust by any other CA. They have now had multiple chances to respond in an appropriate fashion and have failed to do so, so I don't see why the response here should be any different. Thus, at this point, if I were mozilla and Google, I would: 1) set a sunset date of 06/01/2018 for the ban to take effect. 2) immediately (next firefox/chrome release) add a small banner message (or similar) any time a Symantec certificate is found stating "Symantec certificates will soon be distrusted; if you are the site owner, to read more" Where go here goes to this and the intent thread @ Google. Site owners will get the message -- either directly by their own browsing, or from their customers. Note that this direct-to-user messages, while should be used sparingly, is the ~only mechanism available to browsers to make sure appropriate eyeballs see that a certificate change is needed by the site owner. I suspect it would greatly have helped with the Wosign distrust, for example. Of course the above does not preclude Symantec from getting a separate/new managed PKI (from another CA) to be able to replace certificates for customers immediately, nor does it preclude the possibility of this new PKI transitioning back to symantec control once they demonstrate they have resolved the underlying issues. But what the above does do is shift the risks from the relying parties (who are the ones with almost all the risk as symantec drags their feet), to Symantec (they either get their act together or exit the CA business). So I, for one, have no particular interest in continuing to engage in a discussion with an uncooperative party. The time for softball has ended. > Perhaps it would be > help to break it down. Symantec's specific requests for modification are > as follows (my interpretation): > > 1) Scope of Distrust > > Google proposal: existing CT-logged certificates issued after 1st June > 2016 would continue to be trusted until expiry. > Symantec proposal: all CT-logged certificates should continue to be > trusted until expiry. > Rationale for change: if transparency is enough to engender trust, that > principle should be applied consistently. This also significantly > reduces the revalidation burden. > > 2) Timeline > > Google proposal: a set of dates by which certain milestones must be > achieved. > Symantec proposal: no specific alternative dates (more info by the end > of June), but the Google dates are too aggressive. > Rationale: need to establish business relationships; capacity issues at > Managed CAs; international requirements further complicate things; the > revalidation burden is very large; writing solid code takes time. > > 3) SubCA Audit Type > > Google proposal: SubCAs are audited with the standard audits. > Symantec proposal: treat SubCAs as Delegated Third Parties and so give > them BR section 8 audits (an audit by the CA not an auditor; 3% sampling). > Rationale: none given. > > 4) Validation Task Ownership > > Google proposal: Symantec and its affiliates must not participate in any > of the information verification roles permitted under the Baseline > Requirements. They may, however, collect and aggregate information. > Symantec proposal: Symantec currently uses a 2-step process - validation > and review. Symantec should be allowed to do the first, with the SubCA > doing the second (with 100% review, not samplingh). > Rationale: reducing the burden on the SubCA, reducing the time for them > to ramp up, and (presumably) to allow the Symantec personnel to continue > to have jobs. > > 5) Use of DTPs by SubCA > > Google proposal: SubCAs may not use Delegated Third Parties in the > validation process for domain names or IP addresses. > Symantec proposal: SubCAs should be allowed to continue to use them in > situations where they already do. > Rationale: SubCAs should not be required to rejig their processes to > work with Symantec. > > 6) SubCA Audit Timing > > Google proposal: SubCAs are audited at 3 month intervals in the 1st > year, 6 months intervals in the 2nd year, and then yearly. > Symantec proposal: after the initial audit, only yearly audits should be > required. >
Re: New undisclosed intermediates
But Censys lists it as a trusted intermediate chaining to a root ( ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS: https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation With respect to Gerv's question: given the ample time to disclose intermediates, and given all CAs in the program indicated that they had, seems reasonable to immediately add undisclosed ones that are discovered to OneCRL. Other than some breakage, as already noted, main downside would seem to be potentially large growth in OneCRL. On Thursday, June 8, 2017 at 7:58:51 AM UTC-4, Kurt Roeckx wrote: > On 2017-06-08 13:31, richmoor...@gmail.com wrote: > > This one is interesting since the domain name of the CRL resolves to an RFC > > 1918 IP address. Surely that is a violation of the baseline requirements. > > > > https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca > > That seems to be a root CA. It does not mention any CRL. I don't expect > a root CA to have a CRL. I'm not sure from where crt.sh is getting the > CRL URL. > > > Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
Symantec, in previous blog posts on their site, has indicated that they will support their customers [1]. That said, it is fair point that the plan should spell out what happens if symantec does not cooperate. It seems appropriate to have the plan do what it says -- scheduled phase out of the old roots -- with the same timescale. If symantec does not step up to fill their customer needs, I am sure one or more of their competitors will [and remember all this only applies to symantec customers who need publicly trusted certs... one big appeal of the proposal is that non-public uses can remain unaffected]. As the recent Wosign/Startcom experiences teaches, though, if the CA is not cooperative, it is very important for the browsers to step in with messaging. Not sure what form this would take, since most developers I know do not use beta/nightly versions of browsers, so it would need to be something in actual releases. Perhaps a single line with orange background just below URL box that says "in one month, this site will cease to be trusted by major browsers [click here for why]", or somesuch. With the link being very clear: it is the owner of the website that needs to update their certificate. Just a thought. 1. https://www.symantec.com/connect/blogs/message-our-ca-customers "In the event Google implements its proposal, Symantec will ensure your websites, webservers or web applications continue to work across browsers." On Wednesday, May 10, 2017 at 4:11:59 PM UTC-4, okaphone.e...@gmail.com wrote: > On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham wrote: > > On 09/05/17 16:51, Gervase Markham wrote: > > > * Editing the proposal to withdraw the "alternative" option, leaving > > > only the "new PKI" option. > > > > This has now been done: > > > > https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit# > > > > > * Engagement here in m.d.s.p. with the community to refine and flesh out > > > the "new PKI" proposal, based on the Google outline but examining it and > > > enhancing it to make sure it is practical, both from an implementation > > > perspective and to reduce disruption to sites as far as possible. > > > > I would appreciate people's comments on the details of the current draft. > > Makes sense to me. > > But it does seem to assume that Symantec will cooperate with this. What > happens if they decide not to is less clear. Perhaps it would be a good idea > to indicate which steps will be taken in any case? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft further questions for Symantec
In addition to requesting disclosure of intermediates that have been (even if not currently are) able to issue server certs, and the catchall, both of which seem excellent, I encourage Mozilla to consider asking these questions as part of an implemented remedy plan. That is, put in motion Mozilla's plan of action given all the information available today, but note that certain modifications are possible should Symantec provide in responses to these queries additional information Mozilla considers useful and actionable. For example, consider executing the planned phase out of all existing symantec certs by early next year, with distrust of all existing roots at that time, and a limit on new cert lifetimes of 13 months. But should symantec become a leader in reducing cert lifetimes with the stand up of a clean PKI (cf. Eric Mill's proposal), then Mozilla would strive to (a) include the new roots by next year, and (b) accept certs with lifetime of 27 months. Or, should symantec be able to verifiably demonstrate other things (e.g. a complete map of their PKI inter-relations, and all parts that are non-BR compliant and thus should be distrusted), then the old ones might not be removed. Yes, this is harder on the coders (I sympthasize), but how much longer can the current situation (and the risks it does pose *today*) go on? On Monday, May 8, 2017 at 1:08:27 PM UTC-4, richm...@gmail.com wrote: > On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote: > > I think it might be appropriate to have a further round of questions to > > Symantec from Mozilla, to try and get some clarity on some outstanding > > and concerning issues. Here are some _proposed_ questions; feel free to > > suggest modifications or other questions, and I will decide what to send > > officially to Symantec in a few days. Please focus on formulating > > questions which would have an effect on Mozilla's view of Symantec or > > our response to the recent issues. > > How about adding a catch all: > > Are you aware of any information that might have an effect on Mozilla's view > of Symantec, our response to the recent issues or any of any further issues > that have not been disclosed to us so far? > > Cheers > > Rich. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Draft Proposal
It makes perfect sense if the game plan is to force continued delays of decisions on the part of root programs! Which appears to be exactly what is happening. After all, wait long enough, and it can be claimed that all possibly bad things would be expired, so don't distrust us, m'ok. I think the idea of giving Symantec a path to keep 27 month certificates, e.g. Coupled to the standup of a new PKI, makes a lot of sense, since going to a new PKI would help get rid of the risks associated with the present PKI, and make a big player a leader in making shorter lifetimes a reality (In the absence of a new PKI it would seem 9 mo or 13 mo validity is needed to reduce ecosystem risk). On Sunday, May 7, 2017 at 6:56:56 PM UTC-4, Eric Mill wrote: > On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > I'm posting this on behalf of Symantec: > > > > We would like to update the community about our ongoing dialogue with > > Google. > > > > Following our May 4th post, senior executives at Google and Symantec > > established a new dialogue with the intention to arrive at a new proposal > > for the community that addresses the substantial customer impact that would > > result from prior proposals. We urge Symantec customers and the browser > > community to pause on decisions related to this matter until final > > proposals are posted and accepted. > > > This call for the browser community to not make any decisions until Google > and Symantec finalize and accept a proposal completely marginalizes and > ignores both Mozilla and the broader web community. > > The "new dialogue" part also comes across as having gone over Ryan's head. > This is unfortunately consistent with Symantec's latest blog post, which > unprofessionally referred to proposals by "Mr. Sleevi" and "Mr. Markham". > These statements personalize the issue and marginalize the proposals by > casting them as individual opinions and not the views of their > organization. They also reinforce the perception that Symantec sees their > situation as the product of an unreasonable person or two and not the > result of their own errors. > > This list just spent the last two weeks focused on a large host of issues, > curated by Mozilla on their wiki and discussed by the broader community > here. So far, all Symantec has done to publicly respond to those is to send > a single email per-issue, and then not otherwise participate in the > discussion beyond blog posts. > > Posting a call to Mozilla's community list asking for Mozilla and its > community to pause while Symantec gets on the phone with senior Google > executives to work it all out is a baffling tactic. I hope Mozilla > continues to assert its stake in this process. > > -- Eric > > The intent of both Google and Symantec is to arrive at a proposal that > > improves security while minimizing business disruption across the community. > > > > We want to reassure the community that we are taking these matters and the > > impact on the community very seriously. > > ___ > > 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: [EXT] Re: Symantec: Draft Proposal
Steve, Thank you for the prompt response, and I am glad this certificate was in fact validated internally by Symantec. On Tuesday, May 2, 2017 at 6:55:13 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 > > wizard--- via dev-security-policy > > Sent: Tuesday, May 02, 2017 7:10 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: [EXT] Re: Symantec: Draft Proposal > > > > > > Also, in the responses, Symantec claims that MSC Trustgate is no longer an > > RA (but could be a reseller). I did a quick search on crt.sh for recent > > certificates that have supplied by MSC Trustgate: > > > > [link] > > > > Going back to April 2013, this is the *only* "supplied by MSC trustgate" > > certificate in crt.sh that chains off a Symantec root; all others are > > Globalsign. > > Can Symantec confirm that they vetted this (OV) certificate in-house? While > > I > > suppose MSC could supply certs from multiple CAs, I find it odd that > > everything in the logs since April 2013 is Globalsign except this one > > outlier -- > > and am concerned it means there was some mechanism for MSC to issue / > > have issued a cert off a Symantec chain -- and this concerns me given the > > higher nominal level of validation. > > MSC Trustgate is an approved reseller of Symantec certificates. They are no > longer operating as an SSL/TLS RA. This certificate was authenticated and > issued by Symantec after having been properly submitted to us by MSC > Trustgate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Draft Proposal
This seems like a very reasonable stance for Mozilla to take: strongly encourage a new Symantec PKI so they start with a clean slate, otherwise staged distrust of all existing certificates with the requirement that Symantec produce a full document/diagram of how the components of their PKI are connected so that the non-BR-compliant bits can be "chopped off" from trust via OneCRL. Given Symantec's propensity for responding right at deadlines, might I suggest that, should Symantec not choose to stand up a new PKI, that you set a reasonable deadline for the production of the document described above? Perhaps May 12th? Also, in the responses, Symantec claims that MSC Trustgate is no longer an RA (but could be a reseller). I did a quick search on crt.sh for recent certificates that have supplied by MSC Trustgate: https://crt.sh/?Identity=%25MSC+Trustgate.com+Sdn+Bhd It looks to me like MSC is now a globalsign reseller (sure, why not). But one certificate stood out: https://crt.sh/?id=68658151 Going back to April 2013, this is the *only* "supplied by MSC trustgate" certificate in crt.sh that chains off a Symantec root; all others are Globalsign. Can Symantec confirm that they vetted this (OV) certificate in-house? While I suppose MSC could supply certs from multiple CAs, I find it odd that everything in the logs since April 2013 is Globalsign except this one outlier -- and am concerned it means there was some mechanism for MSC to issue / have issued a cert off a Symantec chain -- and this concerns me given the higher nominal level of validation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Conclusions and Next Steps
I don't know about others, but I am quite disappointed by Symantec's proposed remediation plan. Intentional or not, these response seems to indicate they don't really understand the potential consequences of many of their past actions. Essentially, they promise to: 1) Have a third party audit all of their EV certs 2) Have a third party audit all of their partner certs 3) Have quarterly audits 4) Will offer certs with 3 month validity periods 5) Engage better with CAB and browser programs to help the ecosystem These steps, while no doubt appealing to Symantec and its customers, do not address the significant relying party risks introduced by their past actions, including allowing various third parties carte blanche to issue certs chaining to publicly trusted roots without meaningful oversight (issues L, W, and Y). This is compounded by apparent institutional difficulties with properly identifying the scope of problems and resolving them (e.g. why did SHA-1 Issue H not lead to procedures so Issue J didn't happen; on Issue D, why did the first set of test cert mis-issues not catch the March 2016 ones?). Further doubts as to the trustworthiness of Symantec's PKI comes from the significant lack of oversight (intentional or not) even in cases where they *knew* there were problems (e.g. Issues P,Q,T,V). In light of this history (as well as related history for other CAs discussed on this forum in the past), on what basis are relying parties supposed to conclude that "more audits" and a "promise to do better" is a sufficient response? It seems to me the existing Symantec PKI is a mess and any steps short of complete distrust of all existing roots leaves relying parties exposed to significant risk. No-one (apparently not even Symantec given demonstrated past inability to identify similar issues within their PKI) has a full view of all the past actions (e.g. cross-signs, creation of unconstrained CAs, etc.) under their existing roots; and the scope of issues here are more serious than other cases that have led to full dis-trust under Mozilla's program. The problem of course is compatibility (Symantec's own plan essentially says "yes, many bad architectural decisions were made by us and our (mostly large enterprise) clients, so we are too big to fail and you can't do drastic things"). But this does not absolve Symantec's existing PKI of their 6+ year history of poor decisions and management. So what about the following: plan a scheduled phasing out of trust in existing Symantec certificates (timeline from Google's proposal seems reasonable), but with all certificates chaining to existing roots, and the old roots themselves, distrusted in the final milestone. This may seem more extreme, but with one addition there are some attractive features that actually reduce compatibility risks (especially to non-browser facing systems), allows symantec to rearchitect their public PKI to follow practices that should help avoid complete distrusts in the future, and gives stronger assurances to relying parties: To deal with the compatibility consequences, during this timeframe, permit Symantec to generate and begin using new root CAs. These roots could/should be unidirectionally cross-signed by one or more of their existing (but to be removed) roots, so that they can begin issuing replacement certificates ~immediately for their customers from sub CAs under the new roots. The plan would then be to strive to have these new roots incorporated in the trust store by the time of the final milestone above (and given Symantec's public statements to support their customers, they would actually do this). >From the perspective of the public web PKI, this "cleans the slate", and >allows the various root programs to clearly articulate requirements under >which these new roots operate (eg mandatory disclosure and auditing of all >subCAs and cross-signed roots (and their subCAs) *technically capable* (even >if administratively constrained or constrained by technical means not >recognized by public web PKI browsers) of issuing browser trusted >certificates, CT logging, validation methods, certificate validity limits, >etc). Since these new roots don't have legacy baggage, any violations of root >program policy thus become clear cut, simplifying monitoring. If done right, this approach might even help *reduce* compatibility issues. Each server using existing Symantec certificates falls into one of three categories: 1) services solely non-browser clients (eg fixed firmware devices, apps,...) 2) services solely browser clients 3) services both 1&2 #1 should be completely unaffected by the above plan (continue to use Symantec's old PKI which is now essentially a large private PKI). #2 has three sub-categories: 2a: solely browsers managed by enterprise policy: these can be made immune to the above (and continue to use Symantec's old PKI) if the to be publicly distrusted roots can be a
