[caops-wg] Re: Grid OCSP proposal

[Milan Sova]

	Hello.
Jesus Luna Garcia wrote:
> Dear all,
> 
> We hope you're having a very fruitful meeting at Seoul. We are looking 
> forward to knowing a little bit what has been discussed there.
> 
> Milan, Thanks for all your useful comments. We have read your document 
> and agree with most of your observations (just a small change on page 6, 
> changing "reply" by "replay"). 

	Thanks - jetlagged midnight in Seoul ;) I'm including the document for 
the CAOPS list members for reference and as an invitation to the discussion.

> In the case of OCSP Response Extensions 
> we are expecting to publish our results soon, but in the meantime maybe 
> the following remarks may help to clarify the point:
> 
> -We agree with you in that the idea of including new extensions on the OCSP
> Response may be something relatively difficult to standardize. But on the
> other hand, we would like to point out that such mechanism has been defined
> in the RFC2560 with the aim to convey additional information on assertions
> made by the responder. What we find is that even though such generic 
> mechanism has already been proposed on the standard, the document lacks 
> of suggestions about which uses can be given to the extensions in order 
> to suggest directions or services that could improve the validation 
> process.
> This is normal given the fact that the standard is very generic in its 
> design.
> However, the CAOPS-WG could propose a set of recommended/suggested ocsp 
> extensions to improve the validation process for grid applications.

	Yes, I agree that some kind of Grid CRL profile should be created. 
However, I don't think it should divert from existing standards and 
practices.

> For example, due to the dynamic nature of the mechanism, we find that the
> addition of extensions presenting information such as the accuracy of the
> OCSP Response (with values that could range from Very-High: Maximum Delay
> –md- of 5 minutes, High: md of 1 hour, Medium: md of 1 day, and Low: md 
> of 1
> week or more ), 

	If I understand you correctly, you want to introduce a new extension to 
express the "freshness" of the status information. I'd stay with the 
crlTime field of the CRLreference extension and let the relying party 
make the decision based on the exact time. Or am I missing your point?

> or the level of revocation of a certificate (definitely
> revoked or simply suspended) could help to complete the OCSP Response.

	Isn't reasonCode extension capable of providing this information?

> In addition, given the connectivity provided by a central OCSP Response
> System we find that this could be an ideal place to convey information that
> could be retrieved from the user's domain without the need to communicate
> with other Authorities such as, for example, the degree of trust in the
> issuing authority of the certificate (i.e. Gold: highly trusted registry 
> and
> revocation procedures, Silver: highly trusted registry procedures, Bronze:
> low confidence registry procedures). We believe that the availability of 
> such dynamic information could be very
> valuable to complement a PDP AuthZ decision when matching against the
> correspondent validation policy in order to accept/deny user access for a
> grid application.

	I don't think so. The relying party should decide by itself how much 
trust it gives to any particular CA and their requirements may differ. I 
can hardly imagine how could the OCSP service know about the level of 
trust every relying party has towards every CA.
	Moreover this goes against the principle of authentication and 
authorization separation and IMHO could not be considered a good practice.

[...]
	
> -In the case of Trust Chaining for different CAs, we believe that this
> feature should not require a high overhead because the OCSP Responder will
> be signing with the same cryptographic keypair (only the public certificate
> is changed according to the CA hierarchy being processed).

	Sorry, I don't see the connection to trust chaining (perhaps we differ 
in understanding the term). Could you explain your view, please?
> 
> 
	Regards
-- 
						Milan Sova
						sova at cesnet.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OCSP_Requirements_for_Grids_ms.doc
Type: application/msword
Size: 131072 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/caops-wg/attachments/20050316/489aaf82/attachment.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2191 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/caops-wg/attachments/20050316/489aaf82/attachment.bin