RE: [dss] CMS (request for comments)

[Trevor Perrin <trevp@trevp.net>]

At 10:20 PM 4/22/2004 -0400, you wrote:
>Andreas,
>
>Trevor stated ... "To deal with this, Ed suggested semantics where
>co-signatures and counter-signatures are not allowed" ...
>
>Actually this is not quite true.


That's how I read this email:
http://lists.oasis-open.org/archives/dss/200404/msg00124.html

The text you quoted below doesn't say anything about CMS with multiple 
SignerInfos.

Could you state clearly what you think core handling should be when a DSS 
server receives a SignedData with multiple SignerInfos?


Trevor



>  Here are the semantics I suggested:
>
>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.
>
>Ed
>
>
>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: April 22, 2004 12:56 PM
>To: kuehne@klup.de
>Cc: dss@lists.oasis-open.org
>Subject: Re: [dss] CMS (request for comments)
>
>At 05:19 PM 4/22/2004 +0200, Andreas Kuehne wrote:
> >Hi Trevor !
> >
> >>SignerInfo approach
> >>------------------------------
> >>  - client extracts a SignerInfo from SignedData
> >>  - client sends SignerInfo inside <SignatureObject>/<Base64Signature>
> >>  - client sends enveloped or detached content as an input document
> >
> >In the case of detached content, the certificates get lost, aren't they ?
> >Afaik they are not included in the CMS-SignerInfo, just referenced by
> >'IssuerAndSerialNumber' ...
>
>Good point - the certificates are contained in SignedData, not SignerInfo,
>so they get lost.
>
>The client would have to extract the certificates as well as the SignerInfo,
>and send the certificates in
><OptionalInputs>/<AdditionalKeyInfo>/<KeyInfo>/<X509Data>/<X509Certificate>
>elements.
>
>
> >>SignedData approach
> >>------------------------------
> >>  - client sends SignedData inside <SignatureObject>/<Base64Signature>
> >> (as above)
> >>  - if a detached signature, content comes in an input document
> >>  - if an enveloping signature, content is inside SignedData (and no
> >>input documents)
> >>  - if there are co-signatures or counter-signatures, the server will
> >>reject the request
> >>  - PROS:
> >>    - easy to do with pre-existing CMS libraries
> >>  - CONS:
> >>    - doesn't support client-side hashing for enveloping signatures
> >
> >Why should I do client-side hashing in this case? The server will get
> >the complete content anyway?
>
>Right - the benefits of client-side hashing (bandwidth-savings, privacy)
>can't be achieved.
>
>Actually, that's not quite true - the client could re-code the enveloping
>signature as a detached signature.  In other words, the client could remove
>the enveloped data.  This requires changing the length fields within the
>SignedData, so it's a little more surgery than just extracting SignerInfo's
>and certificates, but it's possible.
>
>
> >>   - doesn't support co-signatures or counter-signatures
> >
> >Hmm, if he server got the complete SignedData structure, what's holding
> >it back from calling a pre-existing CMS library fully capable of
> >verifying any type of  co- and counter-signatures?
>
>Nothing.  The problem is communicating these results to the client.  For
>example, what it one co-signature fails and one succeeds?
>
>To deal with this, Ed suggested semantics where co-signatures and
>counter-signatures are not allowed.  There are other approaches we could
>take:
>   - try to communicate multiple results
>   - allow the server to choose which signature to verify and return some
>indication
>   - allow counter-signatures but not co-signatures etc..
>
>If you have a preference, we'd like to hear it.
>
>
> >  Maybe there is a problem with returning multipe <SignerIdentity> elements
>?
>
>The problem is broader - we'd need to return multiple result codes, and most
>other optional outputs are signature-specific as well.
>
>
> >Do I missed an important issue ?
> >
> >>    - requires making <InputDocuments> optional
> >
> >Yes, I don't like weakening the schema. But I would accept this for
> >enabling CMS in the core.
>
>Thanks - I'm noting this as a preference for SignedData.
>
>
>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
>.
>
>
>
>
>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.