[OASIS Issue Tracker] Issue Comment Edited: (OFFICE-2656) Clarifywhen signatures operate on encrypted and when on unencrypted files.

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

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19016#action_19016 ] 

Dennis Hamilton edited comment on OFFICE-2656 at 4/30/10 6:12 PM:
------------------------------------------------------------------

To clarify why this "correction" fails.

I have uploaded an extract of a META-INF/documentsignature.xml file that was produced for a signed document of mine.  I assume the file is meant to be conformant in accord with the provisions of ODF 1.2 Part 3 CD01 at least.  (It is from OpenOffice.org 3.2.0.)  I have not bothered to go back and look at how OpenOffice 2.4 does digital signatures in its private implementation.  

The extract is at <http://www.oasis-open.org/committees/document.php?document_id=37563>.

 1. This demonstrates, as well as I can tell, that the derivation of signature digests are always on the extracted data streams, not on the compressed data unit encoded in the Zip package.  I base that on the simple argument that the exhibited signature file signs itself and also references to fragments of itself, not something that can be done using the compressed form as the target.  Likewise, all use of URIs in accordance with section 2.7 are of this nature.

 2. As an incidental matter, this extract also demonstrates a bug that is a consequence of the use of the package base IRI as the file-entry base IRI for relative references.  When the URI is a simple fragment (that is, there is a 0-length relative-part), such as "#fragment-id" this resolves, according to sections 2.7 and 4.3, to a package file whose name is "" (that is, empty).  The correct way to make such relative references to fragments of the signature file itself is using references such as

   URL="META-INF/documentsignature.xml#fragment-id".

      was (Author: orcmid):
    To clarify why this "correction" fails.

I have uploaded an extract of a META-INF/documentsignature.xml file that was produced for a signed document of mine.  I assume the file is meant to be conformant in accord with the provisions of ODF 1.2 Part 3 CD01 at least.  (It is from OpenOffice.org 3.2.0.)  I have not bothered to go back and look at how OpenOffice 2.4 does digital signatures in its private implementation.

 1. This demonstrates, as well as I can tell, that the derivation of signature digests are always on the extracted data streams, not on the compressed data unit encoded in the Zip package.  I base that on the simple argument that the exhibited signature file signs itself and also references to fragments of itself, not something that can be done using the compressed form as the target.  Likewise, all use of URIs in accordance with section 2.7 are of this nature.

 2. As an incidental matter, this extract also demonstrates a bug that is a consequence of the use of the package base IRI as the file-entry base IRI for relative references.  When the URI is a simple fragment (that is, there is a 0-length relative-part), such as "#fragment-id" this resolves, according to sections 2.7 and 4.3, to a package file whose name is "" (that is, empty).  The correct way to make such relative references to fragments of the signature file itself is using references such as

   URL="META-INF/documentsignature.xml#fragment-id".
  
> Clarify when signatures operate on encrypted and when on unencrypted files.
> ---------------------------------------------------------------------------
>
>                 Key: OFFICE-2656
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2656
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>            Reporter: Michael Brauer
>            Assignee: Michael Brauer
>
> The ODF 1.2 part 3 CD01 specification currently does not explicitly state how references to encrypted files are handled.
> There are two uses cases:
> a) A signature is applied to an encrypted document. In this case, the signature would operate on the encrypted files.
> b) A signed document is encrypted. In this case, the signature would operate on the unencrypted files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira