Response to Inaccurate Crypto-Gram Article on VeriSign Certificates

Many customers have asked us about claims made in a recent edition of the Crypto-Gram newsletter. The newsletter, which discusses two fraudulent digital certificates that VeriSign erroneously issued in January 2001, contains a number of inaccurate statements about the issue, Microsoft's response, and the integrity of Microsoft's security response process.

Microsoft stands behind its handling of the issue. Within days of being contacted by VeriSign regarding the certificates, the Microsoft Security Response Center had informed millions of customers about the issue and let them know what they could do immediately to protect their systems. Less than a week later, we delivered a security update that compensates for flaws in the certificates and prevents them from being accepted as valid. The best proof of the timeliness and quality of information Microsoft provided is the fact that virtually all of the claims made in Crypto-Gram are addressed by Microsoft Security Bulletin MS01-017, which has been available for almost a month.

The following addresses the most egregious statements in the article:

Claim: "There are a lot of details that are unclear. Some news reports claim that the certificates will expire in a year, others claim that they will be good forever" (Crypto-Gram, April 15, 2001, https://www.counterpane.com/crypto-gram-0104.html#7)
Fact: It's no mystery when the certificates will expire. The FAQ section of the bulletin provides screen shots of the certificates, and it can plainly be seen that one expires on 30 January 2002, and the other expires on 31 January 2002. This data is corroborated by information on the VeriSign web site.

Claim: "...there is no way to revoke the certificates (Windows has no CRL features). (Crypto-Gram, April 15, 2001, https://www.counterpane.com/crypto-gram-0104.html#7)

Fact: Both of these statements are simply false. There is a way to revoke the certificates - via the Certificate Revocation List (CRL) mechanism defined in the relevant industry standard, RFC 2459. And Windows does indeed have CRL features - CRL support has been available for the Windows NT family since 1998, and for the Windows 9x family since early 1999.

Claim: "Microsoft has tried to paint this problem as ... all VeriSign's fault anyway" (Crypto-Gram, April 15, 2001, https://www.counterpane.com/crypto-gram-0104.html#7)

Fact: Microsoft's focus throughout this episode has been on protecting its customers rather than assigning blame. Still, since the newsletter raises the issue, the question must be asked: if the company that issued the certificates doesn't bear the responsibility to do so correctly (and in conformance with its own Certification Practice Statement), who does? To its credit, VeriSign has owned up to the error and addressed the need to improve its processes:
Q: What happened? Did VeriSign follow normal procedures? What are [we] doing to avoid this in the future?

A: As good as our process is, we did not detect fraud at issuance - stage one. This was due to human error. We did detect fraud at stage two. We discovered the fraud during routine fraud screening. That said, we are actively implementing controls to improve our internal processes to prevent first stage failures to detect fraud. We will be adding technical controls as well as more manual checks and balances to prevent this from occurring in the future.

("Q&A for Fraudulent Authenticode Certificates March 22, 2001", https://www.verisign.com/developer/notice/authenticode/faq.html)

Claim: "Microsoft has tried to paint this problem as ... not a security vulnerability ... But if it's not a security vulnerability, why are they issuing all these security patches for Internet Explorer?" (Crypto-Gram, April 15, 2001, https://www.counterpane.com/crypto-gram-0104.html#7)

Fact: Microsoft Security Bulletin MS01-017 dealt extensively with this question, both in the Technical Discussion and in the FAQ. For example:
If there's no flaw in Microsoft software, why are you releasing new software?

There's a standard procedure that should allow VeriSign to prevent these certificates from being accepted if they're used. Microsoft products support that procedure, but a defect in construction of VeriSign code-signing certificates prevents it from being effective in this case.

Every certificate issuer periodically generates a Certificate Revocation List (CRL), which lists all the certificates that should be considered invalid. Every certificate should provide a piece of data called the CRL Distribution Point (CDP) - this data indicates the location from which the CRL can be obtained. The problem is that VeriSign code-signing certificates don't provide CDP information. As a result, even though VeriSign has added these two certificates to its current CRL, it's not possible for systems to automatically download and check it. Our update compensates for this omission in the VeriSign certificates.

(Microsoft Security Bulletin MS01-017 Frequently-asked questions)

But don't take our word for it - let the certificates speak for themselves. Immediately below is a screen shot of the Details page from one of the certificates. (The Details page for the other certificate is identical). The scroll bar notwithstanding, all of the extension fields are visible. If a CDP had been provided, there would be an extension field titled "CRL Distribution Points". There isn't one. Without this data, no system - Microsoft or otherwise - could obtain and check the CRL.