[caops-wg] Version 06-09 of the OCSP document.

[jluna at ac.upc.edu]

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?