Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
(Update B) |
(Update B again) |
||
Line 13: | Line 13: | ||
Symantec issued a cert to one of its customers that did not comply with at least one provision of both the CA/Browser Forum Baseline Requirements and Mozilla policy. It was a 1024-bit cert which expired after the end of 2013. Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. | Symantec issued a cert to one of its customers that did not comply with at least one provision of both the CA/Browser Forum Baseline Requirements and Mozilla policy. It was a 1024-bit cert which expired after the end of 2013. Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. | ||
This cert was issued directly from the root. | This cert was issued directly from the root. Symantec's [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x_vrJtv7A0Y write-up] points out that issuance from the root is permitted by [https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf version BRs 1.1.6], the version in force at the time, if 5 conditions are met, and they say they were met. | ||
This cert was backdated, but that is not a BR or Mozilla policy violation, as long as it was not done to evade a technical control. | This cert was backdated, but that is not a BR or Mozilla policy violation, as long as it was not done to evade a technical control. | ||
The cert had a short serial number. Entropy in the serial number is a SHOULD in BRs 1.1.6. 20 bits of entropy is a MUST in the Mozilla policy ([https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md version 2.2]), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time. I am told Microsoft removed the allowance for doing entropy in the Date field on 11th November 2013, so this was a violation of their policies. Symantec say that they got a verbal exception from Microsoft. | |||
Symantec did not request permission to issue in advance, they disclosed the issuance at least a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID. | Symantec did not request permission to issue in advance, they disclosed the issuance at least a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID. | ||
Line 23: | Line 25: | ||
===Symantec Response=== | ===Symantec Response=== | ||
Symantec self-reported this issuance to Mozilla [https://bugzilla.mozilla.org/show_bug.cgi?id=966350 via Bugzilla] at the end of January 2014. Even though a [https://bugzilla.mozilla.org/show_bug.cgi?id=966350#c2 question was asked] about the BR Compliance OID that the new cert asserted, they did not comment on the bug beyond the initial report. | Symantec self-reported this issuance to Mozilla [https://bugzilla.mozilla.org/show_bug.cgi?id=966350 via Bugzilla] at the end of January 2014. Even though a [https://bugzilla.mozilla.org/show_bug.cgi?id=966350#c2 question was asked] about the BR Compliance OID that the new cert asserted, they did not comment on the bug beyond the initial report. Recently, Symantec have produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x_vrJtv7A0Y longer write-up] of the incident. | ||
===Further Comments and Conclusion=== | ===Further Comments and Conclusion=== |