OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] Extended conforming packages andmanifest:algorithm-name


Thanks for the clarification - our encryption implementation for OOXML is (somewhat by accident, to be honest) very much like what you're advocating - the encrypted stream decrypts to a full document that can be pulled out and stands on its own. This avoids information leaks, which you point out in your other mail.

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Tuesday, May 04, 2010 2:37 PM
To: David LeBlanc; robert_weir@us.ibm.com; 'Jomar Silva'
Cc: 'ODF TC List'; 'Michael Brauer'
Subject: RE: [office] Extended conforming packages and manifest:algorithm-name

Welcome, David!

The idea is not to rule out other algorithms than blowfish and the low-number SHAs.  There are already provisions to allow anything that [xml-enc] provides a specific URI for.  So AES is covered.  This is in the ODF 1.2 Part 3 CD01, which you can find via <http://www.oasis-open.org/committees/document.php?document_id=34822>.  (Not sure why there are two versions there.)  The schemas are at <http://www.oasis-open.org/committees/document.php?document_id=34824>.  The latest working draft on the progression to CD02 is found via <http://www.oasis-open.org/committees/document.php?document_id=37347>.

With regard to arbitrary additions, on the other hand, there is nothing to prevent a number of parties arranging that as a private agreement.  They wouldn't be anything a conforming consumer is required or expected to accept however.  Although, if I was doing that, I would do an external or wrapper encryption so that the whole Zip package is encrypted and the decrypted file and the decrypted package is a clean, conformant ODF document.  Then the parties don't need to screw around with ODF part-wise encryption to achieve their private encryption arrangement, don't have to share secret pass phrases, etc.  

I am always interested in your $0.02.


 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 



-----Original Message-----
From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com]
Sent: Tuesday, May 04, 2010 14:02
To: dennis.hamilton@acm.org; robert_weir@us.ibm.com; 'Jomar Silva'
Cc: ODF TC List; Michael Brauer
Subject: RE: [office] Extended conforming packages and manifest:algorithm-name

I've just joined today, and had intended to confine my comments to digital signature issues, but this issue caught my eye.

An argument for allowing arbitrary algorithms is that some countries have requirements to do encryption with algorithms that are specific to their country. China, Russia and South Korea are 3 examples, but there are more.
It is also true that cryptography is a relatively rapidly evolving area, and we (Microsoft Office) try not to tie ourselves to any specific algorithm for encryption purposes.

While I do take your point that interoperability is to be valued, it is the point of encryption to explicitly not interoperate with anyone who isn't authorized to see the content. We see it as a problem that the only currently allowed algorithm doesn't meet any government standards that we're aware of, and would like to be able to support algorithms that do meet standards, such as AES.

Just my $0.02 - 

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Tuesday, May 04, 2010 1:24 PM
To: robert_weir@us.ibm.com; 'Jomar Silva'
Cc: ODF TC List; Michael Brauer
Subject: RE: [office] Extended conforming packages and manifest:algorithm-name

A. I would remove the allowance of arbitrary algorithms from all conforming ODF 1.2 documents, extended or otherwise.  Anything that makes it impossible for a conforming consumer to even start consuming the document, even an extended one where foreign-element fallbacks can be applied, should not be supported for obvious interoperability reasons.  We have eliminated arbitrary compression methods and we should do the same for arbitrary encryption algorithms.

B. Remedies

 1. Everywhere in section 3.8 I would remove every bullet-item that says

       * The IRI of an alternative algorithm as specified in section 5.1 of [xml-enc] ... 

There are some other problems (for example in the last bullet of 3.8.1 of CD01, requiring producers to support Blowfish is strange when it is consumers that should be required to support it [at a minimum]).

 2. Another way to do this would be to leave this alone but in ODF 1.2 Part
1 prohibit any alternative algorithms as specified in [xml-enc] section 5.1 in packages that are acceptable for ODF documents.  This leaves alternative algorithms available for other uses of ODF 1.2 Package but not for ODF 1.2 Documents.  

I don't have a preference on which way this is achieved, so long as ODF 1.2 consumers never have to deal with alternative algorithms.  Inability to recognize the algorithm means the document can't be consumed.  Using alternative algorithms in the production of packages identified as ODF documents should not be considered achieving any level of ODF 1.2 conformance, even if it is an experimental extension.  (Seems like an experimental MIME type should go with that.)

 - Dennis


-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com]
Sent: Tuesday, May 04, 2010 12:15
To: office@lists.oasis-open.org
Subject: [office] Extended conforming packages and manifest:algorithm-name

We recently discussed removing the "extended" conformance clause for packages.  This was in :  
http://tools.oasis-open.org/issues/browse/OFFICE-2257

I think the idea was it was only used when there were additional files in the document beyond those defined by ODF.

However, I found another place where "extended" conformance is triggered. 
Part 3, Section 3.8.1 defines the allowed values of the manifest:algorithm-name attribute, and says:

"The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core].
Alternative algorithms may be specified by extended conforming documents only. They shall not be specified by conforming documents."

So if we eliminate the extended package distinction, then we allow conforming documents to be encrypted using proprietary algorithms, which I think goes against the interoperability benefits we were trying to foster by making the extended/non-extended distinction.

I don't think I'm in favor of this change.

Anyone want to argue otherwise?

-Rob

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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]