Hi. You can find my comments in the attachment of this (not very timely ;( ) response. Here are some notes which I didn't fit into the text: Throughout the document: I'd rather skip all referencing to "blacklisting". It is being used here in a pure authorization meaning - denying somebody access to a resource. I don't think authorization decisions should be handled by invalidating the result of authentication. ==== 5.5 Responder Discovery ---------------------- - I'm not sure I understand the section properly. "Any OCSP server acting as Clearinghouse or Trusted Responder MUST be contacted first." - Why? 6.3. Revocation Information Sources ----------------------------------- "blacklist" again 8.2.1 Delta CRLs ---------------- - I don't seem to see the point here. Let me try to express my reading of the section: "One of the problems with current Grid CAs' full CRLs is their long expected lifetime, i. e. the nextUpdate pointing to at least 7 days in the future. This behavior is motivated by the software used by Grids (OpenSSL) and by the potential network problems. However, this usage of nextUpdate takes out the possibility of expressing the CRL issuance frequency in the CRL itself (some CAs issue them several times a day but the the only place to find out the frequency is their CP/CPS). The Delta CRLs are proposed to solve the problem - their nextUpdate would reflect the actual CRL issuance frequency so that the OCSP responder feed with them could provide the more appropriate value for the nextUpdate in the response." Am I reading the section right? If I am, doesn't that effectively mean that there would be a new delta CRL issued with every full one (or at least with every full CRL containing no new revocation records)? 9.1 OCSP Service Architecture ----------------------------- What are the "OCSP High Level Responders"? OCSP Client Configuration Examples ---------------------------------- The actual example is missing. Regards -- Milan Sova sova@cesnet.cz