Comments inline and snipped On Mon, Mar 9, 2020 at 2:48 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> ==Meh== > * Microsec issued two certificates in 2018 with 3-year validity periods [1]. > That bug, and the related discussion, discussions Microsec's confusion but does not appear to lead to any understanding about what systemically has been changed to prevent this confusion in the future. At the time of the discussion, it was also pointed out how that confusion was unreasonable. > * CP section 1.3.2 permits 3rd party RAs, but in their BR > Self-Assessment, Microsec states that “The Trust Service Provider do not > apply third parties for RA activities.” > * CPS section 4.9.5 provides a detailed explanation of the revocation > process but fails to mention the required preliminary report to the > Subscriber and the entity who filed the Certificate Problem Report. > * CPS section 4.9.1 contains a section titled “Reasons for Revoking a > Subordinate CA Certificate operated by another CA” but in their BR > Self-assessment, Microsec states that “All Subordinate CA-s under the > Microsec roots are operated by Microsec.” > > ==Bad== > * I was unable to locate the description of email address validation > practices required by Mozilla policy section 2.2. Microsec published new > CPS version adding section 3.2.7 to resolve this issue. > * Microsec recently issued what appears to be two certificate used for > testing that violate the BRs [3][4]. They are now expired. > * CCADB currently lists 9 audit letter validation failures for Microsec. > * The root contains subject L and organizationIdentifier fields which > are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the > subCAs also exhibit this issue. > * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions > for reporting an issue such as key compromise to the CA. The Microsec > CPS’ only state that questions related to the policy may be reported via > the info in that section, and other email addresses > (“highprioritycertificateproblemrep...@e-szigno.hu”, > “revocat...@e-szigno.hu") are found in other sections of some documents. > Section 4.9.5 then states that revocation requests are only accepted at > the address listed in section 1.2, but there is no email address in this > section. > * Three EV (QWAC) certificates have been issued with an extra > subject:serialNumber field that contains what appears to be a policy OID > [6]. Only one is currently revoked. > * In comment #18 of the inclusion bug dated January 2019, Microsec > confirms that their CPS did not contain the required CAA information, > despite Microsec being a Mozilla root program member at that time. > Every one of the non-snipped incidents here (including the 3 year certs) seem to point to a systemic failure to understand and follow industry developments, either within m.d.s.p. or within the CA/Browser Forum's Baseline Requirements. That's concerning, as Microsec already operates a trusted root - https://crt.sh/?caid=778 - in Mozilla's program, and so it's not unreasonable to expect them to be following and adhering to these requirements, especially as it relates to the CP/CPS. I've highlighted similar issues, below, regarding the same systemic concerns: * The following non-conformities were listed in the 2018 BR attestation > statement [7]. (they are not defined as “major” or “minor”): > ** The TSP shall maintain dual control for performing critical functions > on > the core systems (including Root CA, intermediate CAs, archiving system, > TSA system, OCSP responders etc.) [ETSI EN 319 411-1, GEN-6.4.3-02, > OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06] > ** The TSP shall modify the web application form and the registration > interface in such a way that it is clearly indicated what kind of > information are required for the issuance of the given certificate in > accordance with the policies. Misleading information shall be avoided. > [ETSI EN 319 401, REQ-6.1-01] > and > * The following non-conformities were listed in the 2019 BR attestation > statement [9]: > ** The TSP shall not issue non-compliant test certificates from the live > environment. As this has been occurred in the past, the TSP shall > provide evidences of the changed testing procedures to avoid further > occurrence of such events. [ETSI EN 319 401, REQ-6.1-07] > ** The TSP shall review the re-keying procedure in the CPS and shall > align the CPS with the real process-es and the relating standards. [ETSI > EN 319 411-1, REG-6.2.3-02] > ** The TSP shall ensure that the reusing procedure of all data fulfills > the EVCG 11.14 and the CPS corresponds to these reusing requirements. > [ETSI EN 319 411-1, REG-6.2.3-03] > ** There are conflicts between Hungarian law and EV Guideline regarding > to the witnessing the root ca key generation by a Qualified Auditor, the > TSP must inform the CAB/Forum about this fact. [ETSI 319 411-1 > GEN-6.5.1-14], [BRG, 9.16.3], [EVCG, 8.1], [EVCG, 17.7] > ** The TSP shall present a mitigation plan to revoke and replace the > non-conforming certificates with exponent 101. [ETSI EN 319 411-1, > SDP-6.5.1-18] I certainly want to be moderate here in how much weight is placed on the audit issues. On the one hand, they represent concerns from the auditor that indicate non-compliance, and they're useful signals. On the other, too much reading into these concerns may incentivize CAs, and their auditors, from not highlighting these matters, as we've seen. The balanced approach that has been historically used is for the CA to file incident report(s) for these matters, that allow them to more thoroughly explain the reason for the finding and the steps they've taken to ameliorate those concerns. However, Microsec hasn't really availed themselves of that, so I feel like we have to take that judgement at face value. Looking at the overall pattern of issues, highlighted by Wayne's review of the CP/CPS, TUViT, and Microsec's own misissuance, I feel it's a reasonable conclusion that Microsec is not only following best practices for operating a trusted root, but also not following minimum practices, nor does it have effective procedures in to follow and adapt to changes in the ecosystem. Had there been, prior to this discussion, a clear demonstration of Microsec's commitment through active engagement. I think Kathleen rightfully called this out late last year [1]. This seems to also fit the pattern Wayne observed after his initial review [2]. At the core, I think this cuts to a deep question: As Microsec already operates a Mozilla-trusted root, fundamentally the decision to include or not include this root is, in part, a question about whether or not Microsec is organizationally capable of operating in Mozilla user's best interests. A decision to reject this root inclusion, but keep the existing root, would be inconsistent with the concerns being highlighted here. At the same time, a decision to include the root "solely" because they already have a root that is trusted seems inconsistent with the principles and objectives of this review process. Thus, at the core, this is not "just" a question about whether to include (or not) the new root, but also a question about whether the incidents, and their handling, rise to the level to consider removal or distrust (for example, a DISTRUST_AFTER) My own, personal view, wearing no hats, is that the handling to date does rise to that level of considering no longer trusting new certs, phasing out old certs, and rejecting this new root. This naturally leads to the next question: What _would_ a restoration of faith look like? Even if the above is rejected, what would it take for Microsec to demonstrate they're on a trustworthy level? Unfortunately, I think the only options are radical: radical candor, radical redesign, and a radical approach to compliance. I think it would involve the creation of new roots, new policies, and even new profiles, reimplementing everything from the ground up so that it's simple: simple to understand the policies and practices, simple to update and adjust to requirements, and simple to evaluate. And while I suspect that's fundamentally at odds with Microsec's operational models, I think seeing something from them that was clear and unambiguously implementing "best practices for 2020" would be what's needed to restore trust. And I know that's not an easy option, and it may not be worth it for Microsec to attempt and fail, but I think it's the level we should be setting for CAs. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364#c33 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364#c35 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
