Re: [dss] Action point on PRocessingDetails and reports

[Trevor Perrin <trevp@trevp.net>]

At 04:41 PM 12/4/2003 +0100, Juan Carlos Cruellas Ibarz wrote:

>Trevor,
>Thanks for your answer... see below.
>
> >
> >>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...).
> >
>Well, I would say that it is a question of balance between agnosticism and
>usefulness in certain environments... if this is something that somebody
>could request (and I remember some previous email in our list in favour
>of details of verification process -the question is how deep they have to
>be), it would be worth to have it.

Here's the email thread - you and Andreas were proponents of this:
http://lists.oasis-open.org/archives/dss/200306/msg00035.html





> >
> >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.
> >
>
>The proposal I sent was based on specific requirements of the entity
>that wanted to have such a feature....
>
> >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>.
> >
>
>That could be a good solution....this is what I was thinking that could
>come up: some kind of combination....
>Should we then try to work in that direction these week and half left
>until the next conf call or would you like to hear more opinions on that?

If you wanted to spec out such a combined approach, that might be a good 
base for further discussion.  Also, we could try to get Andreas's opinion.

Trevor