Hello. Jesus Luna Garcia wrote:
Dear all,Thanks - jetlagged midnight in Seoul ;) I'm including the document for the CAOPS list members for reference and as an invitation to the discussion.
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").
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: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.
-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.
For example, due to the dynamic nature of the mechanism, we find that theIf 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?
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 ),
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 ResponseI 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.
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.
Sorry, I don't see the connection to trust chaining (perhaps we differ in understanding the term). Could you explain your view, please?-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).
Regards -- Milan Sova sova@cesnet.cz
Attachment:
OCSP_Requirements_for_Grids_ms.doc
Description: MS-Word document
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature