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

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

You are missing the point. Are you saying that profiles are categorically
restricted from pursuing scenario-specific support of multiple signature
verification ?

In my mind it is a value-to-the-customer question. You're saying keep the
protocol acedemically pure, I'm saying allow profiles to exercise some
flexibility. If a profile puts higher value on a constrained multi-signature
verify, why would you object. Stick to the core, and allow profile authors
to decide what extensibility mechanisms they wish to exploit based on their
subjective assessment of value. Clearly I place higher value in being able
to support counter-signing and co-signing albeit in a constrained way.
Again, even in our profile, this would be for selected scenarios only, and
other scenarios would salute the core to the "T".    

See comments inter-mixed below.   

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

At 06:56 PM 4/16/2004 -0400, you wrote:
>[...]
>- ReturnSigningTime is primarily intended as an optional input 
>directive on a sign not a verify

It's intended for verify.

<ed>
But where will you obtain the SigningTime if a timestamp has not been added
as part of the Verify. Hence my point of better addressing this on the sign.
If the client simply wants the entire document and all signatures verified,
then yes disallowing it makes sense. It is a simple question of value.
</ed>

So how would we handle it? -
  1) Disallow it?
  2) Allow the client to target the option at a particular signature? (i.e. 
the client would say: verify all signatures, but only return the signing
time for *this* one)?
  3) Have the option apply to all signatures, in which case the server needs
to return multiple response elements, with a tag indicating which response
goes with which signature?

<ed>
If this were an issue at all, which I doubt it would be, I'd go for your 1)
on this one. 
</ed>

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

I think we'd have to modify this to follow one of the 3 approaches above.

<ed>
This one is defintely a 3).
</ed>

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

The point of this element is for the server to return the identity, to save
the client the difficulty of parsing the cert.  So again, we'd have to
follow one of the above 3 approaches.

<ed>
No this is academic, you haven't looked at the example, so its hard to
debate. Here I reverse the tables and say ... so now your concerned with
client convenience. Not a problem in XMLDSIG in my mind, and as for
CMS/ASN.1 we address this with an optional output. No issue.  
</ed>

>- ReturnUpdatedSignature - this one I would simply constrain when 
>multiple signatures exist within a document, the profiling allows for 
>that

<ed>
Simply constrain under this special scenario (i.e. multi-signed docs), and
support in all others. It is the profile's purogative. 
</ed>

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

The same logic applies to the other verify options -
<ReturnTransformedDocument>, <VerifyManifests>, <VerificationTime> and
<AdditionalKeyInfo>.  Do these apply globally or to specific signatures?
Also, you didn't mention how the result codes in 4.4. should be handled when
the signatures have different results.

<ed>
Urn:oasis:names:tc:dss:1.0:result:ValidDocument_AllSignaturesVerified
Urn:oasis:names:tc:dss:1.0:result:InValidDocument_NotAllSignaturesVerified

For the second URI, consult ProcessDetails
</ed>

The verify protocol is pretty simple to begin with.  Changing this many
things (<SignatureObject>, behavior of all options, server processing, and
result codes) is pretty significant.  Let's not do it unless we really need
to.

<ed>
We are not asking that the core to do it. We simply need the core to allow
the profiles to.
</ed>

Are there cases where the document-centric approach *needs* to be taken,
because the client is unable to locate and identify the signatures?

<ed>
Over-simplification. No comment.
</ed>

Ed