Re: [dss] CMS (request for comments)

[Andreas Kuehne <kuehne@klup.de>]

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.

So we support every type of signature format .. as long as the client 
tranforms it to our structure ;-)

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

In 1980 I built my first modem with 300 baud. This gadget would have 
caused the need for this otptimization.


[...]

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


I would suggest the usual approach : The core rejects 
co-/counter-signatures, a special profiles handles it.


Andreas