OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] OFFICE-2656: Default Signing After Encryption is Unacceptable


On 6 May 2010 11:51, Thorsten Behrens <tbehrens@novell.com> wrote:
> 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).

I have to agree and it is important that the standard must support
this requirement.

I can see that there is also a use case for what Malte is describing
in terms of automated workflows but to my mind this is really more of
a package signature than an xml document signature.  Where really
anything could be in the package.  The same workflow would have no
verifiable knowledge that it is dealing with odf streams.  It might
just as easily be a signed text file or jpeg.  It would simply provide
assurance that whatever is in the package bears a valid signature of
an identifiable certificate holder.  Which I can see can be useful in
constructing some workflows.

But not being a signature of xml makes it impossible to implement
things like signing parts of documents, adding visual signatures etc.
for encrypted documents.  So the use case is maybe a bit simplistic to
meet broader requirements.   What is required in the text to support
both use cases?


>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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]