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

From: Michael McIntosh <[email-masked]>
Date: Tue, 12 Feb 2002 04:53:22 -0800

Khaja,

Wouldn't someone that went to the trouble to issue rogue certificates using
a stolen CA private key would also probably inject the OCSP Service Locator
for a rogue OCSP Responder? Is the scenario you describe really likely?

Thanks,
Mike

-----Original Message-----
From: Khaja E. Ahmed [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 2:00 AM
To: Simon Tardell; [email-masked]
Subject: RE: Candidate for moving OCSP to a Draft Standard

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: "Khaja E. Ahmed" <[email-masked]>
Date: Tue, 12 Feb 2002 10:50:45 -0800

Mike,

I would like to wash my hands of all responsibility associated with this
scenario :-).  It is not mine but was presented to me by some Bank PKI folks
in EU and is (I believe) of ISIS origins.   I share your opinion that it is
unlikely but then there are too many things that are equally (ore more)
unlikely yet have elaborate counter measures in the technologies / standards
we develop.  Looks like people do worry about unlikely by possible
scenarios.

To answer your question however,  this scenario is certainly in the realm of
the possible and the solution you describe would not work because the trust
model envisioned, required clients to always go to an OCSP responder it
trusted regardless of what the AIA pointed it to.  In fact the OCSP
responder was not even delegated the authority to respond by the CA in
question but by a different CA.  As an example, the solution was being
promoted by some Identrus banks and would work fine in the Identrus PKI
model also.  So, if the unlikely were to happen, the solution would actually
work as expected in the cases that we were able to work out, as long as the
OCSP responder did the necessary/proper checking.   The hash of cert
technique described by Peter G would do just fine as a checking mechanism
for example.

Khaja

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Michael McIntosh
> Sent: Tuesday, February 12, 2002 4:53 AM
> To: 'Khaja E. Ahmed'; Simon Tardell; [email-masked]

---

From: Petra Barzin <[email-masked]>
Date: Tue, 12 Feb 2002 23:13:27 +0100

Maybe this will help:

This is an excerpt of the so called ISIS-MTT specification (Industrial

Signature Interoperability Specification & Mailtrust). The specification

may be obtained from: http://www.t7-isis.de/

Part 4, section 3.1.2 describes the scenario Khaja is talking about.

It defines a private extension to be used in an OCSP response:

3.1.2 ISIS-MTT Private OCSP Extensions

CertHash (Positive Statement)

id-isismtt-at-certHash OBJECT IDENTIFIER ::= {1 3 36 8 3 13}

CertHash ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
certificateHash OCTET STRING }

hashAlgorithm: The identifier of the algorithm that has been used
certificateHash: A hash over the DER-encoding of the entire PKC or AC.

ISIS-MTT: The responder may include this extension in a response to send
the hash of the requested certificate to the responder. This hash is
cryptographically bound to the certificate and serves as evidence that
the certificate is known to the responder (i.e. it has been issued and
is present in the directory). Hence, this extension is a means to provide
a ‘positive statement about issuance’ as described in Table 8.[8]. As
explained in Table 13.[1], clients may rely on this information to be able
to validate signatures after the expiry of the corresponding certificate.
Hence, clients MUST support this extension. If the intention is to deliver
a ‘positive statement about issuance’, this extension MUST be inserted.
A further note on security: Including the hash of the queried certificate
in the response prevents impersonation attacks of the following scenario:
Mallory manages to get the private key of a CA. The corresponding CA
certificate is immediately revoked. Using the stolen CA key, Mallory creates
a faked certificate with the same serial number as an existing one (the
original) and containing a new public key. Using the corresponding private
key, Mallory signs a message and sends it, along with the faked certificate,
to Alice. Alice succeeds to mathematically verify the signature and wants to
check the state of the received certificate by sending its serial number to
the OCSP server. The server returns the answer ‘good’, if the original
certificate has not been revoked. Having received the response ‘good’, Alice
thinks that the (actually faked) certificate is O.K. and accepts the signature.
She is unable to detect that the response corresponds to another certificate
than what she was asking about. This threat is apparently not handled by
PKIX documents. The security gap can be closed by including either the
certificate or a fingerprint of it in the response, respectively in the
‘positive statement’ as proposed here. It is crucial that the signature
of the responder can be reliably verified. Hence, departing from the
practice proposed by RFC2560, the certificate of the responder SHOULD be
issued by some independent the CA, i.e. not by the CA the certificates
of which the responder provides information about. This configuration
is described in Table 8.[1], item d).

Table 8 states:

Accredited CAs obtain certificates from the German Federal Agency for

Communication and Post (RegTP), which contains an ‘OCSP signing’ key.

Regards, Petra

"Khaja E. Ahmed" schrieb:

Mike,

I would like to wash my hands of all responsibility associated with
this

scenario :-).  It is not mine but was presented to me by some
Bank PKI folks

in EU and is (I believe) of ISIS origins.   I share your
opinion that it is

unlikely yet have elaborate counter measures in the technologies /
standards

scenarios.

To answer your question however,  this scenario is certainly in
the realm of

the possible and the solution you describe would not work because the
trust

model envisioned, required clients to always go to an OCSP responder
it

trusted regardless of what the AIA pointed it to.  In fact the
OCSP

responder was not even delegated the authority to respond by the CA
in

question but by a different CA.  As an example, the solution was
being

promoted by some Identrus banks and would work fine in the Identrus
PKI

model also.  So, if the unlikely were to happen, the solution
would actually

work as expected in the cases that we were able to work out, as long
as the

OCSP responder did the necessary/proper checking.   The hash
of cert

for example.

Khaja

> Wouldn't someone that went to the trouble to issue rogue

> certificates using

> a stolen CA private key would also probably inject the OCSP

> Service Locator

> detail but the solution you are pointing out would not apply.
In

> this (ISIS

> CertificateOK extension is used this problem may not be caught if

> duplicate

> capable server may not catch this particular problem depending on

> the nature

> entire certificate or at least the public key or identifier and

> confirm that

> 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