[caops-wg] OCSP - proxy certs

[Olle Mulmo]

>
> *Section 5.5 talks about support for proxy certs.  I obviously don't 
> think it is out of scope - we MUST talk about it - but it is 
> indisputable we don't know how to deal with them.  But punting 
> completely is leaving a lot of the potential value added of Grid OCSP 
> out.

You are right. Your suggested text (cut) will be added.

> We might also want to tell developers and OCSP client configurers
> OCSP queries on proxy certs are NOT RECOMMENDED and should
> be avoided, except by prior agreement and consultation with
> specially configured OCSP responders that can deal with them.

Yep.

> *Section 5.3
> The sources must be properly protected against malice use....
> Suggest [maybe it's overload]

The text below sounds fine to me -- with a reservation for replacing 
some of the wording with MUSTs.

> The OCSP responder database must be protected properly.  In most cases
> the database will be updated automatically, and adequate change 
> control and logging must be used to ensure data is obtained and loaded 
> from a trusted source in a timely fashion.  Signatures on CRLs must be 
> checked and CRLs must be refreshed in a timely fashion.   OCSP 
> responders must ensure that proper change control and access controls 
> are in place to prevent unauthorized addition or removal of 
> certificate status information from the database.  This is 
> particularly important to any OCSP service providing experimental 
> support for proxy certificate verification (see section 5.5).

...

> Customer expressed interest in dealing with proxy certs.
> The situation seems to be that in practice a chain of certs is
> available, from the EE to the last proxy cert.  Our experimental
> responder didn't deal with that well, apparentlhy peeling off the
> first one and skipping any others (first one being the last proxy
> cert).
>
> The standard reads (to me) as ambiguous about this, which surprised
> me, because I expected the above behavior:
> (RFC 2560 page 2)
>
> The response for each of the certificates in a request consists of
>
>    -- target certificate identifier
>    -- certificate status value
>    -- response validity interval
>    -- optional extensions
>
> Is this a bug in the spec, or the implementation?  What is the
> OCSP server "art" on this since this spec came out?   There is a
> remark about this somewhere in section 3 - it seems to be
> sort of out of place.

I don't follow. There's definitely not a bug in the spec: a response has

	issuer
	producedAt timestamp
	array of certificate status responses
	nonce if provided, and other extensions
	signature

where the array of certificate status responses contain the things you 
list above, for each certificate that status was queried for: 
identifier of the cert (hash of issuer name + serial#), it's status 
(good/revoked/unkown), how long this status is valid for (e.g., the 
thisUpdate/nextUpdate fields of the CRL), and possible extensions (e.g. 
revocation reason codes, the location of the CRL that was consulted, 
...).

I would say that your responder got confused up by the proxy certs. 
Possbily also that that it is one of the responders that cannot handle 
multi-certificate requests (array count > 1).

/Olle