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, <go here> 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. > Rationale: Because SubCAs are established CAs, once an audit has been > done to validate the transition, the subsequent audit schedule should be > the standard yearly one, not the high-frequency 3/6 month one proposed. > > 7) Detailed Audits > > Google proposal: Symantec may be requested to provide "SOC2" (more > detailed) audits of their new infrastructure prior to it being ruled > acceptable for use. > Symantec proposal: such audits should be provided only under NDA. > Rationale: they include detailed information of a sensitive nature. > > Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
