Details

    • Type: Bug
    • Status: Applied
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: ODF 1.2 Part 1 CD 4
    • Fix Version/s: ODF 1.2 Part 1 CD 5
    • Labels:
      None
    • Environment:

      This issue applies to all forms of ODF 1.2 Part 1 CD04 and to previous version of ODF 1.2 working documents. It does not apply to ODF 1.0 and ODF 1.1.

    • Proposal:
      Hide

      In the ODF 1.2 Part 1 schema for attributes table:protection-key-digest-algorithm and text:protection-key-digest-algorith, specify the exact values that are permitted as constraints on the anyURI type:

      http://www.w3.org/2000/09/xmldsig#sha1
      http://www.w3.org/2000/09/xmldsig#sha256

      In the text for each of section 19.700 table:protection-key-digest-algorithm and section 19.853 text:protection-key-digest-algorithm, replace all of the first paragraph after the first sentence with the following text:

      """
      It takes the values that identify SHA1 and SHA256 in §5.7 of [xmlenc-core]. Consumers shall support both SHA1, the default, and SHA256.
      """

      Show
      In the ODF 1.2 Part 1 schema for attributes table:protection-key-digest-algorithm and text:protection-key-digest-algorith, specify the exact values that are permitted as constraints on the anyURI type: http://www.w3.org/2000/09/xmldsig#sha1 http://www.w3.org/2000/09/xmldsig#sha256 In the text for each of section 19.700 table:protection-key-digest-algorithm and section 19.853 text:protection-key-digest-algorithm, replace all of the first paragraph after the first sentence with the following text: """ It takes the values that identify SHA1 and SHA256 in §5.7 of [xmlenc-core] . Consumers shall support both SHA1, the default, and SHA256. """
    • Resolution:
      Hide

      No action

      Show
      No action

      Description

      The introduction of table:protection-key-digest-algorithm (19.700) and text:protection-key-digest-algorithm (19.852) opens up the prospect of additional algorithms beside the default SHA1. In fact, SHA256 must be supported by consumers and should be used by producers. The current text also permits SHA512 and RIPEMD-160 by reference to [xmlenc-core]. Additonal algorithms, identified by other URIs, are also allowed.

      This is wasted effort. The digest algorithm does not protect the protection, it only protects the key. Furrthermore, having the hash of the key exposed and available, as it is in the table:protection-key and text:protection-key entries makes it easy to discover the key by well-known password attacks. The only safe key to use in setting protection is one that is worthless for any other purpose and for which its discovery is no loss. In general, hashes should not be used to protect secrets where the hash itself is readily obtained and where the secret is of any serious value. The prospect of possible collisions that have the same hash is in fact uninteresting for this use case.

      By requiring support for stronger digest algorithms in the specification, there is also an unnecessary burden on implementers, conformance assurance efforts, and just plain code bloat for no useful value.

      My preference is that these attributes be removed from the ODF 1.2 specification altogether and that the requirement to use SHA1 be stated as part of the specification for table:protection-key and text:protection-key. That's already more than enough. (XOR folding would probably be sufficient but it is too late for that.).

      Acknowledging that the SHA256 recommendation is likely established in implementations, I propose that only SHA1 and SHA256 be permitted, there be no requirement on producers other than they use one, and no other digest algorithms be allowed or expected.

        Attachments

          Activity

            People

            • Assignee:
              michael.brauer Michael Brauer (Inactive)
              Reporter:
              orcmid Dennis Hamilton (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: