Subject: RE: OCSP identifiers

From: [email-masked] (Peter Gutmann)
Date: Fri, 17 Nov 2000 14:16:55 (NZDT)

Michael Myers <[email-masked]> writes:

>Your concern is precisely why the OCSPv2 draft proposes what it does.  Have
>you any thoughts on the details of the relevant ASN.1?

Hmm, it's going to need some profiling in order to reduce the number of choices
to a workable subset, I like the issuerSerial and pKCert options but the certID
and name options are still going to cause problems on the server/responder side
(certID has the problems which have already been mentions, and something which
is a GeneralName could require creating a huge number of indices on the server
when a cert contains four email addresses, two URLs, a few extra DNs containing
stuff which didn't fit in the subject name, and some otherNames which didn't
fit anywhere else).  How will interoperability be achieved?  It'd require
either restricting clients to use the most useful/workable ID forms
(issuerSerial and possibly pKCert) or providing a mechanism whereby the server
can tell the client "I can't do anything with this, use the XXX identifier
instead".

Peter.

---

From: Margus Freudenthal <[email-masked]>
Date: Fri, 17 Nov 2000 10:51:55 +0200

Peter Gutmann wrote:
> to a workable subset, I like the issuerSerial and pKCert options 

I would support including the certificate hash option as well.  It
provides uniqueness despite the various key compromises.  It is quite
short as well.  I know, this doesn't allow CRL-based OCSP service, but
as the name implies OCSP should provide online service instead of CRL
caching.

-- 
Margus Freudenthal                              [email-masked]
Cybernetica                                     http://www.cyber.ee/