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

[robert_weir@us.ibm.com]

That's the intent.  There are three classes of algorithms:

1) The "default" algorithm which is SHA1+Blowfish CFB.  By default we 
really mean in the XML sense, not that it is the preferred algorithm.  In 
fact, I think it should be called something like "legacy" rather than 
"default", lest a reader get the wrong message.

2) The larger set of algorithms allowed in conforming packages from 
[xmlenc-core], which includes TRIPLEDES and AES-128, AES-192 and AES-256.

3) The open-ended list of algorithms which are permitted in "extended" 
packages  but not in non-extended packages.  For these we neither define 
the algorithm nor the identifiers for the algorithms.

I think we want to preserve that third option, not only to meet government 
needs, but also to future-proof ODF.  For example, suppose some 
fundamental crypto advance breaks AES tomorrow. Unlikely, but possible.

The point of the two conformance classes is to distinguish those documents 
that use only the well-known identifiers defined in ODF 1.2, versus ones 
that use others.

I think this is still an interop issue.  I can email someone an encrypted 
document and then send them a passcode via other means, such as SMS.  This 
will work and allow security as well interoperability.  But if the doc 
uses an unknown algorithm, then the receiver is blocked.    Also, even in 
the single user case, wanting to read my own documents 10 years from now.

That said, if there are additional algorithms that we want to reserve 
identifiers for in ODF 1.2, ones not already in Part 3 or [xmlenc-core] 
I'm open to suggestions.

-Rob


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 05/04/2010 
05:36:39 PM:

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