Re: Online Certificate Revocation Protocol

"Nick Pope" <pope@secstan.com> Mon, 18 June 2001 18:45 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 OAA16426 for <pkix-archive@odin.ietf.org>; Mon, 18 Jun 2001 14:45:05 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5IGSo600850 for ietf-pkix-bks; Mon, 18 Jun 2001 09:28:50 -0700 (PDT)
Received: from btclick.com (mta02.btfusion.com [62.172.195.247]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5IGSlJ00845 for <ietf-pkix@mail.imc.org>; Mon, 18 Jun 2001 09:28:48 -0700 (PDT)
Received: from npwork2 ([213.123.188.89]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GF4WFV00.X5N for <ietf-pkix@mail.imc.org>; Mon, 18 Jun 2001 17:28:43 +0100
From: Nick Pope <pope@secstan.com>
To: ietf-pkix@mail.imc.org
Subject: Re: Online Certificate Revocation Protocol
Date: Mon, 18 Jun 2001 17:33:31 +0100
Message-ID: <NCBBIDOLIPNCGDJKAHCDCEMGEMAA.pope@secstan.com>
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.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
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

Re-sending due to e-mail address problems:

>I agree with Denis.  The use of a "never valid" reason code needs to be
vary
>carefully considered before be included since it provides an easy means of
a
>signatory repudiating all his signatures.
>
>Nick Pope
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Denis Pinkas
>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.


--Paul Hoffman, Director
--Internet Mail Consortium