*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