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