Re: FW: [dss] Comments to draft 6 Use Case requirements

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

Trevor, see  my comment below:

>
>> >.       Ability to retrieve signature verification results, if authorized
>>to
>> >do so.
>>
>>When would this be useful?  Why would Alice want to retrieve Bob's signature
>>verification results?
>>
>><ed>
>>If Alice is the lawyer and Bob is the origin signator over a legal document,
>>Alice would need evidence of the signature validity. This Alice would do by
>>requesting an "IssueReceipt" option on the verification request from the
>>Trusted Service Provider (EPM operator).
>></ed>
>
>As I understand it, Alice will request a Signature Verification, with an 
>option to receive a "receipt" that the signature was valid at that 
>time.  EPM implements this receipt as an RFC 3161 Timestamp on the signature.
>
>We have a few ways this or similar things could be done in our 
>protocol.  Which shows that we need to think about this some more.  But to 
>recap the alternatives:
>  - client could request the "Verify" operation with the "Return 
>Information used in Verification" option, to procure the CRLs or OCSP 
>responses the server used.  Which is similar to a receipt, in that it would 
>help a relying party verify the signature.
>  - we recently discussed the ability to request a signed verification 
>response from the server.  I was going to add that into the next document.
>  - the client could request a signature or timestamp on a signature, and 
>the service could verify the first signature as a prelude to 
>counter-signing or time-stamping it.
>  - the Verify operation with the "Return Information used in Verification" 
>option could verify the signature and then return it time-stamped, or 
>counter-signed.  I was suggesting this but now I'm not so sure, cause the 
>server isn't really returning information used in verifying, but creating 
>new information.
>
>So this is confusing, I don't know what to do here.
>

About the third one I would say that this case refers to a request of
"sign" that includes a "verify" as first step....

I do not like very much the last one, because as you say the server
would not return information used in verification...

Instead, you could consider to add  one more option: 
  - client could request the "Verify" operation with the "Return 
Information used in Verification" option, to procure the CRLs or OCSP 
responses the server used AND a time-stamp on the whole structure formed 
by the signature verified and the cryptographic material
(which would prove that at the time the verification was done, the
cryptographic
material was OK).


>[Question about EPM: it seems like the "ApplyPostmark" option requests the 
>service to add a postmark to the signature, and the "IssueReceipt" option 
>requests the service to return the postmarked signature.  Is that correct?]
>
>
>
>Anyways, it seems that a few EPM requirements are out of scope for DSS, and 
>thus that EPM should probably be a "superset" of DSS - that is, EPM could 
>use DSS for signing and verifying, but would have its own, additional 
>operations for things like Non-repudiable Delivery and Logging of 
>Events.  Does that make sense?
>

I agree with you, Trevor.

>[1] http://lists.oasis-open.org/archives/dss/200306/msg00090.html
>
>Trevor 
>
>
>You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
>