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

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

These are all good points, which must be debated and discussed. However I do
not think it has to be an all or none proposition. I'' address your specific
citings below. Remembering however that they are optional to start with, and
also that I am focusing on the Verify not the Sign where signature-centricty
makes absolute sense.

- ReturnSigningTime is primarily intended as an optional input directive on
a sign not a verify
- ReturnProcessingDetails, see line 958 of section 4.5.4 which allows for
multiple detail elements of the same type, minor changes here could easily
handle the multiple signature scenario, or profiles could extend it, or
simply get specific in the Message element (last resort)
- ReturnSignerIdentity - see the co-signed example I sent the list, Identity
is already present in the X509Data element and would cover this requirement
without any optional output, certainly not on the Verify where this debate
lies
- ReturnUpdatedSignature - this one I would simply constrain when multiple
signatures exist within a document, the profiling allows for that

I don't see this as a huge issue and I certainly do not believe it requires
a separate protocol or a massive overhaul. 

My biggest concern is that you are taking the first step in hand-cuffing
profiles from exploring these areas with this overly restrictive stance on
the core. You do not have to embrace the document-centric approach within
the core, but please do not prevent profiles from supporting it, or force
profiles to bend the core excessively.

Ed   

  

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 16, 2004 3:31 PM
To: ed.shallow@rogers.com
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] "Required" Designation on SignatureObject within
VerifyRequest

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 


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.