Hello Kathleen! Thank you for sharing your draft version. I have a question regarding the meaning of:
> * The latest versions of the WebTrust and ETSI audit criteria are now > required, and auditors are required to be appropriately qualified. Will you still accept ETSI TS 102 042 audits or does it mean, you will only accept ETSI EN 319 411-1 audits? Both are acceptable according to BRG 8.4. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart=siemens....@lists.mozilla.org] On Behalf Of Kathleen Wilson via dev-security-policy Sent: Mittwoch, 6. September 2017 20:23 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Draft Security Blog about v2.5 of Root Store Policy All, Here is a draft of a security blog about version 2.5 of Mozilla's Root Store Policy. I will greatly appreciate constructive feedback about it. Thanks, Kathleen == Mozilla Releases Version 2.5 of Root Store Policy == Recently, Mozilla released version 2.5 of our Root Store Policy, which continues our efforts to improve standards and reinforce public trust in the security of the Web. We are grateful to all those in the security and Certificate Authority (CA) communities who contributed constructively to the discussions surrounding the new provisions. The changes of greatest note in version 2.5 of our Root Store Policy are as follows: * CAs are required to follow industry best practice for securing their networks, for example by conforming to the CA/Browser Forum’s Network Security Guidelines or a successor document. * CAs are required to use only those methods of domain ownership validation which are specifically documented in the CA/Browser Forum’s Baseline Requirements 1.4.1. * Additional requirements were added for intermediate certificates that are used to sign certificates for S/MIME. In particular, such intermediate certificates must be name constrained in order to be considered technically-constrained and exempt from being audited and disclosed on the Common CA Database. * Clarified that point-in-time audit statements do not replace the required period-of-time assessments. Mozilla continues to require full-surveillance period-of-time audits that must be conducted annually, and successive audit periods must be contiguous. * Clarified the information that must be provided in each audit statement, including the distinguished name and SHA-256 fingerprint for each root and intermediate certificate in scope of the audit. * CAs are required to follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla's root program is coordinated, although they are not required to participate. * The latest versions of the WebTrust and ETSI audit criteria are now required, and auditors are required to be appropriately qualified. * CAs are required at all times to operate in accordance with the applicable Certificate Policy (CP) and Certificate Practice Statement (CPS) documents, which must be reviewed and updated at least once every year. * Our policy on root certificates being transferred from one organization or location to another has been updated and included in the main policy. Trust is not transferable; Mozilla will not automatically trust the purchaser of a root certificate to the level it trusted the previous owner. The differences between versions 2.5 and 2.4.1 may be viewed on Github. (Version 2.4.1 contained exactly the same normative requirements as version 2.4 but was completely reorganized.) As always, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Mozilla Security Team == _______________________________________________ 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
