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

[Trevor Perrin <trevp@trevp.net>]

At 01:07 PM 7/8/2003 +0200, Juan Carlos Cruellas wrote:

>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....

Right.  That's why this is tricky, it combines Verifying, then Signing, so 
it doesn't fit well into either of our protocols.

So here's another option.  Maybe the client could send a request containing 
a single document payload but multiple Sign/Verify operations.  So in an 
EPM-ish case, where a recipient of a signed document wants to both check 
the validity of the signature (Verify), and get the server to counter-Sign 
it to assert its validity, the client could send a signed document and 
request both Verify and Sign operations.

Since the document might be large, and Verification might be expensive, it 
makes sense to collapse these into a single request instead of having the 
client first call Verify and pass the whole document, and then call Sign 
and pass the document again, and require the server to Verify the signature 
again as a prelude to counter-signing.

As a side benefit, this would let the client request multiple signatures on 
a single document (sign here and here and here), and also verify multiple 
signatures on a single document.

More complexity, but note the requirements are already split into Generic 
Request Requirements that deal with the document payload, and 
Signing/Verifying Requirements that deal with the operations.


>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).

Maybe if we did what I just suggested, we wouldn't need the "Return 
Information used in Verification" option.  That description is sort of a 
misnomer - we're asking the server to augment the initial signature with 
revocation data and/or a timestamp, which sort of fits better in the 
Signing protocol then the Verifying, since the output is a signature.

So if you want to both Verify a signature, and get the server to add 
verification info and timestamp again, you would request both the Verify 
and Sign operations.  The Verify operation to learn about the current 
signature, the Sign operation to produce a new signature (even though it's 
just the old signature with new stuff added)..

Trevor