Subject: RE: OCSP RFC and OCSP version 2 ID

From: Peter Williams <[email-masked]>
Date: Wed, 16 Jan 2002 11:41:27 -0800

Denis,

You refer to an assumed  "main mechanism" in your note. Speaking factually,
to hopefully guide you, sensibly:-

The main [reference] mechanism(s) at, and shortly after,
the time of writing OCSP IDs included:-

(1) VeriSign, who used an oracle database-based repository to feed data
to OCSP deamons acting in cached and interactive, direct-trust 
mode; CRLs were not involved. OCSP proxing/multiplexing interactive
direct-trust mode was  added, shortly after standarization, for a 
defense customer bridging multiple certification domains.

(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
deamons. Indirect CRLs and CRLDPs support was added slightly after
the architects had harmonized their work.

Both mechanisms evolved further, outside of IETF and
in vendor forums, particularly in the area of: application 
integration, CRLDPs and delta-CRL data sources, proxying 
transaction semantics and response resigning, data freshness 
signalling, and OCSP client interaction with X.509 and 
PKIX-style path processing and X.509 applications such as 
SSLv3/https and MTA-based automatic xmldsig signature 
verification on B2B and banking protocol XML streams.

Historically, this work essentially re-designed the standardized
features of the "distributed authentication model" of 
X.500 1988, for OCSP-borne queries.

Currently, VeriSign's current work in W3C also
reflects alot of the understanding on the required
semantics of realtime trust models.

Peter.

-----Original Message-----
From: Denis Pinkas
To: Santosh Chokhani
Cc: [email-masked]
Sent: 1/16/02 12:04 AM
Subject: Re: OCSP RFC and OCSP version 2 ID

At the time the document was written, the main mechanism to feed the
information to the OCSP server was to use CRLs. So it seems sensible to
think that these fields are copied from a CRL.

---

From: Rich Salz <[email-masked]>
Date: Wed, 16 Jan 2002 19:01:04 -0500

From the time of the first I-D for OCSPv1 up until close to RFC status,
CertCo was the third major entity in the OCSP arena. We were at least
partially fronting for the still-being-created Identrus, and we (CertCo
and the tech commmittee folks from the initial working groups) saw OCSP
as the keystone for its online trust services.

For what it's worth, the CertCo product used CRL's, but also had a "fast
track" interface for updating its internal database.  At the time, we
would often explain that CRL-only approaches were deficient to our
LDAP-based publication and CRL approach, since a CRL couldn't tell you
if a certificate was, in fact, never issued. :)

> semantics of realtime trust models.

Hardly.  Much as I like XKMS (a co-worker is co-editor on the
requirements document), its approach to semantics is to sweep them under
the rug; post to the right URL and "just trust me."
	/r$
-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com