[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [dss] Comments to draft 6 Use Case requirements
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]