Subject: RE: Online Certificate Revocation Protocol

From: Santosh Chokhani <[email-masked]>
Date: Wed, 13 Jun 2001 21:48:00 -0400

Jim:
 
Please see comments in-line.

-----Original Message-----
From: jim [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 10:10 AM
To: Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

I have to jump in again.  Mark is correct.  Remember that we are talking a
Certification Revocation List (CRL).  This is vastly different than a
Compromised Key List (CKL).  We place a certificate on the CRL because there
is a larger problem other than just the signing key.  If the token set is
damaged or destroyed (this is a good place to insert Bob's reflection on
bent keys), the cert needs to be added to the CRL.  If there is some way to
ensure that only a keyset is damaged, the cert can be rekeyed so that
service for the DN continues.  It specifically does come back to the concern
of knowing what is considered destroyed and what is considered bent.  Since
I have not seen the equivalent of a CKL in the IETF world, I have to assume
that the only way to truly cancel usage of a key is either to put the cert
on the CRL or to rekey the cert so that the old key is no longer valid.  The
question becomes how to demonstrate that a key has been invalidated without
invalidating the DN or cert. 
[Santosh Chokhani] Why do you want to claim a destroyed key is invalid?  As
you know a subscriber or an authority will stop using a private key well
before the expiration of public key certificate used for signature
verification.  But, absent trusted time stamp, PKIX does NOT recommend use
of private key validity period.  So, just because key is not usable any
more, you should revoke it.  Besides if the subject is a CA and issued
numerous certificates, revoking CA's key will cause unneeded Denial of
Service.  BTW, even if you had trusted time stamp or notary, unless get
certificates notarized, revoking CA's public key certificate will either
cause denial of service or will not protect against a security breach.  Here
is the scenario.  If the you put the CA on the revoked list, all the
certificates issued have been invalidated for no reason.  If you apply the
logic that you will use "invalidity date" CRL: extension and match against
the certificate issuance time (let us say notBefore date), if the key was
truly in wrong hands, they will issue bogus certificates with pre-dated
notBefore date. 

I think Santosh and I agree that the question is one of trust as to whether
the key is truly destroyed as opposed to being unusable to the user,
[Santosh Chokhani] I am not sure we agree.  I think certificate need not be
revoked if the key is destroyed.  Now if the CA stops trusting the holder of
the private key, that is a different matter.

  but the issuing authority still has the responsibility for making that
determination and if needed, revoking the cert to invalidate the key.  There
is a fine line between what happens technically and what needs to happen
procedurally.  Thus, I still side with Mark and the proponents of
transaction notarization (accomplishable through a retrievable audit trail)
as a better, more secure process.
[Santosh Chokhani] I do not care buy that PKI is useless with trusted time
or notary service.

   I am not arguing about what needs to happen as far as the technical
capability of key management, but from the risk mitigation standpoint, which
is what business needs to deal with.  They need to have an electronic system
that is as inherently secure as their paper system or PKI will never get off
the ground. 

Jim 

Santosh Chokhani wrote: 

 Please see responses in-line. 

-----Original Message----- 
From: Scherling, Mark [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 4:30 PM 
To: 'Santosh Chokhani'; Scherling, Mark; [email-masked] 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol 
 
Hi Santosh, I'm not sure why you would think that revoking a certificate
would result in a denial of service?  If your key has been destroyed and I
want to use your public key to send you a message, you cannot read it.  I
will assume you have received the message since there is no other indication
(CRL or OCSP response). Unless you tell me otherwise and then I may think
that you are denying receipt of my messages.   I'm assuming that we have an
agreement that the messages we are sending are confidential and sensitive
and require encryption and signing. 
[Santosh Chokhani] If some thing has been signed and subsequently the
private key is destroyed, the public key can still be used to verify the
signature, if the key was not revoked.  I do not want to get into the time
stamp protocol since I want a PKI to function to some degree without
"trusted time stamp".  Now, imagine that an intermediate CA key is
destroyed.  There is no need to revoke the CA key and invalidate all the
certificates issued by the CA.  I realize that the CA can generate a new key
and re-issue all the certificates, but this work need not be done.  In
short, the denial of services comes from revoking a certificate that is
perfectly fine. I also don't understand why you would not want to revoke a
key if it was destroyed? 
[Santosh Chokhani] I do not understand what the need to revoke the
certificate is?If I cannot use my key to sign or decrypt or gain access to a
service then what is the value of that key to me? 
[Santosh Chokhani] You are right in the decryption scenario, but as stated
earlier not right in the signature scenario. If a key is revoked, it is
placed on a CRL until the key expires.  The key can no longer be used for
signing 
[Santosh Chokhani] But what about what was signed before, unless you
integrate trusted time stamp and revamp the X.509 and PKIX path validation
to account for time and trusted time, legitimate signatures will be
rejected. and as Bob pointed out others cannot use the public key to encrypt
messages to the key holder.In my experience, most users forget their pass
phrase (be it userid and password or key and pass phrase).  If the user
destroys their key at this point, what is the purpose of keeping the key?
Why would you not revoke the key?Sorry to burden you but could you explain
to me why you think revoking a certificate is a denial of service? 
-----Original Message----- 
From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 12:56 PM 
To: Scherling, Mark; Santosh Chokhani; [email-masked] 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol 

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
serviceI 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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 3:31 PM 
To: 'Santosh Chokhani'; [email-masked]; 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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 11:57 AM 
To: [email-masked]; Scherling Mark 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol 
 
I agree with "thayes". 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
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:[email-masked] <mailto:[email-masked]> ] 
>Sent: Tuesday, June 12, 2001 9:07 AM 
>To: Paul Gogarty; [email-masked]; [email-masked] 
>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: [email-masked] 
>[ mailto:[email-masked] <mailto:[email-masked]>
]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:[email-masked]
<mailto:[email-masked]>  
> 
>       http://www.interclear.co.uk/ <http://www.interclear.co.uk/>  
>

---

From: jim <[email-masked]>
Date: Thu, 14 Jun 2001 07:42:35 -0400

Comments in line...

Santosh Chokhani wrote:

>  Jim:Please see comments in-line.
>
>      I have to jump in again.  Mark is correct.  Remember that we are
>      talking a Certification Revocation List (CRL).  This is vastly
>      different than a Compromised Key List (CKL).  We place a certificate
>      on the CRL because there is a larger problem other than just the
>      signing key.  If the token set is damaged or destroyed (this is a
>      good place to insert Bob's reflection on bent keys), the cert needs
>      to be added to the CRL.  If there is some way to ensure that only a
>      keyset is damaged, the cert can be rekeyed so that service for the
>      DN continues.  It specifically does come back to the concern of
>      knowing what is considered destroyed and what is considered bent.
>      Since I have not seen the equivalent of a CKL in the IETF world, I
>      have to assume that the only way to truly cancel usage of a key is
>      either to put the cert on the CRL or to rekey the cert so that the
>      old key is no longer valid.  The question becomes how to demonstrate
>      that a key has been invalidated without invalidating the DN or cert.
>
>      [Santosh Chokhani] Why do you want to claim a destroyed key is
>      invalid?
>

I do not want to claim that a destroyed key is invalid.  What I believe needs to
happen is recognition that the CA is the one to make the decision as to whether
the key is destroyed, not the user.  If, for instance, I am using a system with
a hard token, if the key is run over by a car and will not be usable, there is
still the remains of the key to be turned over to the CA and the CA can make the
decision.  If the key is a software token, there is no such manner of
determining that the key is truly destroyed by the average PKI user.  As such,
why allow a user to determine whether the key is destroyed?  All I think needs
to happen is recognize that this is a CA decision and let the CA take the
appropriate precautions in accordance with the CP/CPS for the system.

>       As you know a subscriber or an authority will stop using a private
>      key well before the expiration of public key certificate used for
>      signature verification.  But, absent trusted time stamp, PKIX does
>      NOT recommend use of private key validity period.  So, just because
>      key is not usable any more, you should revoke it.  Besides if the
>      subject is a CA and issued numerous certificates, revoking CA's key
>      will cause unneeded Denial of Service.  BTW, even if you had trusted
>      time stamp or notary, unless get certificates notarized, revoking
>      CA's public key certificate will either cause denial of service or
>      will not protect against a security breach.  Here is the scenario.
>      If the you put the CA on the revoked list, all the certificates
>      issued have been invalidated for no reason.  If you apply the logic
>      that you will use "invalidity date" CRL: extension and match against
>      the certificate issuance time (let us say notBefore date), if the
>      key was truly in wrong hands, they will issue bogus certificates
>      with pre-dated notBefore date.
>
>      I think Santosh and I agree that the question is one of trust as to
>      whether the key is truly destroyed as opposed to being unusable to
>      the user,
>      [Santosh Chokhani] I am not sure we agree.  I think certificate need
>      not be revoked if the key is destroyed.  Now if the CA stops
>      trusting the holder of the private key, that is a different matter.
>
Again, here is the decision point.  Does the CA make the trust decision?  I
think so, and if that is the case, the CA should be endowed with the final
decision as to whether the key is destroyed, not the user.  This takes us back
to Bob J.'s question about bent keys, which I totally agree with.  Again, it
needs to be a CA decision in accordance with a CP/CPS.

>
>
>      but the issuing authority still has the responsibility for making
>      that determination and if needed, revoking the cert to invalidate
>      the key.  There is a fine line between what happens technically and
>      what needs to happen procedurally.  Thus, I still side with Mark and
>      the proponents of transaction notarization (accomplishable through a
>      retrievable audit trail) as a better, more secure process.
>      [Santosh Chokhani] I do not care buy that PKI is useless with
>      trusted time or notary service.
>
Useless no, but risk mitigation of possible court action is critical in business
depending on the value of the transaction and criticality of the information
being passed, so there is reason to have at a minimum an audit trail that no
only indicates the computer event that takes place, but also what data or
transfer of funds occurred with that transaction.  Whether this is done by
timestamping and notarization or with the persistent proof audit log offered by
Conclusive Logic, Inc., is a matter for each enterprise to decide, but we as
technologists need to let that be a business decision, not try to make it for
them by saying, "You don't need to do it, so we won't include the capability."

PKI systems need to be designed to support the enterprise business model and the
security managers at an enterprise define the CP/CPS for that system with all of
their security issues being invoked.  Thus, it makes sense for the CA
responsible for issuing authenticatable certificates to users to cover the types
of transactions the business wants to perform to be the single decision maker in
enforcing CP/CPS policy and procedures in the case of determining whether a key
is truly destroyed.  Most users do not have that capability and the burden
should not be put on them.  Those users who do have that capability should be
more capable of accurately reporting to the CA that the key was truly
destroyed.  Then the CA, working with the Security Manager, can make the
appropriate decision that implements the policies and procedures that were
designed for the system.  Obviation of the security policies and procedures
reduces the secure nature of the PKI, which is why it was originally
implemented.  If we reduce the secureness that is offered by the PKI, we
certainly reduce the PKI market.

>
>
>        I am not arguing about what needs to happen as far as the
>      technical capability of key management, but from the risk mitigation
>      standpoint, which is what business needs to deal with.  They need to
>      have an electronic system that is as inherently secure as their
>      paper system or PKI will never get off the ground.
>
>      Jim
>
>      Santosh Chokhani wrote:
>
>     >      From: Scherling, Mark
>     >      [mailto:[email-masked]]
>     >      Hi Santosh, I'm not sure why you would think that
>     >      revoking a certificate would result in a denial of
>     >      service?  If your key has been destroyed and I want to
>     >      use your public key to send you a message, you cannot
>     >      read it.  I will assume you have received the message
>     >      since there is no other indication (CRL or OCSP
>     >      response). Unless you tell me otherwise and then I may
>     >      think that you are denying receipt of my messages.   I'm
>     >      assuming that we have an agreement that the messages we
>     >      are sending are confidential and sensitive and require
>     >      encryption and signing.
>     >      [Santosh Chokhani] If some thing has been signed and
>     >      subsequently the private key is destroyed, the public
>     >      key can still be used to verify the signature, if the
>     >      key was not revoked.  I do not want to get into the time
>     >      stamp protocol since I want a PKI to function to some
>     >      degree without "trusted time stamp".  Now, imagine that
>     >      an intermediate CA key is destroyed.  There is no need
>     >      to revoke the CA key and invalidate all the certificates
>     >      issued by the CA.  I realize that the CA can generate a
>     >      new key and re-issue all the certificates, but this work
>     >      need not be done.  In short, the denial of services
>     >      comes from revoking a certificate that is perfectly
>     >      fine.I also don't understand why you would not want to
>     >      revoke a key if it was destroyed?
>     >      [Santosh Chokhani] I do not understand what the need to
>     >      revoke the certificate is?If I cannot use my key to sign
>     >      or decrypt or gain access to a service then what is the
>     >      value of that key to me?
>     >      [Santosh Chokhani] You are right in the decryption
>     >      scenario, but as stated earlier not right in the
>     >      signature scenario. If a key is revoked, it is placed on
>     >      a CRL until the key expires.  The key can no longer be
>     >      used for signing
>     >      [Santosh Chokhani] But what about what was signed
>     >      before, unless you integrate trusted time stamp and
>     >      revamp the X.509 and PKIX path validation to account for
>     >      time and trusted time, legitimate signatures will be
>     >      rejected. and as Bob pointed out others cannot use the
>     >      public key to encrypt messages to the key holder.In my
>     >      experience, most users forget their pass phrase (be it
>     >      userid and password or key and pass phrase).  If the
>     >      user destroys their key at this point, what is the
>     >      purpose of keeping the key?  Why would you not revoke
>     >      the key?Sorry to burden you but could you explain to me
>     >      why you think revoking a certificate is a denial of
>     >      service?
>     >      From: Santosh Chokhani [mailto:[email-masked]]
>     >           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
>     >           serviceI 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.
>     >
>     >                From: Scherling, Mark
>     >                [mailto:[email-masked]]
>     >                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
>     >                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
>     >                     From: Santosh Chokhani
>     >                     [mailto:[email-masked]]
>     >
>     >                     Sent: Tuesday, June 12,
>     >                     2001 11:57 AM
>     >                     To: [email-masked];
>     >                     Scherling Mark
>     >                     Cc: Ietf-Pkix
>     >                     Subject: RE: Online
>     >                     Certificate Revocation
>     >                     Protocol
>     >                     I agree with "thayes".
>     >
>     >
>     >                     From: [email-masked]
>     >                     [mailto:[email-masked]]
>     >
>     >                     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:[email-masked]]
>     >
>     >                     >Sent: Tuesday, June 12,
>     >                     2001 9:07 AM
>     >                     >To: Paul Gogarty;
>     >                     [email-masked];
>     >                     [email-masked]
>     >
>     >                     >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
>     >                     >
>     >
>     >                     >[mailto:[email-masked]]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
>     >                     >
>     >                     http://www.interclear.co.uk/
>     >
>     >                     >
>     >

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 14 Jun 2001 10:34:15 -0700

At 07:42 AM 6/14/01 -0400, jim wrote:

>I do not want to claim that a destroyed key is invalid.  What I believe 
>needs to happen is recognition that the CA is the one to make the decision 
>as to whether the key is destroyed, not the user.  If, for instance, I am 
>using a system with a hard token, if the key is run over by a car and will 
>not be usable, there is still the remains of the key to be turned over to 
>the CA and the CA can make the decision.  If the key is a software token, 
>there is no such manner of determining that the key is truly destroyed by 
>the average PKI user.  As such, why allow a user to determine whether the 
>key is destroyed?  All I think needs to happen is recognize that this is a 
>CA decision and let the CA take the appropriate precautions in accordance 
>with the CP/CPS for the system.

All of this debate orbits around "who is on the hook" when bad things happen.

If I suspect my key is compromised (but I cannot easily prove it), or I 
believe I have destroyed it (successfully or not), then what must I do to 
announce to the world that "any signatures generated after this point is 
time should not be attributed to me"?

If it is only up to the CA to make these determinations, and the CA chooses 
not to agree, how am I to protect myself from responsibility for future 
transactions made in my name?

If I make an effort to tell folks "this is the termination date of my key 
use", and the CA does not take action, do they (the CA) become responsible 
for any mischief that may ensue?  It would seem as if they must, since the 
decision on key reliability is in their hands.

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: jim <[email-masked]>
Date: Thu, 14 Jun 2001 22:14:27 -0400

If you want to disavow use of the key, the CA is responsible for making it happen
and the results of what happens if the keys do not get placed on a CRL.  Since
the CA is acting within the security arena, I would certainly hope that any CA
errs on the side of being too conservative.  However, that is up to the security
management protocol of the enterprise and I would not deem to tell an enterprise
how to operate.  From my perspective, if the CP and CPS would not require
disavowal of a key by a user via the process of certificate revocation, I would
prefer not to trust that enterprise.

So, I am not as concerned about a key not being revoked when its owner wants it
revoked as I am about it not being revoked when there is uncertainty about the
demise or destruction of the key.  Any uncertainty should be cause for revocation
just as a request from the user should be cause for revocation.

Jim