[OASIS Issue Tracker] Commented: (OFFICE-2562) ODF 1.2 Part 1 CD04:protection-key password format unspecified

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Malte Timmermann commented on OFFICE-2562:
------------------------------------------

I don't agree that there should be any artificial/random maximum password length.
This is my opinion about password restrictions in general - and also applies to minimum length, because a reasonable value today might be unreasonable quite soon.
I also don't see an interop issue here.

> 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