Issue B: 1024-bit Certificate Issued Directly From Root (Dec 2013 - Jan

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to