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] (OFFICE-3998) CLONE - ODF 1.2 manifest:checksum-type contradictions


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

Patrick Durusau updated OFFICE-3998:
------------------------------------
    Fix Version/s:     (was: ODF 1.3)

> CLONE - ODF 1.2 manifest:checksum-type contradictions
> -----------------------------------------------------
>
>                 Key: OFFICE-3998
>                 URL: https://issues.oasis-open.org/browse/OFFICE-3998
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Part 3 (Packages), Security
>    Affects Versions: ODF 1.2
>         Environment: This defect occurs in OpenDocument-v1.2-os-manfest-schema.rng and OpenDocument-v1.2-os-part3.odt (.pdf, .html)
>            Reporter: Dennis Hamilton
>            Priority: Major
>             Fix For: ODF 1.2 Errata 01
>
>
> In ODF 1.2 Part 3 section 4.8.3 it is stated that defined values for the manifest:checksum-type are
>  SHA1
>  SHA1/1K
>  and a variety of URN and URI values other than those.
> In the OpenDocument-v1.2-os-manifest-schema.rng, the only value permitted other then anyURI is SHA1/1K.  SHA1 is omitted from the value choices.
> In ODF 1.1 and earlier, the *only* supported value is stated to be SHA1 and no URN and URI values are allowed.  It is evidently the case that some common implementations of encryption for ODF 1.1 documents actually used what is identified as "SHA1/1K" for ODF 1.2.
> So the current schema provision for manifest:checksum-type is neither downward compatible nor are conformant ODF 1.1 implementations upward compatible.
> In addition, ODF 1.2 Part 3 section 4.8.3 is worded in a manner that gives preference to a single URN for producers and requires support for only SHA1/1K and a couple of URN values for consumers.<strike>, even though 4.8.3 defines SHA1 and SHA1/1K to be equivalent</strike>.
> [Note: A consumer that is designed to accept older versions of encrypted documents can treat manfiest:checksum-type="SHA1" as either SHA1 or SHA1/1K by checking to see if there is a match in 1K and, if not, checking for a match on the full decrypted stream.  ODF producers that intend for their encrypted documents to be acceptable down-level have no means to determine how SHA1 will be understood and whether SHA1/1K will be recognized.  The safest course is to use "SHA1/1K", even when producing documents identified as being ODF 1.0/1.1 compatible.  This will evidently disrupt the fewest older implementations.]



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)


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