On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. Perhaps it would be > help to break it down. Symantec's specific requests for modification are > as follows (my interpretation): > I suspect many of us are a bit exhausted by the discussion :-). Particularly since at this point it feels like there's some divergence between our goals of protecting security and not breaking the web. It's clear that Symantec's actions for a much smaller CA would have resulted in complete distrust (perhaps over time). That's not being pursued because Symantec is too big too fail. I'll try to engage on some specific points. > > 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. > Transparency is not a magic solution to trust, though it is helpful. We know that it primarily acts as a canary-in-the-coalmine, not perfect coverage. Distrusting older certs issued under a less strict validation regime makes sense. > > 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. > > I'm concerned that a lack of commitment to any particular date reflects a lack of urgency for this process. Fundamentally, the legacy Symantec PKI reflects risk for relying parties. Taking additional months or years to move away from it is all time that RPs bear that risk. > 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 > Alex _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
