OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (OFFICE-2724) ODF 1.2 Part 3 3.4.1and 3.4.2(1) One Password and Start Key, Many Encryption Keys



     [ http://tools.oasis-open.org/issues/browse/OFFICE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Hamilton updated OFFICE-2724:
------------------------------------

       Proposal: 
1a. In the first bullet-item in the list of section 3.4.1 change the text

"The start key is generated."

to
"A single password is used for all of the individual-file encryptions.  All start key values are generated from that single password.  Note: Start keys generated by the same start-key-generation method will be the same; the same start key is used everywhere that the default algorithms are used (3.4.2).."

1b. If that is too strong, in Section 3.4.2 item (1) replace this initial text

"The start key is generated: ... ."

with

"A single start key is generated and used for all of the keys that will be derived: ... ."

2. Either way, in section 3.4.2 item 2, replace

"The derived key is generated from the start key: ... ."

with

"For each file to be encrypted, a separate derived key is generated from the start key: ... ."

  was:
1a. In the first bullet-item in the list of section 3.4.1 change the text

"The start key is generated."

to
"A start key is generated from the single password that is provided.  Note: Start keys generated by the same start-key-generation method of one or more encrypted files will be the same; only one start key is created from the password when the default algorithms are used (3.4.2).."

1b. If that is too strong, in Section 3.4.2 item (1) replace this initial text

"The start key is generated: ... ."

with

"A single start key is generated and used for all of the keys that will be derived: ... ."

2. Either way, in section 3.4.2 item 2, replace

"The derived key is generated from the start key: ... ."

with

"For each file to be encrypted, a separate derived key is generated from the start key: ... ."

    Description: 
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.)

  was:
 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 some 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.)


Thanks, David.  I see that I didn't make the issue clear.  I have edited the description and refined the proposal somewhat to be more clear.

The proposed resolution in this issue is to affirm that there is only one Pass Phrase and it is the basis for all of the start-key-generation and key generation stages for every one of the individual file encryptions done within the Zip package.

The problem behind this issue is that instead of establishing some of these parameters globally (once per manifest.xml) rather than separately for each manifest.xml <manifest:file-entry> element, the manifest.xml schema suggests that more variation is permitted than makes any practical sense whatsoever and certainly has no use case in practice.  However, the accompanying text in section 3.4.1 and/or 3.4.2 fails to specify that there are any constraints on variability among the per-file-specified encryption elements and attributes and the pass phrase that is started from..


> ODF 1.2 Part 3 3.4.1 and 3.4.2(1) One Password and Start Key, Many Encryption Keys
> ----------------------------------------------------------------------------------
>
>                 Key: OFFICE-2724
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2724
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging, Security
>    Affects Versions: ODF 1.2 Part 3 CD 1
>         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).
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2 Part 3 CD 2
>
>
> 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.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]