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

[Trevor Perrin <trevp@trevp.net>]

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.

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?


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

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

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

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.

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.

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


Trevor