Re: Online Certificate Revocation Protocol

[jim <[e-mail]>]

True, a destruction event does not mean that a key has been compromised, but on
the other hand, it does not mean that a compromise did not occur.  Thus, there
is still need to close the loop.
Jim

Santosh Chokhani wrote:

>      In all this, I do not see a security reason for key revocation.  If and
> when a key is known or suspected of compromise, one should (must) revoke it.A
> destruction event does not mean key has been compromised.
>
>      -----Original Message-----
>      From: jim [mailto:[e-mail]]
>      Sent: Friday, June 08, 2001 8:33 PM
>      To: Santosh Chokhani
>      Cc: Tony Bartoletti; Housley, Russ; [e-mail];
>      [e-mail]
>      Subject: Re: Online Certificate Revocation Protocol
>
>      I usually try to keep a low profile, but cannot help but get
>      involved.  There is absolutely a need for revoking keys, even if
>      they were destroyed.  If I were conducting a high-risk operation
>      (large sales, financial responsibilites, life responsibilities in
>      the medical community, national defense, etc.), I would not trust
>      any system where keys were not revoked just because someone reported
>      them destroyed.  The associated key could certainly be reproduced
>      for later usage if someone were able to figure out what was being
>      used, and without revocation, there would be no way to ensure that
>      they usage of the key did not continue after the reported
>      destruction.  When a key is no longer to be used other than at the
>      end of its validity period, it must be place on a CRL to end usage
>      of it altogether.
>
>      I have stated it pretty strongly, but I feel that way about it.  The
>      problem then becomes one of determining the risk mitigation with
>      lost keys and ensuring that the mitigation is as stringent as
>      possible to ensure less risk.  It is a matter of trust if the CP and
>      CPS do not call for revocation and will certainly disqualify the
>      users of such keys from access to areas where their certification is
>      not considered suitable.  If the ability to put trust into a
>      certificate that is then used to authenticate a user so that user
>      can access information or workflow that they would not otherwise be
>      able to access, then the business decision behind using that form of
>      trust must make the risk mitigation decision to reduce the amount of
>      trust that can be divested into a certificate from a system that
>      does not revoke it because it is reported by the user to be
>      destroyed.  For a system to be validated, registration and
>      certificate issuance have to be upheld by having practices as strong
>      for certificate revocation.  Otherwise, why have a PKI to begin
>      with?
>      Jim Heimberg, ABC, Ph.D.
>
>      Santosh Chokhani wrote:
>
>     >
>     >
>     > Destroying a private key used to generate signature may cause some
>     > operational grief in terms of getting a new key certified, but
>     > there is no need for that key any more and hence no revocation is
>     > needed.
>     >
>     > Destroying a private decryption key also does not require any
>     > revocation, but underscores the need for key recovery.  Absent key
>     > recovery, data encrypted with the public key companion to the lost
>     > private key, can not be decrypted.
>     >
>     > -----Original Message-----
>     > From: Tony Bartoletti [mailto:[e-mail]]
>     > Sent: Friday, June 08, 2001 5:31 PM
>     > To: Housley, Russ; [e-mail]
>     > Cc: [e-mail]
>     > Subject: Re: Online Certificate Revocation Protocol
>     >
>     > At 04:47 PM 6/8/01 -0400, Housley, Russ wrote:
>     > >Peter:
>     > >
>     > >You make an interesting point.  I figure that a message signed
>     > with the
>     > >private key that is claiming to be compromised is a good thing to
>     > pay
>     > >attention to.
>     > >
>     > >If the message is from the subscriber, then that subscriber
>     > probably knows
>     > >that some bad thing just happened and the subscriber is trying to
>     > let
>     > >everyone know.  He does not want any one to rely on the key any
>     > more.
>     > >
>     > >If the message is not from the subscriber, then the key has
>     > absolutely
>     > >been compromised.  What a nice attacker to tell everyone.
>     > >
>     > >Russ
>     >
>     > Indeed.  I have often considered that a revocation request signed
>     > with the
>     > corresponding private key is one of the few things in this world
>     > one can
>     > act upon reliably.  If we could build whole systems on such
>     > principles,
>     > we'd be home free.
>     >
>     > A question:  If one discovers that they have accidently destroyed
>     > their
>     > private key (and there is no evidence of compromise), are they
>     > under any
>     > particular obligation to request revocation?  Is there any
>     > liability, or
>     > other real "downside" to simply getting a new key and keeping mum
>     > about the
>     > fate of the former key?
>     >
>     > (I ask, because this seems the only case where a revocation
>     > request could
>     > NOT be signed by the key in question.)
>     >
>     > ___tony___
>     >
>     > >At 04:34 AM 6/9/2001 +0000, Peter Gutmann wrote:
>     > >>Nada Kapidzic Cicovic <[e-mail]> writes:
>     > >>
>     > >> >This is exactly what CMP specifies. Many vendors already have
>     > support
>     > >> for CMP
>     > >> >EE initiated certificate revocation. The interoperability of
>     > different
>     > >> >implementations of CMP certificate revocation (among other
>     > things) has been
>     > >> >conducted during PKI Forum and ICSA CMP interop testing quite
>     > successfully.
>     > >>
>     > >>However there are two ways to look at revocation, the DOS model
>     > and the scram
>     > >>switch model.  The DOS model says that anyone who can revoke
>     > your cert can
>     > >>cause a DOS, so it should be made as difficult as humanly
>     > possible to
>     > >>revoke a
>     > >>cert.  The scram switch model says that when your private key is
>     > compromised
>     > >>you want the cert revoked right now with no excuses, so it
>     > should be made as
>     > >>easy as possible to revoke a cert.  CMP follows the DOS model
>     > and makes
>     > >>it very
>     > >>difficult (in some cases impossible) to revoke your cert.
>     > Programs like PGP
>     > >>follow the scram switch model (via suicide-note revocations) and
>     > make it very
>     > >>easy to revoke your cert.  Depending on your point of view, CMP
>     > may not
>     > >>be the
>     > >>right thing for handling revocations.
>     > >>
>     > >>Peter.
>     >
>     > Tony Bartoletti 925-422-3881 <[e-mail]>
>     > Information Operations, Warfare and Assurance Center
>     > Lawrence Livermore National Laboratory
>     > Livermore, CA 94551-9900
>     >
>