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] Commented: (OFFICE-2354) support sha256 inpart 1 vs part 3

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17577#action_17577 ] 

Dennis Hamilton commented on OFFICE-2354:

Well, the usages in Part 3 are important for cryptographic security purposes in one case and for helping a consumer know whether the decryption worked in the other (more dangerous SHA1/1K) case.

For Part 1, the strength of the hashing or other device for obscuring a table protection key does not protect the protection, which is trivial to over-ride. So it only protects the key and if the key is valuable it should not be used for this minor purpose.

If one is concerned about preventing casual users from removing the protection on table cells, while still being able to entering some of the table cells, keep an unprotected copy and only circulate one that is protected with a randomly-produced key that need not be remembered and has no value whatsoever.  Even better, randomly generate the "hashed"-value bits, skipping creation of a plaintext password altogether.

Having said all of that, I also agree that some consistency in reference to digest algorithms and their setup and their identification in the values of attributes would be nice.

> support sha256 in part 1 vs part 3
> ----------------------------------
>                 Key: OFFICE-2354
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2354
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Improvement
>          Components: Security
>    Affects Versions: ODF 1.2 Part 3 CD 1
>            Reporter: Bart Hanssens
>            Priority: Minor
> Part 3, 3.8.3 manifest:checksum-type says 
> "Package consumers that support encryption shall support the values SHA1/1K and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1"
> "Package producers that support encryption shall support the value SHA1/1K"
> Part 3, 3.8.6 manifest:start-key-generation-name states 
> "Package consumers that support encryption shall support the values SHA1 and http://www.w3.org/2000/09/xmldsig#sha1";
> "Package producers that support encryption shall support the value SHA1"
> On the other hand, Part 1, 19.700 table:protection-key-digest-algorithm states 
> "Consumers shall support SHA1, which is the default, and SHA256"
> "Producers should use SHA256"
> While I do realize that part 3 may be used outside the scope of ODF, it seems a bit odd that the spec as a whole more or less promotes SHA256 for a table protection key, SHA1 for start key generation and SHA1/1K for checksum-type (2-3 different algorithms for basically the same thing)

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]