Re: [dss] CMS (request for comments)

[Trevor Perrin <trevp@trevp.net>]

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