Re: OFFICE-2656: Default Signing After Encryption is Unacceptable

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Dennis,

I will explain below why the option to sign documents after encryption 
is worthy, but there are a few details regarding digital signatures in 
ODF 1.2 that we most not overlook:

In part 3 (packages) we specify a framework for digital signatures. We 
do not make any assumptions what is signed, or how signatures get into a 
package.

In part 1 we specify two kind of signatures based on the framework, 
document signatures and macro signatures which define what needs to be 
signed. These are two special kind of signatures, but applications may 
implement any other kind signatures, if they like.

So, rather than objecting to a particular kind of signature (which by 
the way works in practice for months and did not get any negative 
feedback from users), I would prefer to get a proposal for the kind of 
signatures you think are useful. This may include extensions to the part 
3 digital signature framework that are required to implement these.


On 05/05/10 23:30, Dennis E. Hamilton wrote:
> I finally figured out how we were talking past each other on #1.  
> 
> I had no idea that the way it is implemented now is that the signing is done after encryption in OO.o 3.2 when both are done.  I noticed only yesterday that the only way the signing+encryption ceremony works in OO.o 3.2 is to specify encryption on Save As and then request a digital signature afterwards.  Even then, it was inconceivable to me that this case would have the signing actually happen after encryption.  I just couldn't believe it and I ignored what I now see as obvious.  Having looked carefully at the proposed wording on what to do with an unencrypted signature document, one more time, I finally got that the new statement is not a mistake, it describes what the OO.o implementation is actually doing.  That only took me 5-1/2 days. 

You sign a document to ensure its integrity (at least that is one reason 
  for signing). What you sign is not a model of the document in memory 
(which may change), but the bytes you stored on the disc. For that 
reason, you have to store a document before you can sign it.

Encryption is part of the storing process. That's why you sign the 
encrypted document if the document is encrypted.

Further, you can sign a document at any time. You may for instance 
receive a document from someone, have a look at it, and sign it. In that 
case, it is neither required nor wanted that you store the document again.

Or to explain it differently: Encryption is part of the storing process. 
Signing is a separate process, but requires a stored document, because 
you need the stored ODF document in oder to sign it.


> 
> Now I get it.  So when OO.o 3.2 sees a META-INF/documentsignatures.xml, it knows that the signing process was tricked into signing the compressed files because they look like uncompressed raw files (though the MIME types certainly don't agree and I guess the decryption process has to compensate for any useless Transform entries, unless the Transforms reflect that it is not the XML file but an encrypted-data blog that is being signed), and it verifies that signature before anything else happens.  Then any decryption happens.  
> 
> What a clever hack.

You may consider it a hack, but it is actually intended and required 
that signing happens after encryption (or at least after storing a 
document).

But of course, one may decrypt the encrypted streams before signing 
them. Regarding the integrity of a document, this does not make a 
difference, because the encrypted and the unencrypted streams are 
equivalent. But you then would need a password to sign the document, and 
even worse, to actually check the signature. This would make it for 
instance impossible to check a signature before forwarding a document, 
or to implement gate-keepers that block documents that are not signed or 
whose signature is not valid.

Best regards

Michael

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