RV: [caops-wg] Re: Grid OCSP proposal

[Milan Sova]

	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 at cesnet.cz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2191 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/caops-wg/attachments/20050317/7f9794cb/attachment.bin