Subject: RE: OCSP I-Ds going forward

From: [email-masked] (Peter Gutmann)
Date: Tue, 3 Dec 2002 19:22:22 +1300 (NZDT)

"Tom Gindin" <[email-masked]> writes:

>The following structures have been proposed in this discussion: a - CertID, b
>- fullCertificate, c - issuerSerial,

IssuerAndSerialNumber.  IssuerSerial is that SEQUENCE OF GeneralName oddity
which no-one can explain.

>If b is present, c, d and e are pointless

Unless:

- You're in a bandwidth-constrained environment (the cert can be an order of
  magnitude larger than the rest of the query).

- Your responder can't dissect certs to extract bits and pieces for use as
  IDs.

>This reduces the matrix to four single fields (CertID, fullCertificate,
>issuerSerial, and ESSCertID), and CertID with any one of the other three.

This still has the problem that it doesn't guarantee any interoperability,
because I can submit requests containing X to a responder which only does !X.
To provide guaranteed interoperability, you need at least one universal,
unambiguous, easy-to-get-right identifier (see my previous post on this
topic).  You can then augment it with as many add-ons as you like, provided
you understand all of their potential shortcomings.  In other words:

There must be at least one MUST which is:

- Universal and unambiguous (uniquely identifies a cert even if (just to keep
  Steve Kent happy :-) it has a broken DN).

- Compact enough to work in bandwidth-constrained or resource-limited
  environments.

- Easy to get right, to avoid the problems experienced with the v1 ID.

The only ID which seems to meet these requirements is certHash.  As I said in
my previous message, I don't care what else you stick in there, as long as I
can ship code which I know will work with any other (v2-aware) implementation.

Peter.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 03 Dec 2002 09:30:49 +0100

Peter,

> which no-one can explain.

I can provide an explanation:

A chain of DNs names formed by a certification path starting from a root CA 
and finishing with the end CA uniquely identifies the name of a CA. It is 
similar to identify two files with the same name, but placed in a different 
directory. Hence why a SEQUENCE OF GeneralName makes sense. Then, given that 
the CA name is unique, the serial number for that CA uniquely identifies the 
certificate.

However, there are better ways to uniquely identify a CA and this approach 
is currently NOT followed by OCSP v1, nor the draft for OCSP v2.

So I agree that we should not consider IssuerAndSerialNumber, but this is 
based on a fully different rational.

(...)

> The only ID which seems to meet these requirements is certHash.  

certHash is not usuable when only CRLs are used by the OCSP Responder. Since 
the client does not know if CRLs or something else is being used in the 
background by the OCSP Responder, certHash cannot be used. This option 
should thus be discarded.

Denis

> As I said in my previous message, I don't care what else you stick in 
 > there, as long as I can ship code which I know will work with any
 > other (v2-aware) implementation.
> 
> Peter.

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Tue, 03 Dec 2002 06:47:20 -0500

Peter,

Your point of being able to handle broken DNs is a very good one.
The relative complexity of DNs compared to a simple hash, and the
historic ability of coders to get DNs wrong begs for one easy way
to match certificates.

Compact is a good reason too, and the hash provides a fixed length
search key, and complexity that does not vary with the number of
DN components, their order, or whether a given attribute is absent
or present or appears more than once.

A hash approach does not require writing, testing, documenting and
maintaining all of the programming logic needed to handle DN
complexity.

And a  hash doesn't care what type or version of certificate is used,
whether it's encoded in DER or XER, or whether it even has a DN.

Phil

Peter Gutmann wrote:

big snip