RE: [office] OFFICE-2656: Default Signing After Encryption isUnacceptable

[David LeBlanc <dleblanc@exchange.microsoft.com>]

I largely agree with you, but I think that you may not want to preserve behavior which is a security flaw in the standard. The signing certificate may contain large amounts of privacy-sensitive information, and if you leave that unencrypted when the intent of the user is to encrypt the document, you then have a problem. You brought up regulatory concerns in the other thread - in many countries, leaking private information can be a serious legal issue, and I would have concerns about that.

If we (Office) did that, it would likely turn into a presentation at a security conference about how we made a mistake. We recently had a presentation on how our old encryption technique had mistakes at Blackhat Europe.

The point that you may want to evaluate the integrity of a document with some automated process without knowing the password is a fine one, but that can be accomplished more easily and with much less overhead by just using a simple hash or HMAC.

I don't really see a need to sign the encrypted data, but if someone else wants to do that, that's up to them.

In my opinion, the standard should describe how to properly sign, then encrypt a document, and if someone wants to put a signature somewhere else that does something else, then that should be an extension. The standard cannot prevent implementers from making mistakes, but it should certainly only require approaches which are cryptographically solid.

________________________________________
From: Michael.Brauer@Sun.COM [Michael.Brauer@Sun.COM]
Sent: Thursday, May 06, 2010 4:26 AM
To: Malte Timmermann
Cc: Thorsten Behrens; David LeBlanc; dennis.hamilton@acm.org; 'Patrick Durusau'; ODF TC List
Subject: Re: [office] OFFICE-2656:  Default Signing After Encryption is Unacceptable

Dear TC members,

I agree to Malte here, and suggest that rather than discussing whether
the the one the other way of combining signatures and encryption should
be default or should be allowed, concentrate on the technical details.

So, we know that ODF 1.2 allows to sign encrypted documents, and we
heard voices that this is a wanted feature of ODF 1.2. Therefore we
should keep it.

But there is some uncertainty whether ODF 1.2 also supports encrypting
signed documents. So, the technical question is whether ODF 1.2 already
supports this, and if not, what needs to be done to support that.

So, the only kind of discussion that takes the ODF specification forward
are proposals or clarification that enable ODF to support encryption of
signed documents (if that is not supported already). I would like to ask
all TC members to concentrate on this aspect.

Thank you

Michael


On 05/06/10 13:06, Malte Timmermann wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


--
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
           D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz