Issue B: 1024-bit Certificate Issued Directly From Root (Dec 2013 - Jan 2014)
The customer in question informed us of an issue in December 2013 that threatened to seriously disrupt their primary business, and they sought our assistance. The customer's non-browser implementation required a certificate that was back-dated to support its boot phase, not chained through an intermediate, and that used a 1024-bit key. This would replace a similar certificate that was due to expire on December 31, 2013. The BRs in effect at the time (1.1.6) allowed for issuance directly from a root if five criteria were met, which occurred in this case. As the client and server required a back-dated certificate during initial boot phase communication, back-dating was a necessary action in order to prevent serious business interruption during their peak business. While the inclusion of our BR OID was an oversight, it was a rule violation rather than a source of material risk and, as such, did not materially cause harm. The lack of adequate entropy in the serial number was not a BR violation at the time (it was a SHOULD). While this lack of adequate entropy in the serial number was a violation of Microsoft's root policy requirements, the manager of Microsoft's root program granted us a verbal waiver. In order to be granted a verbal waiver by Microsoft, we engaged directly with them to discuss this matter. However, we did not engage the broader browser community due to the time pressure around the holiday. We seriously weighed the security risks, and we believed that issuance of this cert didn't impose risk on anyone but this specific customer, who was willing to accept it. Further, it's important to understand that this action did not threaten browser users, as the site wasn't used by browsers. We stand by our decision to help our customer safeguard their business in this instance, in a risk responsible manner when they needed us most. We didn't immediately disclose the issuance due to a contractual obligation to protect the customer's privacy, which remains in force. We discussed this obligation with our customer. In line with our commitment to disclosing these events to the web security community with as much transparency as possible, we posted our announcement on a Mozilla bug report on February 1, 2014, without using our customer's name.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
