RE: Online Certificate Revocation Protocol

["Carlin Covey" <ccovey@xxxxxxxxxx>]

Placing the certificate on hold and using some sort of hold instruction code
makes sense to me.  But the hold instruction code would have to refer to
some date after which new signatures are considered invalid.  That
presupposes a timestamp on the signed document, so there is a trusted
signature time to compare with the the "no new signatures after ..." time in
the hold code.  Of course, we could use the private key usage extension to
specify the time, if the CA, RA or subject of the signature certificate
knows this time when the certificate is issued.  In an earlier posting Lynn
Wheeler noted that in such a case the CA/RA functions might be combined with
the timestamping notary function.

Mark, is this similar to what you had in mind when you mentioned revoking
the private key?  That is, we want restrictions placed on validation of
signatures made with the private key based upon when the signatures were
created.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Paul Gogarty
Sent: Tuesday, June 12, 2001 8:11 AM
To: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol



In cases where keys are destroyed before their revocation date would it not
make more sense to place the certificate on hold (use a combination of
'Reason Code' and 'Hold Instruction Code' CRL entry extensions).

This allows the certificate to validate as part of a certification path or
for signature verification, but provides a date after which signatures from
the certificate should not be trusted and the encryption key should not be
used.

	Paul Gogarty
	ASN.1 Developer

	De La Rue InterClear Ltd.
	De La Rue House
	Jays Close
	Viables
	Basingstoke
	England
	RG22 4BS

	Fax: +44 (0)1256 487755
	Tel: +44 (0)7879 458416
	mailto:paul.gogarty@xxxxxxxxxxxxxxxx

	http://www.interclear.co.uk/