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

[Malte Timmermann <Malte.Timmermann@Sun.COM>]

Davin, Dennis.

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.

So the specification should allow for encrypted signatures, but
shouldn't hinder not encrypted signatures in case of encrypted documents.

Wrt signing the decrypted version of the streams in an encrypted
document: It is not clear to me what this should be good for (except
that you could then sign XML data, which could also be in canonicalized
 form, instead of binary data).
Signing the encrypted streams, and using a not encrypted signature means
I can do automatic signature processing. With encrypted signatures, it
doesn't make much difference whether you sign the encrypted or the not
encrypted streams, but using the not encrypted streams means extra
processing time for decrypting them.

David - I think when MS Office / OOXML sign the not encrypted stream,
there is not a logical reason for doing so from the encryption/signature
point of view, but it's simply a pragmatic approach:

When ODF encrypts a document, the structure in the ODF (zip) package is
still the same like before, but with encrypted streams.
When  OOXML encrypts a document, it simply stores the not encrypted
OOXML (zip) package as an encrypted binary blob, wrapped in some new
OOXML package providing the encryption information. With the OOXML
approach, of course you always work on plain data, because you also
store the signature in the plain data package before doing the encryption.

Malte.


David LeBlanc wrote, On 05/06/10 02:57:
> 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 
>