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=18749#action_18749 ] 

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

The problem is that a producer that supports this must have a way to accept a password and submit it to the digest procedure.  For a consumer to be able to unlock the protection it must know how to form the very same input to the message digest procedure.  Saying that it is in UTF-8 is not enough.  There needs some way for pruducers and consumers to have an agreement on what the input method is such that the password entered at the producer and at the consumer results in the same UTF-8 and hence the same hashed copy.  The XML limitation is an useful one (since it applies to UTF-8) as is saying something about elimination or collapsing of white space.

It is pretty demanding to require that a consumer allow entering of all of those codes as part of a password entry and that producers effectively do the same.

If you think "The password shall be provided as a sequence of byes in UTF-8 encoding" is a sufficient condition on what a consumer must support entry of, then I accept that.  I just want to be sure the implications are understood.  OK?

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