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"). 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. 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 ), or the level of revocation of a certificate (definitely revoked or simply suspended) could help to complete the OCSP Response. 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. - In our modest opinion, the set of extensions or services suggested in the final document, should present which ones could be useful on Grid environments, keeping always a balance between performance and security while providing a flexible security policy model. -Regarding to performance and extensions, initial testing has shown that parsing a couple of OCSP Extensions means an overhead of about 0.018 secs when comparing to an OCSP Response without them embedded. This time is relative due to the hardware being used - in our case, a Pentium III at 450 MHz. Even though the initial results do not seem to decrease considerably the efficiency of the responder, we are hoping to send you more results as soon as possible (Proxy Generation and Validation, etc.). -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). Best regards, Oscar & Jesus Milan Sova wrote:
Hi Oscar, Jesus. First I'd like to say sorry I could not make it to Amsterdam in February to meet you - maybe next time? Thanks for your input. My comments to your version of the document are inline. One "global" comment here: I'm not too optimistic about defining new OCSP extensions. I'm afraid nobody is going to implement them unless they are properly standardized (or really widely used, which is, of course, a kind of chicken-and-egg problem). Similarly, overloading OCSP with authorization and "trust chaining" implementation would IMHO make bring up more complexity to the grid AA infrastructure. I'd prefer concentrating on really using the possibilities provided by current state of standards and available implementations.
Regards
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.
The minutes should be up soon, but just a few quick comments before GGF shuts down & I lose net access. OCSP defined the idea of extensions, but this wasn't really developed. There was an OCSP v2 proposed ... I think it lost out (but may exist in some form, by the author; that's theonly reason why I say "think" rather than "definitely did"). Instead, IETF PKIX focused on SCVP as a mechanism for advanced info about certs, PKI, and resolving cert issues. W3C settled on XKMS, based on their mechanisms, as a refactoring of PKI in general, and also in the "space" of advanced certificate validation/discovery / &c services. OCSP would be an internal service of one or both of these services. So, it seems to me, we should probably not look to OCSP for interesting extensions, but on one of these other protocols/standards. XKMS would probably fit in better with Globus' web services software development. Thanks, ==mwh Michael Helm ESnet/LBNL
Mike Helm wrote:
The minutes should be up soon, but just a few quick comments before GGF shuts down & I lose net access.
Thank you, we are looking forward to reading the minutes.
So, it seems to me, we should probably not look to OCSP for interesting extensions, but on one of these other protocols/standards. XKMS would probably fit in better with Globus' web services software development.
I haven't taken a look at XKMS for quite a time, but I'll read it again with the OCSP-Grid Services point of view and send some comments about it to the list.
Thanks, ==mwh Michael Helm ESnet/LBNL
Best regards and have a nice flight home! Jesus & Oscar
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@cesnet.cz
participants (3)
-
Jesus Luna Garcia -
Mike Helm -
Milan Sova