Here's what is currently in the bug... https://bugzilla.mozilla.org/show_bug.cgi?id=1405862 ~~ As per Bug #1403549 the PSCProcert certificate will be removed from Mozilla’s Root Store due to a long list of problems and the way that PROCERT responded to those problems (and to previous CA Communications). For details about the problems, see Bug #1391058 and https://wiki.mozilla.org/CA:PROCERT_Issues
The purpose of this bug is to record the action items that PROCERT must complete before their certificate may be included as a trust anchor in Mozilla’s Root Store again. PROCERT may apply for inclusion of a new certificate[1] following Mozilla's normal root inclusion/change process[2], after they have completed all of the following action items. 1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla's CA Certificate Policy and the CA/Browser Forum's Baseline Requirements. The list must be provided in this bug, and accepted by Mozilla as reasonable remediation. 2. Implement the changes, and update their CP/CPS to fully document their improved processes. 3. Provide a reasonably detailed[4] public-facing attestation from a licensed auditor[3] acceptable to Mozilla that the changes have been made. This audit may be part of an annual audit. 4. Provide auditor[3] attestation that a full performance audit has been performed confirming compliance with the CA/Browser Forum's Baseline Requirements. This audit may be part of an annual audit. Notes: [1] The new certificate (trust anchor) may be cross-signed by the removed certificate. However, the removed certificate may *not* be cross-signed by the new certificate, because that would bring the concerns about the removed certificate into the scope of the new trust anchor. [2] Mozilla's root inclusion/change process includes checking that certificates in the CA hierarchy comply with the CA/Browser Forum's Baseline Requirements. [3] The auditor must be an external company, and approved by Mozilla. [4] “detailed” audit report means that management attests to their system design and the controls they have in place to ensure compliance, and the auditor evaluates and attests to those controls. This assertion by management - and the auditor's independent assessment of the factual veracity of that assertion - will help provide a greater level of assurance that PROCERT has successfully understood and integrated the BRs. ~~ I could add a comment to the bug saying: ~~ To be clear… - This PSCProcert certificate will be removed, and the CA has to re-apply for inclusion of the new certificate through Mozilla’s application process as described here: https://wiki.mozilla.org/CA/Application_Process#Process_Overview However, the CA must not re-apply until all of the listed actions have been completed, related documents provided in this bug, and resulting documents/audits approved by Mozilla in this bug. - Action #3 must not start until Action #1 and Action #2 are done, and the resulting documents approved by Mozilla in this bug. - As with all root inclusion applications, the new CA hierarchy, processes, issued certificates, CP/CPS, BR Self Assessment, and audits must fully comply with Mozilla’s Root Store Policy and the CA/Browser Forum’s Baseline requirements. Otherwise, there will be further delay. ~~ Does that make it clear enough that this is not something to be rushed? And that the items each need to be approved by Mozilla in the bug? I'm not fond of the idea of stating time delays up front, when our application process is by-design very slow and cumbersome already. (Just ask the CAs who have been waiting for over a year for the discussion of their root inclusion/update requests to start.) I think the "get it right or face delay" concept is already a standard part of our application process. Action #3 already requires an audit statement about the changes. I'm not comfortable with the idea of having an auditor report to Mozilla and not the applicant, because I would suspect that might require some contractual agreements and/or NDAs, and I do not sign contractual agreements or NDAs with CAs. Thanks, Kathleen _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
