Subject: RE: Candidate for moving OCSP to a Draft Standard

From: "Khaja E. Ahmed" <[email-masked]>
Date: Mon, 11 Feb 2002 22:59:54 -0800

Simon,

I am afraid I did not describe the scenario and it's assumptions in full
detail but the solution you are pointing out would not apply.  In this (ISIS
envisioned scenario...I think) the OCSP responder and the CA do not know
that the CA's private key has been stolen/copied and is being used to mint
certificates.  Thus the OCSP responder would respond that the certificate
was good because it was not known to be revoked.  In fact even if the
CertificateOK extension is used this problem may not be caught if duplicate
serial numbers were being used.  Indeed even a delegated path validation
capable server may not catch this particular problem depending on the nature
of the checking done prior to generating a response.  The solution
envisioned, as explained to me by some German and other EU bank PKI folks,
was that the OCSP responder would have access to some sort of a database
that contains all the certificates issued by the legit CA and will check
against this database.  The validation server would have to be given the
entire certificate or at least the public key or identifier and confirm that
that precise key, was certified in a certificate with that exact serial
number, etc.

Anyway, where I had left it was that it would be fine to do anything over
and above basic OCSP (via extensions) so long as it did not change/overload
the semantics of the OCSP status itself from that specified in RFC2560.  My
own inclination was, and remains, to settle for people doing ANY checking of
status at all to get started.

Anything beyond that is probably best handled by some standardized
(hopefully easy to use) protocol the list comes up with.

Khaja

> -----Original Message-----
> From: Simon Tardell [mailto:[email-masked]]
> Sent: Monday, February 11, 2002 7:33 AM
> To: Khaja E. Ahmed; [email-masked]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
>
>
> > I agree that there is no great need for an OCSP server to
> > tell a PKI enabled client that a certificate exists or was
> > issued if the PKI enabled client has first performed the
> > required verification of the CAs signature on the cert and
> > done proper path validation and is now only checking the
> > revocation status.  My initial reaction was that it might not
> > do any harm to have an optional extension to satisfy some
> > corner cases.  One such case, that was put forth was of a
> > situation where the CA's private key was stolen and being
> > used to mint certificates by an attacker.  Such certificates
> > would not be in the CA's database. An optional extension like
> > the one proposed by Peter could afford some limited
> > protection against this.
>
> Khaja,
>
> This case is already catered for in RFC2560:
>
> "2.7  CA Key Compromise
>
>    If an OCSP responder knows that a particular CA's private key has
>    been compromised, it MAY return the revoked state for all
>    certificates issued by that CA."
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice +46 8 6853174, fax +46 8 6856530
> cell +46 70 3198319, [email-masked]

---

From: Al Arsenault <[email-masked]>
Date: Tue, 12 Feb 2002 11:57:48 -0500

Gee, what happens in this scenario if it's the OCSP responder's private key
that has been compromised? :-)

Further, what happens if, as Michael McIntosh suggested, the CA private key
that issued the OCSP responder certificate is compromised, and the attacker
creates a new OCSP responder (and points all new/bogus certificates to it).
Now we have two communities, with two OCSP responders, each of which claims
the OTHER is invalid.  How is this resolved?

        Al Arsenault
         Chief Security Architect
        Diversinet Corp.

---

From: "Khaja E. Ahmed" <[email-masked]>
Date: Tue, 12 Feb 2002 11:04:28 -0800

Al,

Different problem, different thread.  Answers inline...

> From: Al Arsenault [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 8:58 AM
> To: Khaja E. Ahmed; Simon Tardell; [email-masked]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>

Nothing.  Even if this has not been discovered, I can't think of any harm
this (by itself) would do.  Recall that the trust model here had the relying
party go to a specific URL for OCSP queries.  This URL was configured into
clients or communicated to them through some trusted mechanism.  As long as
the legit OCSP responder at the appointed URL was doing it's thing, the fact
that someone has it's private key probably does no harm.  Of course, if is
_known_ that the OCSP responder key has been compromised, it can and will be
revoked.

> the OTHER is invalid.  How is this resolved?

Answered in previous response to Michael.

> > own inclination was, and remains, to settle for people doing
> ANY checking
> of