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

[Oscar Manso]

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