-
Type: Bug
-
Status: New
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: ODF 1.2
-
Fix Version/s: ODF 1.2 Errata 01
-
Component/s: Part 2 (Packages) [1.2: 3], Security
-
Labels:None
-
Environment:
This defect occurs in OpenDocument-v1.2-os-manfest-schema.rng and OpenDocument-v1.2-os-part3.odt (.pdf, .html)
-
Proposal:
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.]