Dear all, We attach the last review of the document in the usual formats. .doc with track changes and .pdf with all the changes being accepted. A summary of introduced changes can be found at the end of the document. We would like to remind Milan to introduce his contact data. Oscar and Jesus

Dear Milan, Please find below our responses about your comments contained into the DOC file. In another post we'll try to comment the rest of your email. Best regards and enjoy Tokio! Oscar & Jesus ***Pag 4, line 28: MS1: I'd rather not deal with authorization in an OCPS resquirements document. JLG: OK we should clearly separate OCSP and AuthZ, however let's tell the readers that OCSP may be used as a Validation mechanism able to deny access to users (blacklisting through invalidation) prior to let them into the Authz process itself. ***Pag 5, line 28: MS3: IMO there's a significant terminological difference between a "relying party" (any party relying on the PKI) and an "OCPS client" (software used by some relying parties to get some information) JLG: Maybe the definition for both terms should be provided in an introductory manner, but we may be able to specify that "Relying Party" will be used instead through the document. ***Pag 5, line 32: MS4: DO we need this sentence? That's the same meanign of "issuer" as everywhere and always... JLG: I'm not getting your point here, are you saying to use "issuer" instead of "appropiate OCSP Responder"? ***Page 6, line 32: MS6: Can we reach this goal in the near future? I think some transition period with CRL-only clients JLG: Agree with you, however I don't know where in the document such period should be proposed. Anyone in the list with experience from previous GGF recommendations managing with the introduction of new mechanisms/protocols? Maybe if in that paragraph we change the MUST for a SHOULD? However let's note that section 4 applies to OCSP and its use in relying parties; most of the features explained in this section can't be applied to CRLs because they just weren't intended to. ***Pag 7, line 32: MS7: I'd preferably skip the certificate suspension discussion (the previous three paragraphs). Let's define the usage of OCSP within our current environment and take care of the modification of the environment separately. JLG: I see two points here: in first place and as an analogy with the Proxy revocation topic, we could ommit any comments about the certificateHold status until more practical experience is achieved. On the other hand, it may be useful to warn CAs about the potential implications of setting such status for "temporally" revoked certificates because in our experience sometimes it is used indiscriminately. What do you think?

Hello again Milan, Please find below some other comments to your previous email, sorry for the late response and hope the CAOPS Meeting@Tokio was OK! Best regards, Oscar & Jesus

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.

JLG: Let me cite here a previous email exchanged with David Chadwick a few months ago, precisely about blacklist-like mechanisms and OCSP: "Of course. CRLs, revocation, OCSP are all black list mechanisms. The alternative is to have white lists and to ask the issuer if a cert is on its white list or not. But this is a different type of validation to the one that I am talking about with the CVS. It is only an initial important first step in validation."

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?

JLG: Clearinghouses & Trusted Responders sign OCSP Responses with a private key issued by an authority in which the relying parties implicitly trust (ie IGTF). Compare versus Authorized Responders signing OCSP Responses with a private key in which relying parties must trust explicitly.

6.3. Revocation Information Sources ----------------------------------- "blacklist" again

JLG: Pls refer to first response and previous email.

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)?

OM: Milan, your summary of the section is correct. However, your conclusion is not. When a full CRL is issued, there are no deltaCRLs to issue because such D DeltaCRLs always refer to the full CRL that was issued last. In any case, I don't see what is the point you want to make. Do you propose rephrasing the section?

9.1 OCSP Service Architecture ----------------------------- What are the "OCSP High Level Responders"?

JLG: Please find explanation in section 7.1.3 adcording to the Relying Party's point of view.

OCSP Client Configuration Examples ---------------------------------- The actual example is missing.

JLG: Appendix B.1, page 21?

...or otherwise invalid certificates from *being used*. from use reads ok to me - maybe it's not recognized as standard in the UK?

...OCSP services must be discoverable, fault tolerant and *have* low latency.

don't care, but why not "have fault tolerance" too?

3. Practical Considerations and Expectations ...presents a *scalability* problem...

3.1 Certificate Revocation Lists ...somewhat like *a trusted* responder)... No, this changes the sense, what was meant should perhaps have been

7.1.2 OCSP Clearing house In order for such a service to be *trustworthy*...

Ok, but scalability seems to me like a concept applied to a particular service and scaling applied to a problem or a system as a whole. So we need a scalable solution to a scaling problem. Maybe that's idiosyncratic usage, sorry if so. put in quotes then, like a "Trusted Responder (see below)" trustable or trusted reads better to me; "trustworthy by" doesn't seem right.

9 Other Considerations (I feel the first sentence is rather clunky - perhaps something like the following is better) While OCSP as a technology has been around for several years, *it has yet to make a significant impact to the Grid community.*

This sentence implies the wrong relationship between OCSP & Grids. It suggests that there is something wrong w/ OCSP that has kept it "from use" in Grids. That may be, but is yet to be shown. The existing sentence may be phrased better somehow ("if used are not..." is better verb agreement) but reflects the sense of the relationship between Grids & OCSP better.