Subject: RE: OCSPv2 and OCSP extensions drafts

From: Peter Sylvester <[email-masked]>
Date: Thu, 21 Sep 2000 18:48:36 +0200 (MET DST)

> Peter,
> 
> Maybe I'm the only one who thinks this way, but I view DVCS as more related
> to the validation of signatures on documents and consequently a higher-order
> (i.e. more application-level) protocol than OCSP.  Validation of those
> signatures inherently involves validation of the relevant certificate(s).
> This could be facilitated in part by reference to CRLs or an online
> mechanism (i.e. OCSP).

You mean X509 certificates? One can also say that OCSP does a REAL one-dimensional
thing while DVCS works in COMPLEX environment. 

> 
> The draft that expired was the original "OCSP-X" draft. The DPV and DPD
> drafts draw from and build on that.

The idea of my small comparison was to find out what protocol element are
actually used to implement the required service. Since we are in PKIX and
are not really afraid of borrowing ideas from the X-Series, it seems to me that
a good idea to try to define a service first, unless everybody feels that
this is obvious.

One could also consider that cmp is THE certificate management protocol,
or that an LDAP control could be used for path determination. 

Another thing: 

The path determination proposal now has the possibility to continue a 'stateful'
association. There should be at least some more text about saying what this
actually means. Where and how is the state maintained?
One possibility is the cookie that was returned, and not in the server.
and a client just may accept the first proposal, and has no way to
indicate to the server that the association is terminated. 
In order to maintain a state on a server, one could also use something
like the keep-alive technique of http, or what had been discovered
in the direct socket based protocol of cmp. 

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Sep 2000 11:30:02 +0100

Peter,

Peter Sylvester wrote:
> actually means.

I'd be interested in any proposals you might have to clarify this feature
(actually, answering your question has thrown up a couple:-).

In any case, what's at issue is not an onerous state, that the server has 
to maintain with each client separately - I'd imagine that a lot of server 
implementations would use the same retryReference value in a response, 
regardless of who makes the request. Calling it stateful is probably 
inaccurate, its more like a shorthand for the "meat" of the request/response 
pair in question.

Just to give an example, say a relying party (rp1) has an ee cert (for ee1) 
and sends a request with the issuer/serial from ee1's cert. The response 
includes retryReference 1. The responder now has all the certs in a path
for ee1 in its cache.

Next, ee1 also contacts rp2 in the same "domain" as rp1 (they use the
same responder). A new request for ee1's path is sent to the responder.
It returns the same path from its cache, with the same retryReference
value (1) to rp2.

If either of rp1 or rp2 don't like the first path and more paths
exist, then in this scenario, they'll both step through the list
of retryReference values chosen by the responder. It doesn't matter
in which order they step through the list, or whether rp1 or
rp2 "leapfrog" one another.

The retryReference values can be changed with each response, so that
there's no "history" needed on the responder (maybe we need this
sentence explicitly in the draft). I don't think we have to 
make this a MUST, in case someone does want to implement a server
that maintains the full history of its dealings with a specific
client, by storing different state information per client (not
that that seems very useful). In any case, it makes no difference
to the client since the client always uses the retryReference from
the most recent response, not from the response to the original 
request (again, maybe we should make this more explicit).

> Where and how is the state maintained?

The implementation of the server isn't part of the spec. 

> indicate to the server that the association is terminated.

I don't follow that sentence (or two sentences, whatever:-). The 
example above should clarify that the client never needs to close 
a stateful connection or anything like it.

> in the direct socket based protocol of cmp.

That's not needed here. If the server no longer has the retryReference
it returns an error and the client can process the error.
I could buy that we'd want a specific error, (say referenceNotFound
or something), but internalError or tryLater should be ok in this case.
You're probably right that we should specify which error to send in 
this case (I'd pick internalError).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com