Re: Online Certificate Revocation Protocol

[jim <[e-mail]>]

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.

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, 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.  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:[e-mail]]
>      Sent: Tuesday, June 12, 2001 4:30 PM
>      To: 'Santosh Chokhani'; Scherling, Mark; [e-mail]
>      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:[e-mail]]
>      Sent: Tuesday, June 12, 2001 12:56 PM
>      To: Scherling, Mark; Santosh Chokhani; [e-mail]
>      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:[e-mail]]
>                Sent: Tuesday, June 12, 2001 3:31 PM
>                To: 'Santosh Chokhani'; [e-mail];
>                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:[e-mail]]
>                     Sent: Tuesday, June 12, 2001 11:57 AM
>                     To: [e-mail]; Scherling
>                     Mark
>                     Cc: Ietf-Pkix
>                     Subject: RE: Online Certificate
>                     Revocation Protocol
>
>                     I agree with "thayes".
>
>
>                     -----Original Message-----
>                     From: [e-mail]
>                     [mailto:[e-mail]]
>                     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:[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/
>                     >
>