Uploaded image for project: 'OASIS Open Document Format for Office Applications (OpenDocument) TC'
  1. OASIS Open Document Format for Office Applications (OpenDocument) TC
  2. OFFICE-3749

ODF 1.2 manifest:checksum-type contradictions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: ODF 1.2
    • Fix Version/s: ODF 1.3
    • 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:
      Hide

      Remove "SHA1" from section 4.8.3 because of the fact that there are inconsistent implementations and no obvious way to reconcile them. This is also correct with respect to the description of permitted values in the shaded block at the end of the section.

      Replace the last text paragraph of section 4.8.3 wiht the following two paragraphs:

      "Package producers should use the SHA1/1K value and method when compatibility with older versions of consumers is important. In other cases, producers that support encryption should use the urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k value and method. [Note: manifest:checksum is used to confirm that a decryption is successful. It should not be regarded as a security feature.]

      "Package consumers that support encryption shall support the values SHA1/1K, urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1-1k and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k."

      Show
      Remove "SHA1" from section 4.8.3 because of the fact that there are inconsistent implementations and no obvious way to reconcile them. This is also correct with respect to the description of permitted values in the shaded block at the end of the section. Replace the last text paragraph of section 4.8.3 wiht the following two paragraphs: "Package producers should use the SHA1/1K value and method when compatibility with older versions of consumers is important. In other cases, producers that support encryption should use the urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k value and method. [Note: manifest:checksum is used to confirm that a decryption is successful. It should not be regarded as a security feature.] "Package consumers that support encryption shall support the values SHA1/1K, urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1-1k and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k."

      Description

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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              orcmid Dennis Hamilton (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: