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

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

I also came upon another problem. The standard says that the signatures would all be placed in one file. It is thus not possible to have both encrypted and unencrypted signatures. You can have one or the other.

Perhaps what should be done is that the standard would say that the signature file SHOULD be encrypted, with a footnote explaining the current behavior. If you want to provide a lightweight integrity check which doesn't depend on being able to decrypt the document, then that should be in another file, using another approach, such as an HMAC.

That approach would simplify things, and complexity is the enemy of security.

-----Original Message-----
From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com] 
Sent: Thursday, May 06, 2010 9:15 AM
To: Michael Brauer - Sun Germany - ham02 - Hamburg; Malte Timmermann
Cc: Thorsten Behrens; dennis.hamilton@acm.org; 'Patrick Durusau'; ODF TC List
Subject: RE: [office] OFFICE-2656: Default Signing After Encryption is Unacceptable

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