RV: [caops-wg] Re: Grid OCSP proposal
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
Hello. Oscar Manso wrote:
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.
Great! We might get back to the topic later if needed.
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:
[...]
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 :)
I see. However, from the relying party's point of view there's no change in trust - it gets the responder location from the cert and gets the responses signed by the key certified by the CA => the relying party sees the OCSP service as if it is run by the CA. On the other hand, it's the CA which must trust the OCSP service provider... Signing the responder's key by several CAs brings up another issue: there's the "chicken-and-egg" problem with validating the responder certificate. Common solution is to set ocsp-nocheck extension in the responder's certificate and set its validity to a short time. Have you considered a mechanism for a regular re-certifying the responder? Regards -- Milan Sova sova@cesnet.cz
To avoid confusion: Please make use of proper terminology when such is defined (for once). The proper name for the "trust chaining" scenario is called "Authorized responder", and the authorization is marked by the CA via the inclusion of the ocsp-signing extended key usage. If you want a single OCSP responder instance to act as an authorized responder to several CAs, it must get an OCSP signing certificate from each CA, and include the right one depending on what CA issued the client certificate that status was requested for. Or, it can always include all certificates as it is up to the client to figure out and build the right certification path. All other responders that are not directly entrusted by a CA to provide signing are called Trusted. Trusted because you don't have the explicit consent (authorization) from the CA, and hence you need to put explicit trust on that particular responder. How you base and encode that trust (on its DN, its certificate, or raw public key) is up to you. One responder being authorized by multiple CAs is a perfectly legal and reasonably common mode of operation. I know of at least one commercial software (the one that I wrote...) that supports both the case of all CAs signing a single key pair, and the responder having multiple signing keys simultaneously, selecting the appropriate on depending on which certificate that status is requested for. /Olle On Mar 17, 2005, at 23:44, Milan Sova wrote:
Hello. Oscar Manso wrote:
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.
Great! We might get back to the topic later if needed.
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
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: [...] 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 :)
I see. However, from the relying party's point of view there's no change in trust - it gets the responder location from the cert and gets the responses signed by the key certified by the CA => the relying party sees the OCSP service as if it is run by the CA. On the other hand, it's the CA which must trust the OCSP service provider... Signing the responder's key by several CAs brings up another issue: there's the "chicken-and-egg" problem with validating the responder certificate. Common solution is to set ocsp-nocheck extension in the responder's certificate and set its validity to a short time. Have you considered a mechanism for a regular re-certifying the responder?
Regards -- Milan Sova sova@cesnet.cz
participants (3)
-
Milan Sova -
Olle Mulmo -
Oscar Manso