RE: [office] Encryption and data leakage

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Rob, I'm not sure I understand which approach these last concerns are about.
(I see there are now later notes in this exchange while I was writing this,
so I may be even more out of sync than I think already.)

 1. It strikes me that it is easier to make a Zip, encrypt the whole thing,
and then include it in a Zip along with a manifest and a file that provides
the encryption parameters than almost anything else.  This should work with
standard Zip-handling libraries.  In the OpenDocument case, since whatever
producer is doing this already knows how to make an ODF Package, it
certainly can make the outer wrapper using the same machinery.  One can also
avoid compression of the inner, encrypted payload Zip, so I suspect this can
be done in a single pass on top of the unencrypted save of the payload Zip.

 2. I don't think the act of full-document encryption is technically
difficult.  With regard to the encryption-descriptor, using a profile of XML
Encryption strikes me as the ideal case, it being extremely valuable to rely
on existing work in this situation.  That is probably the biggest impact on
implementers, but the benefit is also quite high.  And since products that
do XML DSig must already deal with certification stores, that aspect is
already in hand and gives us even more consistency and reliance on existing
technology.  There are likely some known libraries and more-widely available
material on threat models against the encrypting application as well.

 3. But there may be use-case issues and only implementers of OpenDocument
products can say what those specific issues are.  For example, ODFDOM would
perhaps need to adjust its model to support this and have it work at the
right point in time.  More seriously, tying encryption to Save As ... (as
now done in OO.o) would be problematic, and it would appear that signing and
encryption would both need to be operations on [being-]saved documents (just
like, for e-mail, the cases are selected in advance, even as defaults, but
it is the send[-to-outbox] that carries out the actions and requests any
Pass Phrases that are required for private keys to be accessed and
certificates to be applied, etc.  

Or were you addressing a different one of the options under discussion?
Bob was commenting about possible IP issues using PKware's proprietary
encryption and DSig arrangements.  I would avoid those simply to use a
widely-recognized standard mechanism (e.g., XML Encryption and XML DSig plus
XadES, etc.) as much as possible.

 - Dennis

(Side note: The e-mail software I use allows signing and/or encryption, with
no indication as to sequence.  I am confident that signing applies to the
unencrypted content, including attachments.)

  - - - - - - - - - - - - -
   Standards are arbitrary solutions to recurring problems (R. W. Bemer)
   Although not by becoming the recurring problem (orcmid).
  When you find yourself in a hole, stop digging.



-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
<http://lists.oasis-open.org/archives/office/201005/msg00268.html>
Sent: Wednesday, May 12, 2010 06:01
To: Bob Jolliffe
Cc: Malte Timmermann; office@lists.oasis-open.org
Subject: Re: [office] Encryption and data leakage

I'd also be concerned about library support for that form of encryption. 
Specifically, if you have a ZIP library in your platform or language 
libraries, but it does not support ZIP encryption, it will be far easier 
to code a pre-ZIP encryption method than to modify the way your system 
library handles ZIPs.

-Rob


Bob Jolliffe <bobjolliffe@gmail.com> wrote on 05/12/2010 05:22:08 AM:
<http://lists.oasis-open.org/archives/office/201005/msg00261.html>
[ ... ]