RE: [dss] CMS

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

Inter-mixed. 

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 20, 2004 5:33 PM
To: ed.shallow@rogers.com
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] CMS

At 11:38 AM 4/20/2004 -0400, you wrote:
>Trevor,
>
>     Yes I think you have summed up the positions well.
>
>   - what are the semantics if the SignatureObject is omitted ? That 
>the input document *is* a signature?

I had 2 previous questions about your approach to CMS:
  a) how would you do client-side hashing with enveloping CMS signatures? 
[i.e. if an enveloping signature is included in a <Base64Signature>].

<ed>
In the CMS world, there is really only detached and enveloping. Presently
the core is not sufficiently specific on SignatureType for a Sign, although
I suppose we can add additional URNs in section 7.1 to further specify CMS
sub-types. So I'd worry about handling those first. On the verify side of
each of the above, I believe we are covered. I won't repeat the suggestion
again.

On the client-side hashing, my first instinct would be to relegate
client-side hashing to profiles wishing to support it and any other extended
CMS options previously referenced in this thread. We would have to reflect
this in the Basic Processing sections. In fact your suggestion of passing in
SignerInfo could be pursued "in those profiles" if they wished.   
</ed>

b) which SignerInfos does the server verify?  All?  The first?  The one
indicated by the client?
<ed>
We would not be working with SignerInfos in the core in this scenario, so
this is rhetorical. See below for the XMLDSIG answers.
</ed>


[Trevor (again)]
>   - what are the semantics if the SignatureObject is omitted ?

<ed>
Assuming InputDocuments and SignatureObject are optional. Core semantics
could be something like ...

There are cases when SignatureObject or InputDocuments can be omitted from
the Verify request. When only one signature contained in one InputDocument
exists, XMLDSIG verification can omit the SignatureObject for enveloped or
enveloping signatures. Similarly for CMS verification of single signatures,
requests can omit the InputDocuments when Verifying CMS enveloping
signatures. The SignaturePtr construct is intended for use when either 1)
verification of a specific XMLDSIG signature is requested, or 2) multiple
XMLDSIG signatures are present in an InputDocument and multi-signature
verification is NotSupported by the implementation, and the request is
forced to specify which signature is to be Verified.

If more than one XMLDSIG signature appears in the only InputDocument and the
SignatureObject is omitted, the DSS implementation must return
urn:oasis:names:tc:dss:1.0:result:NotSupported if they cannot perform the
Verify, or perform the Verify, using any required OptionalOutputs, if they
can. If multiple InputDocuments exist, the WhichDocument element can be used
by the implementation, although it is also optional.

This small change enhances the present spec to support 1) the simplest
single signature verification scenario without the use of SignaturePtr
(which doesn't work for CMS anyway), and 2) an optional multi-signature
verification capability.

We could allow error handling to report on the first encountered signature
error only, and not change anything, or we could put your <scope> construct
into ProcessingDetails. Stopping on the first encountered error is not an
uncommon practice and would not disturb the ProcessingDetails or
ResultCodes, although the later change is trivial as I have already
suggested in this thread. As stated some of the "Return" options should be
constrained when Verifying multi-signatures. This would be the easiest and
would not overload and cross-load the options. Although changing them is
also possible. I would vote for simplicity in the scenarios that turn up
most often, like single signatures ;)  
</ed>

>Probably you're going to say it's profile-specific.
><ed>
>Yes. Default handling spelled out in the core.

Which is the default?  I listed several possible semantics and you agreed 
with all of them!

So if you want semantics like "verify every 
signature in this document", I would suggest a new <SignatureObject> 
sub-element like <DocumentAllSignaturesPtr> or something.  

<ed>
The problem with this is that this element is not a pointer but a flag or
directive and doesn't belong here. If we put a VerifyAllSignatures flag in
an OptionalInputs element, SignatureObject would still have to be made
optional. I am not against a new directive flag in OptionalInputs with
better semantics.
</ed> 

We already have flexibility to add <SignatureObject> sub-elements, so I
don't think the 
flexibility to omit <SignatureObject> gains anything.


Trevor