Re: [dss] CMS (request for comments)

[Andreas Kuehne <kuehne@klup.de>]

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

>  - PROS:
>     - allows client to verify any co-signature or counter-signature
>     - allows client to use client-side hashing
>  - CONS:
>     - may require modifying CMS libraries to support extraction of a 
> SignerInfo (on the client-side) and its verification on the server-side

>
> 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 ? It can do hashing whenever it's appropriate !

>    - 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 ? Maybe there is a 
problem with returning multipe <SignerIdentity> elements ?
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.


Greetings

Andreas