Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
Initial partial draft of Symantec issue list
{{draft}}
This page lists all confirmed or suspected issues involving the CA "Symantec". It will be updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv].
The issues are in broadly chronological order.
==Issue XXX: Issued Certificate Directly From Root (Dec 2013 - Jan 2014)==
Symantec issued a cert to one of its customers, Pitney Bowes, that did not comply with at least one provision of the CA/Browser Forum Baseline Requirements, in that it was issued directly from a root.
This cert was a 1024-bit cert, but if it was issued in 2013, that was neither a BR nor a Mozilla policy violation, as the 1024-bit issuance deadline was 31st December 2013. It was also backdated, but that is not a BR or Mozilla policy violation either, as long as it was not done to evade a technical control. If it was in fact issued in early 2014, it would be a violation of all of these requirements, but there is no way for us to tell and so we must take Symantec's word for it. It also has a short serial number, but entropy in the serial number is a SHOULD in the relevant version of the BRs (1.1.6). It's a MUST in the Mozilla requirements (2.2), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time.
Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. However, they did not request permission to issue in advance, disclosed the issuance a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID.
Symantec disclosed this issue to Mozilla at the end of January 2014. The incident is recorded in {{bug|966350}}.
==Issue XXX: SHA-1 Issuance After Deadline (January 2016)==
Symantec issued five SHA-1 certificates after the SHA-1 issuance deadline. These were certificates requested (or enrolled) in 2015 but issued in 2016. Symantec [https://cabforum.org/pipermail/public/2016-January/006519.html reported this issue] to the CAB Forum public mailing list. They were not the only CA to have similar issues with accidental SHA-1 issuance.
==Issue XXX: SHA-1 Issuance After Deadline - 2 (February 2016)==
Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 precertificate] in February 2016. They seemed to claim, contrary to the CT RFC, that misissuance of a pre-certificate is not misissuance. (Mozilla considers that it is.) Their explanation for the incident was as follows:
<blockquote>
Following discussions with the customer who initiated this order, we have identified a technical deficiency in our system that allowed for hash algorithm modifications by a subset of customers to existing enrollments in limited circumstances, and only when pending administrator review prior to issuance. We released a patch today to add this case to our system-wide SHA1 blocking mechanisms. In addition, as an added precaution, we are evaluating an update to actively change any SHA1 orders encountered in our system to SHA256.
</blockquote>
It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem.
==Issue XXX: UniCredit Sub CA Failing To Follow BRs (April - October 2016)==
Symantec issued an unconstrained sub-CA to a company called UniCredit. 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.
Several months after this problem was discovered by Mozilla, Symantec eventually ordered them to stop issuing, but they continued, in violation of that agreement. Symantec then finally revoked their intermediate.
This incident is recorded in {{bug|1261919}}.
==Issue XXX: Cross-Signing the US Federal Bridge (July 2016)==
The US Government has an extremely complicated PKI called the Federal PKI. It has [https://bugzilla.mozilla.org/show_bug.cgi?id=478418 applied for inclusion] in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies.
Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ cross-signed] one of the root CAs in the FPKI, thereby making certificates below that root in the chain of trust be publicly trusted. This intermediate CA was not disclosed in the CCADB. When this was drawn to their attention, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/OAJD-tWBAAAJ did not revoke] the cross-sign, instead allowing it to expire (less than a month later).
==Issue XXX: Accidental Manual Signing Using SHA-1 (July 2016)==
Symantec applied to the root programs for leave to issue SHA-1 certificates for a customer. As part of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all the data except for the signature) for CAB Forum review. However, they [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ accidentally] issued real certificates - i.e. they signed the tbsCertificate data using SHA-1. They had to revoke all of the certificates. This was supposedly a manual process but it seems like the relevant instructions were either deficient or not followed.
This page lists all confirmed or suspected issues involving the CA "Symantec". It will be updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv].
The issues are in broadly chronological order.
==Issue XXX: Issued Certificate Directly From Root (Dec 2013 - Jan 2014)==
Symantec issued a cert to one of its customers, Pitney Bowes, that did not comply with at least one provision of the CA/Browser Forum Baseline Requirements, in that it was issued directly from a root.
This cert was a 1024-bit cert, but if it was issued in 2013, that was neither a BR nor a Mozilla policy violation, as the 1024-bit issuance deadline was 31st December 2013. It was also backdated, but that is not a BR or Mozilla policy violation either, as long as it was not done to evade a technical control. If it was in fact issued in early 2014, it would be a violation of all of these requirements, but there is no way for us to tell and so we must take Symantec's word for it. It also has a short serial number, but entropy in the serial number is a SHOULD in the relevant version of the BRs (1.1.6). It's a MUST in the Mozilla requirements (2.2), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time.
Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. However, they did not request permission to issue in advance, disclosed the issuance a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID.
Symantec disclosed this issue to Mozilla at the end of January 2014. The incident is recorded in {{bug|966350}}.
==Issue XXX: SHA-1 Issuance After Deadline (January 2016)==
Symantec issued five SHA-1 certificates after the SHA-1 issuance deadline. These were certificates requested (or enrolled) in 2015 but issued in 2016. Symantec [https://cabforum.org/pipermail/public/2016-January/006519.html reported this issue] to the CAB Forum public mailing list. They were not the only CA to have similar issues with accidental SHA-1 issuance.
==Issue XXX: SHA-1 Issuance After Deadline - 2 (February 2016)==
Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 precertificate] in February 2016. They seemed to claim, contrary to the CT RFC, that misissuance of a pre-certificate is not misissuance. (Mozilla considers that it is.) Their explanation for the incident was as follows:
<blockquote>
Following discussions with the customer who initiated this order, we have identified a technical deficiency in our system that allowed for hash algorithm modifications by a subset of customers to existing enrollments in limited circumstances, and only when pending administrator review prior to issuance. We released a patch today to add this case to our system-wide SHA1 blocking mechanisms. In addition, as an added precaution, we are evaluating an update to actively change any SHA1 orders encountered in our system to SHA256.
</blockquote>
It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem.
==Issue XXX: UniCredit Sub CA Failing To Follow BRs (April - October 2016)==
Symantec issued an unconstrained sub-CA to a company called UniCredit. 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.
Several months after this problem was discovered by Mozilla, Symantec eventually ordered them to stop issuing, but they continued, in violation of that agreement. Symantec then finally revoked their intermediate.
This incident is recorded in {{bug|1261919}}.
==Issue XXX: Cross-Signing the US Federal Bridge (July 2016)==
The US Government has an extremely complicated PKI called the Federal PKI. It has [https://bugzilla.mozilla.org/show_bug.cgi?id=478418 applied for inclusion] in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies.
Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ cross-signed] one of the root CAs in the FPKI, thereby making certificates below that root in the chain of trust be publicly trusted. This intermediate CA was not disclosed in the CCADB. When this was drawn to their attention, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/OAJD-tWBAAAJ did not revoke] the cross-sign, instead allowing it to expire (less than a month later).
==Issue XXX: Accidental Manual Signing Using SHA-1 (July 2016)==
Symantec applied to the root programs for leave to issue SHA-1 certificates for a customer. As part of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all the data except for the signature) for CAB Forum review. However, they [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ accidentally] issued real certificates - i.e. they signed the tbsCertificate data using SHA-1. They had to revoke all of the certificates. This was supposedly a manual process but it seems like the relevant instructions were either deficient or not followed.
