Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
Update P
Is is true that this is a new process, and that stopping the issuance process at the point of creating TBSCertificates is unusual. While perhaps embarrassing, the risk here seems minimal given that near-identical certificates were issued and distributed a week later.
==Issue P: UniCredit Sub CA Failing To Follow BRs (April March - October 2016)==
Symantec issued an unconstrained sub-CA to a company called UniCreditas part of their GeoRoot program (see also Issue V). This company persistently issued certificates which were BR-noncompliant (e.g. missing SANs, missing OCSP URIs). During this time, they did not have the appropriate audits and Symantec were aware of this. Symantec [https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 claimed], in response to the CA Communication of March 2016, that they had disclosed to Mozilla all their intermediate CAs along with audits, but this was not true in the case of UniCredit. The [http://ca.unicredit.eu/CPS/cps.html UniCredit CPS] was also BR-noncompliant, in that it said that SANs were optional.
This incident is recorded in {{bug|1261919}}.
Because our customers are our top priority, we attempted to minimize business disruption while they transitioned by permitting UniCredit to operate only its CRL service until November 30, 2016, at which point we would revoke the UniCredit subordinate CA. In October 2016, UniCredit issued one new certificate in violation of the terms of that transition plan. Following that, Symantec promptly revoked the UniCredit subordinate CA on October 18, 2016.
</blockquote>
===Further Comments and Conclusion===
There is doubt as to whether Symantec's indulgence of UniCredit's continued incompetence is within the letter and/or spirit of the BRs and root policy. Firstly, there is the long timeline over which UniCredit was out of compliance. But even when Symantec took action, Baseline Requirements 1.4.4, Section 4.9.1.2, item 8 states that Symantec should have revoked the intermediate immediately upon removing their right to issue, unless Symantec took over the CRL and OCSP duties, which they did not.
This section of the BRs is presumably there to prevent an incompetent or untrustworthy ex-sub-CA owner from continuing to add risk to the WebPKI once their incompetence has been acknowledged.
==Issue Q: Symantec Audit Issues 2016 (December 2015 - November 2016)==
