EPM use cases: some questions and one requeriment.

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Dear all,

Below follow some questions and comments
with a proposal for adding a new requirement to be
added in section 3.6 (verification request requirements).

1. Use case 1 original text: "The archival record includes the hash
of the document, optionally the signature containing the
document, information on the CRL verification process, the
timestamp and the EPM refernce data"

It seems to me that the only optional item in the list above
is the "signature containing the document", is my assumption
correct, Steve?

The second question is what exactly is "information on
the CRL verification process"? is it the final result (valid/unvalid)
of the verification? or is it the set of fields that appear in 
elements of type X509InfoType -X509ValidationData?

I guess that in the use case not only CRL but also OCSP
can be used to verify the signature....

Now, the coment, If the answer to my second question is
that what is stored is X509ValidationData, and I have correctly
understood that field (an OCSP reponse -and perhaps a CRL?),
then we are facing a situation of a service that provides in fact
a signing feature and a archival feature. And the last one 
includes capability for store not only signatures but also
the cryptographic material that once was used to verify them.
And in the VerifyOptionsType, the requestor CAN REQUEST the
storage of non repudiation evidence.

Translating this situation to our services, I think that the
validation service should be designed in such a way that
the requestor COULD request from the service, not only
the validation result but also the cryptographic material
used for that verification. Indeed section 3.7.5 explicitely
says that the sevice "may also return information used
in verification). 
Section 3.6.2 talks about "Explicit key and validation
info submitted by client (Certificates, CRLs, OCSP
responses). To me, this means that the text contemplates
the possibility of the client sending the validationdata. 
I would say that there will be lots of
times when client will not want to get involved in
looking for CRLs or answering to OCSP servers.
What is missing is to allow him to request this validation 
data as part of the answer.

And as in the list of requeriments for Signing Request, we have
section 3.4.4 Explicit Signed/Unsigned Attributes,
I think that we could add something similar to section 3.6:

INITIAL PROPOSAL:
"3.6.3 Explicit Unsigned Attributes
The client may ask the server to insert particular attributes
in the signature, as for instance, the validation data (CRLs or
OCSP responses) used in the validation, for storage purposes."

Please note that we only talk about Unsigned Attributes (ie,
attributes NOT signed by who has produced the validated
signature).

Regards

Juan Carlos.