RE: Online Certificate Revocation Protocol

Hal Lockhart <hal.lockhart@entegrity.com> Wed, 13 June 2001 21:22 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01961 for <pkix-archive@odin.ietf.org>; Wed, 13 Jun 2001 17:22:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DKjQq07227 for ietf-pkix-bks; Wed, 13 Jun 2001 13:45:26 -0700 (PDT)
Received: from indy.gradient.com (root@indy.gradient.com [192.92.110.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DKjOJ07223 for <ietf-pkix@imc.org>; Wed, 13 Jun 2001 13:45:25 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id QAA14900; Wed, 13 Jun 2001 16:45:22 -0400 (EDT)
Received: by BIGBIRD with Internet Mail Service (5.5.2650.10) id <LBJC4B1D>; Wed, 13 Jun 2001 16:49:43 -0400
Message-ID: <899128A30EEDD1118FC900A0C9C74A3401033B3A@BIGBIRD>
From: Hal Lockhart <hal.lockhart@entegrity.com>
To: 'Tony Bartoletti' <azb@llnl.gov>, pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, marcnarc@rsasecurity.com
Subject: RE: Online Certificate Revocation Protocol
Date: Wed, 13 Jun 2001 16:49:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> Does this relate to why the "emergency CRL" published after the bogus 
> Microsoft code-signing certs were issued was not a "real CRL"?  I 
> understood that Microsoft supported one form of "CRL 
> mechanism" while they 
> routinely employed certificates incompatible with that 
> mechanism, and that 
> was the reason they cold not "just revoke" the (bad) 
> certificates that were 
> issued.

According to this:

http://amug.org/~glguerin/opinion/revocation.html

the problem is that Microsoft software will only find CRLs specified in the
CRL Distribution Point extension in the certificate. Verisign does not use
this method. Since the use of this field is optional and Versign has been
operating since before the field was even defined, it is debatable who is to
blame for this situation.

Apparently Micorsoft's "fix" was to hotwire a special CRL, containing just
these two certs into their products.

Hal