OASIS Open Document Format for Office Applications (OpenDocument) TC

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

  • 1.  Re: OFFICE-2656: Default Signing After Encryption is Unacceptable

    Posted 05-06-2010 07:51
    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