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-2562) ODF 1.2 Part 1 CD04:protection-key password format unspecified



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

Dennis Hamilton commented on OFFICE-2562:
-----------------------------------------

The limitation is not artificial.  It is the maximum message that the SHA1 method can digest.

Since users dare not use valuable passwords, I don't think there is any harm in truncation at a more-reasonable smaller size than 2^61-1 octets (2305843009213693951 bytes).

Furthermore, if the character set encoding and any restrictions on character use are not precisely defined, it is possible for someone to use a password with one implementation and platform that can't be used successfully with a different implementation and/or platform (and locale, for that matter).  That is the interoperability issue.  Unless we believe that unlocking will only be done on the same cofiguration which was used to set the lock.  I would be happy to learn that is the only use case that we support.  

If the use case is that there is no interoperability issue with the character-set and encoding of the password that is delivered to the digest algorithm being implementation-dependent, we should say so.

> ODF 1.2 Part 1 CD04: protection-key password format unspecified
> ---------------------------------------------------------------
>
>                 Key: OFFICE-2562
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2562
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Security, Table, Text
>    Affects Versions: ODF 1.2 Part 1 CD 4 
>         Environment: This issue applies to all versions of ODF 1.2 Part 1 CD04, earlier drafts, and to ODF 1.1 and ODF 1.0
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2
>
>
> The table:protection-key (19.699) and text:protection-key (19.852) attributes carry the results of hashing of sequences of binary bits supplied to a digest algorithm.  The input is internal computer data.
> For ODF 1.2 Part 1 protection-key attributes, it is not specified how those binary bits are obtained nor how a consumer of a document holding such keys is expected to obtain the same binary bits and confirm their submission by arriving at the same hash-code result.
> This proposal establishes that UTF-8 encoding in binary octets shall be used.
> This proposal establishes that the permissible Unicode characters shall be the same ones permitted for encoding of XML document in Unicode.
> Finally, truncation or limitation of the string differently by the consumer than is applied by the producer requires that there be some agreement on where truncation shall occur.  The value of 2^61-1 octets is chosen because that is the limitation on the input for SHA1.    It would be wise to find a more-practical though generous limitation.  This proposal makes no recommendation.

-- 
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]