-
Type: Bug
-
Status: Applied
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: ODF 1.2 CD 05
-
Fix Version/s: ODF 1.2 CD 06
-
Component/s: Packaging, Part 2 (Packages) [1.2: 3], Security
-
Labels:None
-
Environment:
This issue applies to all versions of ODF starting with the OASIS ODF 1.0 Standard. The specific text and repair is for ODF 1.2 Part 3 CD01-rev08 (and its ODF 1.2 CD05 Part 3 approved form).
-
Proposal:
-
Resolution:
The manifest.xml schema provides a full set of encryption parameters on EACH <manifest:file-entry> for a Zip-contained compressed file that is encrypted. These parameters are actually not independent from file to file. In particular, there is only one user-enterable pass phrase that is used for all of the encryptions. Although it remains possible that more than one start-key-generation method and start-key size can be specified, all start-key generations are performed with the same pass phrase for all of the Zip-contained compressed files that are encrypted.
This issue proposes clarification that the same pass phrase is employed for each of the encryptions specified in the package manifest.
This is the rationale:
1. There is no provision in the default encryption process and its implmentations for there to be more than one encryption cycle or different password for different files within the package.
2. All of the encryptions that are performed using the model in ODF 1.2 Part 3 sections 3.4 and the related definitions of manifest elements and attributes are performed at one time using a single pass phrase (a.k.a. plaintext password) and start key. There is no manifest information by which any different default procedure can be employed with regard to the start-key derivation step.
3. We must assume that there is a single start key used for all of the individual encryptions.
(Although section 4.8.6 provides for a variety of recognized message digest algorithms, none of them have parameters and there is no way to indicate that different pass phrases are digested for producing start keys. Although different start-key-generation message-digest algorithms might be specified for different files, it is unclear whether any package consumer is prepared for such an eventuality. In the default case, there does not appear to be room for any variation.)