H Gerv, I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates.
We have 2 customers that can issue Secure Email certificates that are not technically constrained with name Constraints (the EKU is constrained to Secure Email and ClientAuth). We'd like to propose: - All new CAs shall comply with Policy 2.5 on its effective date - All existing CAs can continue to operate in issuance mode for one year - All existing CAs may continue to operate in maintenance mode to support revocation services for up to 1 additional year (allow all 1-year certificates to expire), then the CA must be revoked. One customer operates the CA within their environment and has been doing so for several years. Even though we've been encouraging them to move back to a Name Constrained CA or a hosted service, we've been unable to set firm plans in place without a Root program deadline we can reference. Due to the nature of the company and their acquisitions, they need to keep supporting new domains so name constraints is difficult to keep up with. The other customer complies the prior words in the Mozilla policy regarding "Business Controls". We have an agreement with them where we issue them Secure Email certificates from our Infrastructure for domains they host and are contractually bound to using those certificates only for the matching mail account. Due to the number of different domains managed and fact they obtain certificates on behalf of the users, it's difficult to enforce validation of the email address. We have plans to add features to this issuance platform that will resolve this, but not in the near term. Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Thursday, June 8, 2017 11:43 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Root Store Policy 2.5: Call For Review and Phase-In Periods > > Hi everyone, > > I've made the last change I currently intend to make for version 2.5 of > Mozilla's Root Store Policy. The last task before shipping it is to assess > whether any of the changes require a phase-in period, i.e. for some reason, > they can't be applicable immediately. > > CAs and others are requested to comment, with rationale, as to why > particular changes will need a phase-in period and what period they are > proposing as appropriate. This is also an opportunity for interested parties > to > do a general final review. > > I hope to ship the policy immediately after the CAB Forum meeting in Berlin, > which is happening from the 20th to the 22nd of June. > > You can see the differences between version 2.4.1 and version 2.5 here in > diff format (click "Files Changed" and then "Load Diff"): > https://github.com/mozilla/pkipolicy/compare/2.4.1...master > > or here in a more rich format: > https://github.com/mozilla/pkipolicy/compare/2.4.1...master?short_path=b > 7447c8 > (click "Files Changed" and scroll down). > > The CCADB Policy changes are trivial and can be ignored. > > Here is my summary of what's changed that's significant (with section > numbers in brackets), although you should not rely on it to be complete: > > > 1) Certificates with anyEKU have been added to the scope. (1.1) > > 2) CAs are required to "follow industry best practice for securing their > networks, for example by conforming to the CAB Forum Network Security > Guidelines or a successor document". (2.1) > > 3) Accounts which perform "Registration Authority or Delegated Third Party > functions" are now also required to have multi-factor auth. (2.1) > > 4) CAs are required to follow, but not required to contribute to, > mozilla.dev.security.policy. (2.1) > > 5) CAs are required to use only the 10 Blessed Methods for domain > validation. (2.2) This requirement has already had a deadline set for it in > the > most recent CA Communication; that deadline is 21st July 2017. > > 6) WebTrust BR audits must now use version 2.2 or later of the audit criteria. > (3.1.1) > > 7) The ETSI audit criteria requirements have been updated to be accurate. > (3.1.2.2). ETSI TS 102 042 and TS 101 456 audits will only be accepted for > audit periods ending in July 2017 or earlier. > > 8) There are further requirements on the information that needs to be > contained in publicly-available audit information. (3.1.3) > > 9) Mozilla now requires that auditors be qualified in the scheme they are > using, unless agreed in writing beforehand. (3.2) > > 10) When CAs do their BR-required yearly update of their CPs and CPSes, > they MUST indicate this by incrementing the version number and adding a > dated changelog entry. (3.3) > > 11) The Mozilla CCADB Policy has been merged into the Root Store Policy, > but the requirements have not changed. (4.1/4.2) > > 12) CA are required at all times to operate in accordance with the applicable > CP and CPS. (5.2) > > 13) The requirements for what constitutes a TCSC for email have been > reformed to actually make some sense - the cert now has to have meaningful > technical constraints on rfc822Name. (5.3.1) > > 14) New intermediates must be disclosed in the CCADB within a week. > (5.3.2) > > 15) Requirements for revocation are now delegated to the BRs rather than > being explicitly enumerated. (6) > > 16) Section 7.4 ("Transfers") has been replaced by a new section 8 which > requires CAs to notify of various operational changes. This is a merge-in of > text equivalent to the existing Root Transfer Policy which was documented > on our wiki. (8) > > > Gerv > > _______________________________________________ > 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
