RE: [dss] CMS (request for comments)

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

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