[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Extended conforming packages and manifest:algorithm-name
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]