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

[Olle Mulmo]

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