Hi Thorsten,
it's not worth discussing which of all possible scenarios is the most
useful one.
The specification should allow the different scenarios, and not hinder
any valid use case - everything else is up to the application.
Malte.
Thorsten Behrens wrote, On 05/06/10 12:51:
> Malte Timmermann wrote:
>> I fully agree that there are valid use cases that the signature of an
>> encrypted document MAY also be encrypted.
>>
>> But you also should agree that there are valid use cases to not encrypt
>> the signature, because you then can't verify document integrity in
>> automated processes w/o knowing the encryption keys.
>>
> Hi Malte,
>
> well I guess it's really the other way 'round. Honestly, the
> overwhelmingly standard case is to sign first, then encrypt
> (RFC1991, 2440, etc etc). Simply put, encryption means protecting
> document content from plain sight. A signature is part of the
> document, and usually conveys at least some amount of likely private
> information, so the default really should be to encrypt that, too.
>
> Apart from that, all the nice things from DSIG like only signing node
> sets really only work with access to the unencrypted xml streams -
> so I truly feel that signing encrypted documents is the special
> case, and signing first the norm, with a wealth of useful variations
> suddenly then getting straight-forward, instead of being a hard
> problem.
>
> Signing first really is sine qua non - everything else is optional.
>
> Cheers,
>
> -- Thorsten
