ODF Document Privacy and Security

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

In today's call, a variety of topics related to document privacy and
security came up.  

It is worth adding a topic on this for the "State of Interoperability"
insofar as this is a place where there are concerns for what is and is not
done in this area.  Document protection features are an interoperability
case as well, although it is not a security or privacy case.

AES ENCRYPTION

Svante raised questions about whether AES-CBC is being used with ODF
documents, and it is.  Here's more.

  1. It is true that there are attacks against AES-CBC encryptions used in
TCP-IP transmissions but ODF documents are not vulnerable to that particular
attack vector.  However, there is reason to discourage the use of AES-CBC
when there is an alternative (as in the *next* XML Encryption specification
that is being proposed) simply because simple mention of AES-CBC will make
people who don't understand the limitations of the vulnerability nervous.
(The same can be said for the history of SHA1, even though SHA1 is still
perfectly good for certain applications, including it still being the only
digest algorithm generally used in digital signatures.)

 2. ODF 1.2 Limitations.  Some implementations have switched their
production of encrypted ODF packages to providing AES256 CBC by default.
And current implementations of LibreOffice and Apache OpenOffice will
definitely accept such encrypted documents.  From a cryptographic
perspective, there is nothing wrong with using AES256 CBC in place of
Blowfish CFB, the default.  However, the ODF 1.2 specification asserts that
Blowfish CFB is the only algorithm allowed in *conformant* ODF 1.2 Packages.
The alternatives, even though from the XML Encryption specification, are
only used in Extended ODF 1.2 Packages.  

 - Dennis