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

[Patrick Durusau <patrick@durusau.net>]

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

On 5/5/2010 5:30 PM, 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.
>
> 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.
>
> I have expressed my objections in a comment on the OFFICE-2656 issue.
>
> It is my considered opinion that this is not worthy for ODF 1.2.
>
>   - Dennis
>
> -----Original Message-----
> From: OASIS Issues Tracker [mailto:workgroup_mailer@lists.oasis-open.org]
> Sent: Tuesday, May 04, 2010 05:50
> To: office@lists.oasis-open.org
> Subject: [office] [OASIS Issue Tracker] Commented: (OFFICE-2656) NEEDS-DISCUSSION: Clarify when signatures operate on encrypted and when on unencrypted files.
>
>
>      [ http://tools.oasis-open.org/issues/browse/OFFICE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19053#action_19053 ]
>
> Michael Brauer commented on OFFICE-2656:
> ----------------------------------------
>
> Regarding your clarification, item 1:
>
> I can't follow your reasoning here: If the digital signature stream is not encrypted, then all references to the signature stream reference the unencrypted data, because there is no encrypted data.
> If the digital signature is encrypted, we say that the references reference the decrypted data. So, in both cases, the signature operates on the non-encrypted signature stream.
>
> Or, is the issue maybe that we are talking about encryption only, and not about the compression that is implied by the encryption. So, when I say that an consumer shall decrypt a file, then I actually mean that is also shall decompress it. Maybe that is a source of confusion, and we should say:
>
> If a digital signature file is not encrypted, consumers shall not decrypt and decompress files that are referenced by<Reference>  elements and that are encrypted before validating the signature.
> If a digital signature file is encrypted, consumers shall decrypt and decompress  files that are referenced by<Reference>  elements and that are encrypted before validating the signature.
>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> 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)