RE: [office] Extended conforming packages and manifest:algorithm-name

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

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