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

From: [email-masked] (Peter Gutmann)
Date: Fri, 8 Feb 2002 20:17:45 +1300 (NZDT)

"Florian Oelmaier" <[email-masked]> writes:

>Advantage of OCSP: extensible.
>
>Idea: Use advantages heavily.
>
>Conclusion: Interested in Peter Gutmanns extension.
>
>:) So Peter, plz post the extension and the derscription. Best to the list -
>then it is somewhat half-official and a lot of other people in the community
>can use it, too.

Here it is, slightly more formalised than the original source code comment:

-- Snip --

CertificateOK

The CertOK extension sidesteps the limitations of the CRL-based semantics of
the standard OCSP response and provides a straightforward indication of whether
a certificate is OK or not.  "OK" in this sense is the equivalent of the
banking assertion that an account is in good standing, namely that the
identified certificate was issued and is currently valid.  Further information
on why a certificate may not be OK can be found in the standard OCSP response.

  id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }

  CertOK ::= BOOLEAN

  [I'll take a PKIX OID in place of the current private one if it's considered
   worth issuing it]

Rationale

The CertOK response is purely an indication that the account is in good
standing.  In other words, it provides the information that the OCSP responder
is likely to possess, but is prevented by the standard OCSP status values from
providing to the user.  It does not provide, and is not intended to provide, a
DVCS/DPV/DPD/etc-style checking mechanism (for example, again using banking
terms, an indication that the account contains enough to cover a given
transaction, or that the account owner can be trusted to do business with).
These extended forms of checking are covered in separate standards.

-- Snip --

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Feb 2002 12:09:07 -0500

Peter:

If the extension is specified in an IETF document, then I will gladly issue 
an OID from the PKIX arc.  Otherwise, it is a private extension, and it 
should not be issued an OID from the PKIX arc.

Russ

---

From: Juergen Brauckmann <[email-masked]>
Date: Tue, 26 Feb 2002 13:48:34 +0100

Hi Peter.

>   id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }

In the ISISMTT stuff there is a similar OCSP extension which is intended
to allow the server to send the hash of the certificatein question back
to the client.

The problem with a simple boolean is IMO that it's not sure whether
server and client are talking about the same certificate. If we worry
about certificates with a valid signature that may not be issued by a
CA, than it should be possible for the client to check somehow that the
server knows not only about a certificate which happen to have an
IssuerDN and a serialnumber identical to that the client has, but that
is entirely identical to it. This can be achieved by a server which
sends a hash of a certificate back to the client, and the client then
checking this hash.

Standard disclaimer: In a normal PKIX way of doing status checking and
path validation, you don't need to worry about never issued
certificates.

Regards,
    Juergen