Dear all, Our suggestion to introduce information in the form of OCSP Extensions was raised because we understand that through the use of such mechanism the Validation Authority could provide dynamic information that could be useful in order to take validation decisions. We were thinking of an optional mechanism served on demand provided through OCSP. On his last email, Mike mentions other protocols that probably will be more adequate to convey such type of information. At this time we are working on a GT4 pilot that uses OCSP Extensions as proposed and we expect to present you some results soon. On the mean time, we understand that there is no need to discuss further the introduction of OCSP extensions in this document in order not to delay its publication. However, given the fact that the subject has been raised and that Mila has already made some useful comments we would like to comment on them. Milan Sova wrote:
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?
Isn't reasonCode extension capable of providing this information?
Mila, we agree with your comments. The information proposed can already be conveyed using the standard protocol. Maybe we didn't pick the right examples... but that does not mean that the extension mechanism can not convey useful information such as the CA-related attributes mentioned in our previous message.
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.
Of course that it is up to the relying party to decide by itself whether to trust or not a CA. Our suggestion here is that, given the fact that for the relying party may be difficult to have information about all the CAs that can be trusted, the VA could certify (by means of several external and independent audits) the security policies established by each CA reporting such information to the relying party.
Moreover this goes against the principle of authentication and authorization separation and IMHO could not be considered a good practice.
Agree with you for several reasons (performace above all) as the AuthZ decision shall be better taken by an AuthZ Service acting separated from the AuthN subsystem. However our point here is that as both AuthN and AuthZ processes are linked in such a way -depending on the AuthZ model being implemented- that the output from one of them is used as the input of the other; then the AuthZ Decision process may benefit itself from information purely related to the AuthN process, maybe by retrieving CA-related attributes or any other attribute considered to be adequate by the relying parties. The main purpose of these attributes is to match them against the AuthZ Policy Rules just as any other user attributes so that a final decision can be obtained. Notice that once these attributes have been received - at Proxy initialization time - no further retrieving is necessary by the AuthZ Service and according to our first results, performance is not diminished and overall security level is enhanced.
Sorry, I don't see the connection to trust chaining (perhaps we differ in understanding the term). Could you explain your view, please?
We're interpreting "Trust Chaining" not in the sense of providing transitive trust relationships between two EECs through mechanisms like cross-certification, but instead -as mentioned on the note in page 10 just before section 7.1 of the working document- by creating a one-way trust relation between a relying party and a CA (Relying Party -> OCSP Responder -> CA) by signing the OCSP Response with a private key which correspondent Public Key Certificate has been issued by such hierarchy. The only condition is that this keypair must be the same for every configured CA on the OCSP Responder (same certificate request for every OCSP Signing Certificate being requested). In practice it means that no additional overhead is produced with this solution as OCSP Response signatures are created with the same private key. Maybe it's not "Trust Chaining" in the broad sense of the word as the Trust Relation is one-way only , but we hope that the idea is clearer now... Anyway let us know any question :)
Regards
Oscar & Jesús