RE: [dss] "Required" Designation on SignatureObject within VerifyRequest

[Trevor Perrin <trevp@trevp.net>]

At 10:54 AM 4/16/2004 -0400, Edward Shallow wrote:
>All,
>
>     Your Alice and Bob analogy is a good one. I contend it will be easier
>for implementors to simply verify all signatures pointed to by the
>WhichDocument sub-element.

It probably depends on whether the client or server knows where the 
signature(s) are, in the input document.  If the client knows and the 
server doesn't, it's easier for the client to indicate the signature(s) 
then for the server to search for them.

OTOH, if the client would not naturally know that, then we're adding a 
potentially onerous requirement on the client.


>I would also contend that only verifying selected
>signatures in a multi-signed document is the special case, and that anything
>less than total verification is in fact the security flaw and not the
>reverse.

That makes sense.


>  What of co-signatures over the same data where the malicious
>individual changes the referenced data. Should the caller assume that the
>1st signature is still in fact valid. Or worse, are you advocating that they
>be obliged to call the DSS implemntation several times once for each
>signature ?

As things stand, the client would have to call the server for each signature.

The verify protocol is designed to verify individual signatures, not whole 
documents, and it would be hard to change that.  What if one signature 
fails and the other succeeds?  Or they both succeed or fail but with 
different result codes (see 4.4)?  Or consider these options:
  - ReturnSigningTime / SigningTime
  - ReturnProcessingDetails / ProcessingDetails
  - ReturnSignerIdentity / SignerIdentity
  - ReturnUpdatedSignature / UpdatedSignature

How would these work if there were multiple signatures being verified by a 
single request?

In a sense, you're arguing for a document-centric verify protocol instead 
of a signature-centric one.  I.e., you want the protocol to take a document 
and say "this document is good", whereas the current protocol takes a 
document & signature and says "this document matches this signature".

The signature-centric approach is lower-level, and lets the client control 
things in more detail.  The document-centric approach doesn't allow as 
detailed control but is simpler.

At this point, we're fairly committed to the signature-centric 
approach.  It would take a major overhaul, if not a new protocol, to 
support document verification.

I don't think this is worth it if this is just a minor client 
convenience.  OTOH, if there are important use cases where the client can't 
be assumed to know where the signature is located, then the 
signature-centric approach won't work.

So: It would be helpful if people provide feedback on whether 
"signature-centric verification" is sufficient for their use cases, or 
whether "document-centric verification" is needed.


Trevor