ODF 1.2 Part 3 section 2.4 (Encryption)

[Jesper Lund Stocholm <4a4553504552@gmail.com>]

Hi ODF TC,

Description:

Section 2.4 of ODF 1.2 Part 3 describes how to encrypt an ODF package
as well as storing information needed to decrypt the package again.

Section 2.4 describes in detail the required steps to encrypt an ODF
package, herein key derivation algorithm, password digest algorithm
and iteration count as well as encryption algorithm.

The manifest contains a number of constructs to hold information like
the cited above. These include

3.7.1 manifest:algorithm-name
3.7.3 manifest:checksum-type
3.7.7 manifest:key-derivation-name

Reading the accompanying RelaxNG-schemas of the attributes above, the
value-space is a generic "string".

Problem:

From my reading of both section 2.4 and the sections in relation to
the manifest, the value-space of the constructs seem to be fixed.

It appears to me that the only valid values for the constructs are:

manifest:algorithm-name="Blowfish CFB"
manifest:check-sum-type="SHA1/1K"
manifest:key-derivation-name="PBKDF2"

So there seems to be a slight contradiction between the prose of the
specification and the value-space of the schemas. Also, the
specification contains this sentence:

The defined value for the manifest:key-derivation-name attribute is:
* PBKDF2: The PBKDF2 key derivation method. See [RFC2898].

I have looked in Part 3 for guidance to this prose (The defined value
...) but have found none. So it is not clear to me if it means that
"PBKDF2" is a "reserved value" of the attribute with a specific
meaning or if the value "PBKDF2" is the only allowed value.

Proposed solution:

Assuming that the value-space is indeed fixed, having constructs in
the schemas that have fixed values could be a cause of confusion to
developers and hence diminish interoperability
between applications. Since the values in the prose seems to be
predefined, the constructs serve no purpose.


* Remove the constructs mentioned above from the schemas or
* clarify in the specification that any algorithm (type) etc is
allowed as values of these constructs.

Other sections in ODF specify requirements that an application SHALL
support a feature (image-formats, as I recall it), and it might be a
good idea to include similar prose here to maximize interoperability.

--
Jesper Lund Stocholm
www.idippedut.dk
SC34/WG4 http://www.itscj.ipsj.or.jp/sc34/wg4/