[OASIS Issue Tracker] (OFFICE-3869) PAS Comment JP5: Clarify relationship between digital signature and encryption

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OFFICE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50543#comment-50543 ] 

Chris Rae commented on OFFICE-3869:
-----------------------------------

Here's also Dennis' reply to my query to him regarding further investigating this [posted here with his permission].

--
OK, here's what is unclear to Miyachi-san.  I'll start with the answer.  Why these have to be the answer is more complicated, and we need to check whether ODF 1.2 Part 3 makes this answer necessary or whether more needs to be said in the specification.

Four cases:

 1. When a document is signed via META-INF/documentsignatures.xml, Every part of the XML file is signed (has a verifiable digest) based on its Zip-uncompressed data stream.  XML Canonicalization applies for the XML parts.  (It will be interesting to check what is done with RDF/XML parts.)  There can be other META-INF/*signatures*.xml parts and I believe they are also signed by documentsignatures.xml although that needs to be tested.  Other Transforms beside XML Canonicalization and the Identity one for text and blobs are possible.

 2. When an unsigned document is encrypted, everything in the document is encrypted except for the mimetype file, the thumbnail file (which is generally replaced by something that does not leak content), and the META-INF/manifest.xml file.  Every part that is encrypted is compressed, whether that is optimum or not, and it is the compressed form that is encrypted and stored in the Zip as if it is not compressed but with no change to the name, media-type information in the manifest, etc.  Since the Zip has compressed and uncompressed length the same in this case, the true uncompressed length is stashed in the manifest.xml file-entry information along with other encryption/decryption parameters..

 3. When an encrypted document having no encrypted META-INF/documentsignatures.xml file is signed, creation/counter-signing of META-INF/documentsignatures.xml uses the digest of the encrypted block for each part of the Zip that is encrypted.  Unencrypted parts have their digest computed on their uncompressed form. (I.e., manifest.xml's XML Canonicalization is digested.)

 4. When an encrypted document has an encrypted META-INF/documentsignatures.xml file, it cannot be counter-signed and the digests are for the unencrypted, uncompressed forms of all of the files in the package.  That is, for META-INF/documentsignatures.xml to be encrypted, it must have been created the same as it is for any unencrypted document (case 1 above), except for the fact that the META-INF/manifest.xml has to be as if encryption has already taken place.  There is no new information disclosure beyond those already in case (2).

THE JAPANESE CONFUSION. It is not clear to Miyachi-san that an unencrypted digital signature of an encrypted document must be a signature of the encrypted forms of package parts, not of the unencrypted forms.  If it were otherwise (1) that would be a serious information disclosure, (2) it would be impossible to counter-sign and (3) there would be no way to sign an already-encrypted document after it was created.  Without getting into the reasons, *I* think that is already clear in ODF 1.2 Part 3, but that could be because I am too close to it.  I must go check to see where the I's and T's are crossed and dotted.

[I checked.  This language is definitely clumsy (ODF 1.2 Part 3 section 5.2, last two paragraphs):

	"If a digital signature file is not encrypted, consumers shall not decrypt files that are referenced by <ds:Reference> elements and that are encrypted before validating the signature.

	"If a digital signature file is encrypted, consumers shall decrypt files that are referenced by <ds:Reference> elements and that are encrypted before validating the signature."

I can imagine all sort of hazards in the translation of this to Japanese.]

> PAS Comment JP5:  Clarify relationship between digital signature and encryption
> -------------------------------------------------------------------------------
>
>                 Key: OFFICE-3869
>                 URL: https://issues.oasis-open.org/browse/OFFICE-3869
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Task
>          Components: Part 3 (Packages)
>    Affects Versions: ODF 1.2
>            Reporter: Chris Rae
>            Assignee: Chris Rae
>
> Comment logged by national body during the ODF 1.2 PAS process, to be address at Ballot Resolution Meeting.
> Nature of defect :Technical
> Original text of NB comment: Relations between the digital signature and encryption are not clear. Specify the relations.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)