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

["Edward Shallow" <ed.shallow@rogers.com>]

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

    I think we have a more fundamental support problem here. I suspect
counter-signatures (over both data and previous signatures) and
co-signatures (over the same data as previous signatures) will be confusing
and cumbersome for both the implementor and the end client.

    Once again, this doesn't have to be an overhaul, but I am suggesting we
reconsider better handling in the spec of:

1) verification of all signatures in the WhichDocument pointer (by leaving
out the XPath element ?)
2) verification of only the specific signature (using both WhichDocument and
Xpath)
3) default and documented server-side handling spelled out in policy (spec
must be relaxed to support this)

Ed   



-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 16, 2004 12:32 AM
To: Ed Shallow
Cc: dss@lists.oasis-open.org
Subject: Re: [dss] "Required" Designation on SignatureObject within
VerifyRequest

At 12:12 AM 4/16/2004 -0400, Ed Shallow wrote:
>Trevor,
>
>     Please find attached a facsimile of your "challenge" document. It 
> was created in minutes with XMLSec V1.2.4 invoked through 
> Python-XMLSec bindings on a RedHat 9 platform. This signature was 
> subsequently sent back in on a Verify call to the same library 
> "WITHOUT A SINGLE XPATH REFERENCE" or any any hint whatsoever at 
> signature location within the document.

Sure, you're using a high-level function that first searches for a
<ds:Signature> element, and then calls the lower-level verify function on
this element.  If you knew where the signature was, you could have verified
that element directly.


>My point was that many libraries do not require this information and 
>consequently neither will many our DSS implementors. It is superfluous 
>and an unecessary inconvenience for clients.

Now the inconvenience is on the server-side: the server has to search for
the element, which the client could easily have just pointed to.

Furthermore, leaving things implicit adds risks: suppose Alice expects a
signed document from Bob.  But a bad-guy intercepts the document, changes
it, and adds his own signature.  If the client doesn't tell the server which
signature to verify, the server might verify the bad-guy's signature and say
"A-OK", but the client would think the server had verified Bob's signature!

So at best this is a small special-case simplification; at worst it's a
security flaw.  I'm still opposed to it, but I've flagged it as an open
issue in wd-19, so we'll see what other people say.


>     What I am asking is a trivial change. Simply remove the [Required] 
> designation on the SignatureObject. I have just shown to you a 
> perfectly legitimate (and implemnted) example of when it is.

It's a trivial syntax change.  It's non-trivial in its effect on server
processing, and security.

Trevor