Re: [dss] CMS (request for comments)

[Andreas Kuehne <kuehne@klup.de>]

Trevor !


>>>> 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.
>
>
> Well, I dunno - input documents could be large (for code-signing, say, 
> or an S/MIME attachment).

Well, thought about signed jars as detached signatures .. the classes 
aren't included in the signature, are they ?

>> I would suggest the usual approach : The core rejects 
>> co-/counter-signatures, a special profiles handles it.
>
>
> Yeah, after looking into it some more, it seems that 
> co/counter-signatures in CMS aren't used much if at all.  So I agree 
> with not supporting them in core.  Someone can write a more elaborate 
> profile if they want.

Yes, it's the beauty of the core/Profile approach I appreciate more and 
more !

Everyone understands the core, noone has to read through precautions 
made for problems he hadn't heard of, yet ( like German Sig Law, linking 
timestamps, ... ). And you just have work through the two or three 
profiles your interested in.

Greetings

Andreas