Subject: Any OCSP implementations out there?

From: Ambarish Malpani <[email-masked]>
Date: Wed, 15 Nov 2000 12:03:09 -0800

Hi Folks,
    I am looking for people who have OCSP currently implemented
(either in products they are building or using).

There is some feeling that the definition of CertID is not
flexible enough and that OCSP, long term, would be better served
by allowing the client to identify the cert in multiple ways -
by CertID, by the full certificate, by a URL pointing to the
certificate, etc.

I am looking for some input from people who are currently using
OCSP about whether they believe that this is an important
enhancement to OCSP, or whether they are satisfied with it the
way it is currently defined.

If people are reluctant to post to the whole group, please let me
know in a private email and I will happily summarize.

NOTE: This discussion only pertains to OCSP and is not asking
about whether remote path processing is valuable or not.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Nov 2000 09:50:52 (NZDT)

Ambarish Malpani <[email-masked]> writes:

>There is some feeling that the definition of CertID is not flexible enough and
>that OCSP, long term, would be better served by allowing the client to
>identify the cert in multiple ways - by CertID, by the full certificate, by a
>URL pointing to the certificate, etc.

I've already grumbled about this in private, but I'm posting this to the list
in case others have any thoughts... when used in a request this is a really
serious, major PITA to work with because the issuerNameHash/serialNumber option
is useless (ie unless your implementation happens to already make use of the
issuerNameHash and serialNumber as search keys you can't do anything with the
combination of hashed and unhashed data), and the issuerKeyHash isn't the same
as the authorityKeyIdentifier (since there are many different interpretations
of how to construct the aKI) so you have to manually dig into the cert encoding
and construct it yourself rather than just keying off the aKI.  I'd like to see
the CertID extended to also allow a cert hash, issuerAndSerialNumber (strictly
speaking an iAndS hash, you don't need the whole iAndS), and an aKI (that is,
an explicit aKI rather than an implicit RFC2459-style aKI as it's done now).
This could be done by making it a choice of the current certID and the above
values.

You also need to carefully consider just what you can put into a CertID, for
example by allowing URLs I can force the responder to access any web page I
want by telling it there's a cert there ("Hmm, the responder's running under NT
and using OCSP.OCX for the processing, should only take a minute before it's
under my control...").

Peter.

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 15 Nov 2000 15:54:53 -0500

Hi,

> ----------
> From: 	Ambarish Malpani[SMTP:[email-masked]]
> Sent: 	Wednesday, November 15, 2000 3:03 PM
> To: 	[email-masked]
> Subject: 	Any OCSP implementations out there?
> 
> Hi Folks,
 
This question is worth asking and I am certainly interested in the responses
(or a summary) as well.  However, I can't help but get the feeling that the
"people who are currently using OCSP" are more likely than not to have found
it adequate for their needs (otherwise they would not be currently using
it).

Therefore, it's probably worth also soliciting the opinions of any who
perhaps wanted to use OCSP and found it inadequate (and therefore didn't use
it) because the current CertID was too limiting for their
environment/purpose.  Of course, I've no idea if that particular set of
people subscribe to PKIX, but we might as well at least ask the question...

Carlisle.