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

[Patrick Durusau <patrick@durusau.net>]

David (and Dennis),

Thanks!

That is getting somewhat clearer.

Be mindful that under 3.4 Approval of an OASIS Standard, that we have to 
have three statements of use for the committee specification. Which 
would include the signing/encryption matters.

We have talked about putting ODF in general on more of a production 
track, i.e., the next release is already scheduled, etc., so that we 
know how to back up to set other dates.

Perhaps this is important enough for us to actually make that suggestion 
a reality.

I know there are other features that are not going to make this release 
that are of general interest.

Just a thought.

Hope you are having a great day!

Patrick


On 5/5/2010 8:57 PM, David LeBlanc wrote:
> Actually, what you want to do is keep putting the signature inside the (encrypted) archive. Here's a diagram of how it could be done:
>
> /
> /EncryptedData (stored)
> /encryption_descriptor.xml
> /META-INF
> /META-INF/manifest.xml<- just points to the encryption_descriptor
> /Thumbnails
> /Thumbnails/thumbnail.jpg
>
> Once you decrypt /EncryptedData, the decrypted archive is exactly the orginal source archive, containing all of the previous files, etc. Something that may need to be done to make icons and the like show up as they should is to put some boilerplate files so that the file seems to be of the type it claims to be, and the shell recognizes it as an .odt (or whatever) file. The outer wrapper contains no information about the file inside, except information needed to decrypt EncryptedData.
>
> You're right that any changes would break existing implementations, but only when something is signed and encrypted at once, and this is a presumably small number of users. However, that's the risk an implementer takes when they go ahead of the standard - if you zig and the standard zags, it won't be good. This is exactly why I'm participating here - I would like to implement signatures, but I want to do so against something that will absolutely conform to the standard. In no way do I want to see us (Office) have to guess at something and have that turn into a MUST NOT somewhere down the line.
>
> BTW, the signatures don't have to happen prior to encryption - the user may well choose to encrypt something from the start to avoid having the plain text ever be on disk, but the implementation needs to create the signature against the decrypted version of the file.
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Wednesday, May 05, 2010 3:48 PM
> To: 'Patrick Durusau'
> Cc: ODF TC List
> Subject: RE: [office] OFFICE-2656: Default Signing After Encryption is Unacceptable
>
> Patrick, the only proposal I would make is that the current signatures always happen before any encryption, whether or not the signature is encrypted (and it should be if there is any encryption).  That's with regard to the current state of affairs.  There would be no signing after encryption using the package-embedded ODF 1.2 digital signatures.
>
> However, that will break every digital signature implementation in previous and current versions of OO.o, including any other implementation using that part of the code base, which is why I think removal from the ODF specification might be the only option (for now).
>
> Another solution, whether or not there is removal or repair, is to go to an external/wrapper signing and encryption model.  The signing part of that is a bit problematic because it has to deal with being outside of a Zip.  That may be simply unworkable, especially as more-sophisticated signature approaches are introduced, such as XadES.  (On the other hand, since we have adopted a sign-everything whatever its form for META-INF/documentsignatures.xml, an external signature can do that little rather easily.)  But either way, external/wrapper signatures/encryptions don't have to be on the ODF 1.2 critical path and don't even have to be done in the ODF TC.  The advantage of these models, at least for encryption, is that it just makes everything straightforward, the threat models are understandable, and it is possible to vet implementations much more easily than one snarled up inside the ODF 1.2 Package and document model.
>
> Thanks for asking,
>
>   - Dennis
>
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net]
> Sent: Wednesday, May 05, 2010 15:02
> To: office@lists.oasis-open.org
> Subject: Re: [office] OFFICE-2656: Default Signing After Encryption is Unacceptable
>
> Dennis,
>
> I am trying to catch up on this issue.
>
> Do you have an alternative proposal?
>
> To the list: Discussion without the adjectives would be appreciated. I have enough closing emails to review without having to wade through non-substantive remarks. Simply stating the facts are enough. You already have my attention.
>
> Hope you are having a great day!
>
> Patrick
>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> 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
>
>    

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)