RE: Online Certificate Revocation Protocol

Santosh Chokhani <chokhani@cygnacom.com> Tue, 12 June 2001 20:54 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 QAA24458 for <pkix-archive@odin.ietf.org>; Tue, 12 Jun 2001 16:54:23 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CK6cg14553 for ietf-pkix-bks; Tue, 12 Jun 2001 13:06:38 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CK6ZJ14548 for <ietf-pkix@imc.org>; Tue, 12 Jun 2001 13:06:36 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <MYXH0ASH>; Tue, 12 Jun 2001 16:06:31 -0400
Message-ID: <8D7EC1912E25D411A32100D0B76953978DF54B@scygmxs01.cygnacom.com>
From: Santosh Chokhani <chokhani@cygnacom.com>
To: "Scherling, Mark" <mscherling@rsasecurity.com>, Santosh Chokhani <chokhani@cygnacom.com>, thayes@netscape.com
Cc: Ietf-Pkix <ietf-pkix@imc.org>
Subject: RE: Online Certificate Revocation Protocol
Date: Tue, 12 Jun 2001 15:56:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F379.C5B37A00"
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>

Mark:
 
I think if the certificate issuing authority trusts that the subject key is
truly destroyed, I have not seen any cogent argument on this list yet for
revoking the certificate.  All I hear is:
 
1.  It is safe thing to do.
2.  Well we can use trusted time stamp or notary to get around the denial of
service
 
I see no particular reason for revocation in the case of a destroyed key.
Bob Juneman ha made the most cogent point that for private decryption key,
if there is no key recovery, you may want to revoke so that others do not
use the public key since the subject can not use the private key.
 
Rest of the discussion is NOT related to key being destroyed, but related to
not trusting the key being destroyed, not trusting the subject, or trying to
over-design the PKI.
 
I will give you one thing, it is always safe to revoke any key, if you do
not care about denial of service.
 

-----Original Message-----
From: Scherling, Mark [mailto:mscherling@rsasecurity.com]
Sent: Tuesday, June 12, 2001 3:31 PM
To: 'Santosh Chokhani'; thayes@netscape.com; Scherling, Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol


Sorry bad example in that leaving an organization should automatically
trigger a revocation of your certificate.  But, if you are an administrator
and you know that the key was destroyed and had other pressing things, you
may be tempted to forget despite the fact that it states that in your
policies and procedures.  Is it not true that human error is the cause in
most security breaches?
 
Then let me paint you another scenario, the VP gives his secretary (never
happens :-) her keys and access to her e-mail and accounts to handle routine
correspondence.  If the VP 's key is accidentally destroyed, is there
another copy?  Who has access to it?  If the VP stays and the secretary
leaves, is there a security risk?  I guess I'm just a little to paranoid.
 
Cheers
 

-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
Sent: Tuesday, June 12, 2001 11:57 AM
To: thayes@netscape.com; Scherling Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol



I agree with "thayes". 



-----Original Message----- 
From: thayes@netscape.com [ mailto:thayes@netscape.com
<mailto:thayes@netscape.com> ] 
Sent: Tuesday, June 12, 2001 2:50 PM 
To: Scherling Mark 
Cc: Ietf-Pkix 
Subject: Re: Online Certificate Revocation Protocol 



Mark, 

In this message you use the phrases "after I left the organization" and 
"someone leaves the company". This tells me that your affiliation has 
changed, and therefore any certificate you hold indicating that 
affiliation should be revoked.  This has nothing to do with whether the 
key has been destroyed. 

Using the destruction of the key as a replacement for revocation is not 
a good idea for the reasons you give.  However, I see no requirement to 
revoke a certificate for a destroyed key if the subject is otherwise in 
good standing. 

Terry 

Scherling, Mark wrote: 

>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:ccovey@cylink.com <mailto:ccovey@cylink.com> ] 
>Sent: Tuesday, June 12, 2001 9:07 AM 
>To: Paul Gogarty; Lynn.Wheeler@firstdata.com; mscherling@rsasecurity.com 
>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: owner-ietf-pkix@mail.imc.org 
>[ mailto:owner-ietf-pkix@mail.imc.org <mailto:owner-ietf-pkix@mail.imc.org>
]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@interclear.co.uk
<mailto:paul.gogarty@interclear.co.uk>  
> 
>       http://www.interclear.co.uk/ <http://www.interclear.co.uk/>  
>