[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] CMS (request for comments)
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]