Message-ID: <3EBD64FE.1010803@brvenik.com>
From: security at brvenik.com (Jason)
Subject: PGP vs. certificate from Verisign


[snip]
>>
>>Google provided a good place to brush up on the incident.
>>http://www.amug.org/~glguerin/opinion/revocation.html
> 
> Quite untrue - see the impressive paper of Kurt Seifried on the Topic -
> Ending Trust in Certificates
> (http://www.developer.com/tech/article.php/772511)
> 
>>From the security bulletin issued by Microsoft:
> 
> "The certificates could be used to sign programs, ActiveX controls, Office
> macros, and other executable content. Of these, signed ActiveX controls and
> Office macros would pose the greatest risk, because the attack scenarios
> involving them would be the most straightforward. Both ActiveX controls and
> Word documents can be delivered via either web pages or HTML mails. ActiveX
> controls can be automatically invoked via script, and Word documents can be
> automatically opened via script unless the user has applied the Office
> Document Open Confirmation Tool.
> VeriSign has revoked the certificates, and they are listed in VeriSign's
> current Certificate Revocation List (CRL). However, because VeriSign's
> code-signing certificates do not specify a CRL Distribution Point (CDP), it
> is not possible for any browser's CRL-checking mechanism to download the
> VeriSign CRL and use it. Microsoft is developing an update that rectifies
> this problem. The update package includes a CRL containing the two
> certificates, and an installable revocation handler that consults the CRL on
> the local machine, rather than attempting to use the CDP mechanism."
> 

The revocation path was clearly obtainable and verifiable. There was no 
way implemented for this to be verified in the MS Crypto API. 
http://crl.verisign.com/

> So MS had not built their software correctly, agree. But this is NOT the
> real issue. The blame is on MS in this one - hey, that's normal, we allways
> do that - BUT - read carefully here: <snip>  Verisign's code signing
> certficates do not specify a CDP.</snip> So had the MS code worked, there
> still would not have been a CDP. Like your link says: "[...] no Microsoft
> software is capable of automatically obtaining the Certificate Revocation
> List (CRL) listing those two bogus certificates, because there's no
> revocation infrastructure. " i.e. no CDP. Since Verisign is the issuer -
> they must control or at least specify the CRL distribution Point. This is
> the joke of X509 PKI - they don't exist. So you now can enable the checking
> in MS code, hurrah!, but the CDP's still do not exits, so it will not check
> anything. Maybe good enough for you, not for me.
> 

They do exist and have... http://crl.verisign.com/

They are clearly obtainable and the location should have been known and 
used by MS when deciding to include the CA certs in the browser and 
creating the CryptoAPI. The fact that the CA certs are included in the 
software is not good enough for me, you have to read the CPS, know the 
liabilities, and then accept them IMHO. BUT that makes all this crypto 
stuff hard to use. I think we are better off than we were but not as 
good off as we should be.

Of course, there are a ton of other arguments that can be had about 
this, it is crypto ya know... but the standard and accepted practice was 
not followed by the company that made the decision to include and 
provide this inhereted trust and then incorrectly relied on the 
infrastructure it broke.

Powered by blists - more mailing lists