On Tuesday, June 6, 2017 at 9:03:29 AM UTC-5, Gervase Markham wrote: > 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): > > 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.
At this point, it seems reasonable to trust the current certificates that were properly CT logged and include proper SCTs, at least up until we no longer trust new certificates issued from the current infrastructure. > > 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. > It is believable that getting the new issuance infrastructure up and running could be a significant burden. The question may really become "Is it acceptable that a (possibly significant) period of time during which Symantec can issue no new / renewed certificates occur?" I note that Symantec even sets out that there is some material question as to whether there is even another participant within the qualified marketplace that could be prepared in a timely fashion to serve as the Managed CA. > 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. If we mean non-constrained SubCAs, those certainly should be subject to full WebTrust audit, whether in the scope of Symantec's audits or separately audited for the SubCA organization. Why would Symantec get a pass otherwise? > > 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. I think this question should be left to the Managed CA, with the Managed CA's understanding and acknowledgement that their own roots and trust will be held responsible for any mis-issuances detected. Let the Managed CA's own self interest set this where it actually needs to be. > > 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. If it were on behalf of any one else, the other CA would have no new requirements. Why change that? Make any new / extra burdens fall upon Symantec, not the other CA partner. > > 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. > Upon transition back to Symantec control, enforce a higher audit period then, based upon their prior misdeeds. > 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. To the extent that the audit includes supporting documentation as to facilities physical security details, etc, etc, I can see support for not distributing that widely. Is there any reason to believe that this type of audit will reveal anything beyond whether or not they are fully compliant without qualifications? I suspect they take access to their keys seriously, if for no other reason than self interest. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
