OASIS Open Document Format for Office Applications (OpenDocument) TC

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

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                
                                                
                                            

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

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

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

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

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

Hi

On 6 May 2010 11:51, Thorsten Behrens 

I don't know what it means to use an automated process to verify a
document's integrity.  I'm not sure which sense of integrity we have in
mind.

Signatures are good ways to deal with authenticity, depending on what it is
the signature attests to that is not refutable.  My reading is that XML Dsig
does not establish what that might be, although it recognizes that the
nature of the signing might embody some sort of claim when a document is
signed in that manner.

If you are concern that the document has not been damaged in some way, and
then encrypted, it is up to an entity with the authority to decrypt it to
determine that.  Almost by definition, no other entity is trusted to do
that.

If we want to know that the package is undamaged and is not a counterfeit,
having some sort of external verifier that a received file is the one that
was created for that purpose can be accomplished by other means. These are
sometimes called signatures, but they don't require XML Dsig.

Digests are good enough to be thought of as signatures in this specific
case, and if we want to be fancy, signed digests can be (and are) used.
None of these practices have to dig into the package at all and there is no
concern for package-internal encryption, digital signature, or any other
presumed structure.  I suspect that is why HMAC stands for Hash-based
Message Authentication Code.  

Is it this last kind of authentication you are concerned about?




                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Malte.Timmermann@Sun.COM [mailto:Malte.Timmermann@Sun.COM] 
Sent: Thursday, May 06, 2010 02:04
To: David LeBlanc
Cc: dennis.hamilton@acm.org; 'Patrick Durusau'; ODF TC List
Subject: Re: [office] OFFICE-2656: Default Signing After Encryption is
Unacceptable

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.

[ ... ]