RE: Online Certificate Revocation Protocol

"Liaquat Khan" <liaquat.khan@gta.multicert.org> Mon, 18 June 2001 12:35 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 IAA05210 for <pkix-archive@odin.ietf.org>; Mon, 18 Jun 2001 08:35:58 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5IBocA18245 for ietf-pkix-bks; Mon, 18 Jun 2001 04:50:38 -0700 (PDT)
Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5IBoaJ18241 for <ietf-pkix@imc.org>; Mon, 18 Jun 2001 04:50:36 -0700 (PDT)
Received: from [213.122.143.72] (helo=vaio) by protactinium with smtp (Exim 3.22 #9) id 15BxY2-0005BH-00; Mon, 18 Jun 2001 12:50:26 +0100
Reply-To: liaquat.khan@gta.multicert.org
From: Liaquat Khan <liaquat.khan@gta.multicert.org>
To: Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: RE: Online Certificate Revocation Protocol
Date: Mon, 18 Jun 2001 12:56:54 +0100
Message-ID: <LPBBLCKMHBKCDJGHBAJOIEJGCIAA.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <3B2DC2BA.49DF4CFA@bull.net>
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 with what you are saying Denis, but the scenario I was painting was
slightly different.  Imagine a digital signature which is being verified for
the first time by a relying party.  The relying party checks the relevant
CRL and realises that the certificate is revoked.  However the signature was
produced before the revocation occurred.  It would be nice for the CA to
indicate in the CRL within the reason code that the certificate was never
valid.  So signatures performed even before the revocation should not be
trusted.

Regards,
Liaquat


-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
Sent: 18 June 2001 09:59
To: liaquat.khan@gta.multicert.org
Cc: ietf-pkix@imc.org
Subject: Re: Online Certificate Revocation Protocol

Liaquat,

> 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.

This is the reverse situation. If a signature was tested to be valid e.g. in
June 2000 and the certificate was revoked for any reason e.g. in May 2001,
then the signature tested good in June 2000, shall continue to be valid,
otherwise it would not be a good situation for relying parties.

Denis

> 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.