Re: [dss] Action point on PRocessingDetails and reports

[Trevor Perrin <trevp@trevp.net>]

At 04:18 PM 12/3/2003 +0100, Juan Carlos Cruellas Ibarz wrote:

>Trevor,
>
>This message deals with the action point on me for giving some inputs
>on the processing details.
>
>First of all I have to say that my view of this issue is to have elements
>in the answer allowing the server to tell to the client:
>
>"I have verified your signature and the verification has failed.
>By the way, during the verification, the cryptographic verification
>of the signature was OK, the validation of your certificate was OK,
>the validation of the certificate of your CA was OK, BUT the
>validation of the certificate of your CA's CA did not succeed because
>it was revoked...."
>
>What this means is that we would need a way of allowing pairs of
>(object,status) that could be integrated in the response.
>
>With the current structures in section 4.5.8 this is not possible.
>If I have correctly understood they just allow to give high level details
>but not associated with a specific token (ie, a certificate in the CertPath).

Yes.


>They do not allow either, for instance to report problems like "unable to
>contact a OCSP server", or "unable to retrieve the CRL that has to
>be checked for validating this certificate in the certpath".

They let you report these problems in a general way.  For example, both of 
the above would be reflected as:
   <IndeterminateDetail>RevocationStatus</IndeterminateDetail>

This doesn't tell you exactly what failed, or exactly why it failed.

But it's also easier for client and servers, and, well, specification 
editors :-), since we don't have to enumerate every reason why 
revocation-checking might fail.

Also, it's PKIX-agnostic.  It would be nice if things didn't depend on 
specific X.509 technologies like CRLs, OCSP, etc..  Then we could use the 
same structures regardless of the underlying key infrastructure (X.509, 
XKMS, PGP, SPKI, etc...).


[....]

>I am sure that there would be other ways of structuring this information
>(for instance, it could be thougth in
>the other way around: the tag of the element indicating the token type and
>to assign QNames to the reasons)
>  but the question remains, would we
>like to have in the DSS a detailed reporting mechanism allowing the server
>to give such a detailed information
>on each token it has dealt with? If the answer is yes, then we can start
>discussion on the specific structures...
>What appears above is just a proposal..

I'm not sure if we want such a detailed mechanism.  I doubt many clients 
would be able to make use of such detailed reports.

If we do, though, maybe we could combine approaches, and have general 
structures, like the current ones, but also have optional details that give 
specifics?  We could perhaps keep something like the current structures, 
but each <ValidDetail>, <IndeterminateDetail>, or <InvalidDetail> could 
also contain a list of your <StatusReasonTypes>.

Just a thought, I don't have a definite opinion here yet.


Trevor