Re: [dss] EPM use cases: some questions and one requeriment.

[Trevor Perrin <trevp@trevp.net>]

At 10:05 AM 6/19/2003 +0200, Juan Carlos Cruellas wrote:

>Trevor,
>
>My answers within <JC>  </JC> below
>Regards
>
>Juan Carlos.
>
> >What about adding a new bullet to 3.6.2, "Whether Information used in
> >verification should be returned"?
>
><JC>See my two last answers</JC>
> >
> >You raise another interesting point - I didn't realize that 3.7.5 meant the
> >server would return this information as unsigned attributes on the
> >signature, I just thought it would return it separately.  This text is from
> >Nick, he was probably thinking the same as you.  So I would guess this
><JC>I guess that Nick was also thinking in that....</JC>
>
> >means updating the signature to an XAdES-X-L or something, with all the
> >certificate and CRL data attached?
>
><JC>In XAdES and ETSI TS 101733 (ASN.1 version), the information on validation
>data can be added as unsigned attributes in two ways: a piece of data
>giving the
>REFERENCES to such information, ie, references to certificates in certpath,
>references to CRLs and/or references to OCSP responses
>used OR the values of CRLs, certpath and/or OCSP responses.
>The first alternative is suitable for those situations where such material is
>accessible for the client.... The second one covers two situations: those
>where this material is not easily accessible to the client, and those
>situations
>when you want to archive signatures for long periods of time the signature
>and use
>recurrent timestamping (or time-marking).
>The issue then is if we consider realistic situations where someone could
>request verification of signature and ask only for references of the
>cryptographic material,
>leaving the issue of searching the material itself to other service
>(archival service) or
>to himself (perhaps in closed environments  or in situations where most of
>the
>signed documents received are coming from entities whose trust hierarchy is
>easily accessible....
></JC>

In the first bullet of 3.6.2 it mentions a "policy" to be used for 
Verification, which will be an identifier for some trust settings and maybe 
other parameters.  Maybe if we just add a way to indicate that verification 
information should be returned, we could leave it up to particular policies 
to control whether this means to return the references or the actual 
validation information.

I.e., just have the client pass a boolean to indicate whether he wants 
verification data.  What type of verification data actually gets returned 
would be determined by the particular server and policy.  This way we don't 
have to enumerate values for the different types of verification data, and 
worry about whether those values are complete for every type of 
verification data one could come up with.  Would that work?

Trevor