RE: Online Certificate Revocation Protocol

"Liaquat Khan" <liaquat.khan@gta.multicert.org> Thu, 14 June 2001 14:00 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 KAA29649 for <pkix-archive@odin.ietf.org>; Thu, 14 Jun 2001 10:00:29 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5EDDO006945 for ietf-pkix-bks; Thu, 14 Jun 2001 06:13:24 -0700 (PDT)
Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EDDMJ06941 for <ietf-pkix@imc.org>; Thu, 14 Jun 2001 06:13:22 -0700 (PDT)
Received: from [213.122.35.251] (helo=vaio) by carbon.btinternet.com with smtp (Exim 3.22 #9) id 15AWvN-0002su-00; Thu, 14 Jun 2001 14:12:38 +0100
Reply-To: liaquat.khan@gta.multicert.org
From: Liaquat Khan <liaquat.khan@gta.multicert.org>
To: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, madwolf@openca.org
Subject: RE: Online Certificate Revocation Protocol
Date: Thu, 14 Jun 2001 14:18:55 +0100
Message-ID: <LPBBLCKMHBKCDJGHBAJOGEHDCIAA.liaquat.khan@gta.multicert.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <99247398731102@kahu.cs.auckland.ac.nz>
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>
Content-Transfer-Encoding: 7bit

I agree a new reason code of ("never valid") has uses.  This will allow a
relying party when verifying a digital signatures using a certificate, which
when performing revocation checking is found to be on a CRL with the a new
reason code ("never valid"), to detect that the digital signature should not
be trusted even if the digital signature was produced before the time of the
revocation of the certificate.   Otherwise in theory signature produced
before the revocation will continue to be considered valid - not a good
situation for the relying party or for the CA.

However, I cannot see the need to keep such a certificate on a CRL even
after it has expired...what does this achieve?

Regards,
Liaquat

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On
Behalf Of Peter Gutmann
Sent: 14 June 2001 11:13
To: ietf-pkix@imc.org; madwolf@openca.org
Subject: Re: Online Certificate Revocation Protocol


Massimiliano Pala <madwolf@hackmasters.net> writes:
>Peter Gutmann wrote:
>>There's another revocation status which needs a way of indicating it which
is
>>somewhat trickier, I'll bring it up here in case anyone has any ideas:
>>Sometimes a cert can be issued in error, what's needed here is a
revocation
>>reason which says that not only is the cert revoked, it should never be
and
>>was never valid at any time for any reason.  You can sort of achieve this
by
>
>In this case, when will br the entry removed from the CRL ? When the
>certificate will be expired ?? Or should it be left in all future CRLs ?

Well, CMP leaves pretty much everything to CA policy so it's up to the
individual CA.  I leave it in the CRL until the cert expires anyway, but
that's just me (I'm also currently overloading the "undefined" reason code
in
the hope that, since you're not supposed to use it, it's a spare code which
can be used to mean "never valid", but it really needs its own reason code
to
indicate the true status).

Peter.