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

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

Hi Trevor,

    Before I go on, thanks for your patience. I suspect this is not as
obvious as either of us thought going in.

Intermixed. 

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

At 12:02 AM 4/19/2004 -0400, Edward Shallow wrote:
>Trevor,
>
>I like your suggestion on optional outputs scoping. Very neat and tidy.
>But for the same reason, I don't like a brand new SignatureObject 
>sub-element. Especially since I do not want to use it all in the 
>scenario we are discussing. I simply want to Verify the InputDocument 
>(i.e. the DocumentWithSignature). In fact it would work nicely with you 
>new scoping suggestion. I do not think it changes the entire semantic.


Right now the semantics of <SignaturePtr> is "verify this signature".  

<ed>
I read it more as "Here is the signature I am referring to in this request".

</ed>

With your change <SignaturePtr> would become usable as a "document pointer",
not a signature pointer, with the semantics "verify all the signatures in
this document".

This semantics would require new result codes, processing rules, and
optional ouputs "scoping".  I would rather these things be in a profile, not
>>core.  If they're in a profile, then it seems appropriate for the "thing"
that triggers them to be in the profile with them - i.e. to have a new
<SignatureObject> sub-element, instead of making a syntactic change to the
core which only makes sense in conjunction with a particular profile.

<ed>
Yes, but it constrains the profile. Worse it forces the profile to introduce
new elements solely because of a restrictive multiplicity setting. The
element make-up serves the purpose. InputDocuments and SignatureObject can
both be initialized, or either can be initialized. I believe you are over
emphasizing the loss associated with making element optional.

In the simple single signature CMS Verify, both elements are not required.
This scenario alone can justify the change to [Optional]. The fact that a
profile can decide to support multiple signatures in a document is specific
to that profile and IS NOT the primary reason the [Optionality] is being
changed.
</ed>


Trevor