RE: Online Certificate Revocation Protocol

["Scherling, Mark" <[e-mail]>]

The problem is that today we have no way of determining what "hold" means.
We can suspend a certificate which means it's not available, but my
preference is to revoke a certificate if the private key is in an unknown
state, that is we think it was destroyed but there is no way of determining
if that is absolutely true.  

If you look at a lot of the cyber-thefts, a large percentage was with
insider knowledge.  It would be easy to say my key has been destroyed and
then use my key for access to something after I left the organization.  You
would have proof that the key was destroyed (I signed a piece of paper
saying so, with date and time, witnessed by my VP, etc.) yet the key was
used to gain access after the date and time.  It's not a matter of trust,
but a matter of risk management.  If my key was unknowingly compromised and
then destroyed, the key is still valid unless we revoke the key.  It is far
safer than assuming that the key was destroyed.

In the case of a CA key, I would rather revoke all keys and re-issue than
take the risk that the CA key was destroyed and no other copies exist. 

So we want to restrict the ability to use the key even if it has been
destroyed because we cannot with absolution determine that the key was
destroyed and no copies exist.  In many Subscriber Agreements and
Certificate Policies, it states that the Subscriber may back up their keys
using proper safeguards as long as they are the only ones with access.  In
the event that someone leaves a company and their private key was destroyed
prior to them leaving, the back up key may be in a sealed envelope with the
passphrase at their desk or in their filing cabinet.  I know that most of us
would never do this sort of thing but many people do.   So now you are left
with a key that has not been revoked and is still active.  Would we all not
consider this a security risk?

The bottom line is that if a private key is in an unknown state, the CA
should revoke the key.

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Tuesday, June 12, 2001 9:07 AM
To: Paul Gogarty; [e-mail]; [e-mail]
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol


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: [e-mail]
[mailto:[e-mail]]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: [phone]
	Tel: [phone]
	mailto:[e-mail]

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