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