full-disclosure - PGP vs. certificate from Verisign

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: yossarian at planet.nl (yossarian)
Subject: PGP vs. certificate from Verisign

From: "Jason" <security@...enik.com>
To: "yossarian" <yossarian@...net.nl>
Cc: "Evans, TJ (BearingPoint)" <tjevans@...ringpoint.net>;
<full-disclosure@...ts.netsys.com>
Sent: Saturday, May 10, 2003 9:55 PM
Subject: Re: [Full-Disclosure] PGP vs. certificate from Verisign

>
> yossarian wrote:
> > What I wonder - will Verisign have set up CRL servers yet? Remember the
IE
> > problem when someone got hold of MS certificates? The MS-fix was
> > blacklisting them locally, the real problem was that there was no
revocation
> > servers. Then again, how many concurrent connections would they get if
MS
> > sent out a critical update?
> >
> > So - stick to PGP - forget about PKI.
> IIRC, the problem was not that Verisign could not revoke the keys it was
> that IE had no way of checking the revocation status, It was a MS
> implementation problem not a problem with the issuing authority. This
> has been resolved in IE ( in some places ) and you can now enable the
> revocation checking however it is not enabled by default.
>
> 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."

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.

----- Original Message -----