[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Encryption and data leakage
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> [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]