OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (OFFICE-2687) ODF 1.2 Part 3:Unspecified Signature-File Name Allocation

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

David LeBlanc commented on OFFICE-2687:

I think we need to define precisely what is meant by "full-package signature". The correct way to create a signature which covers every element of the package is to do it external to the package. You can then ensure that not only every aspect of the included files are covered, but even metadata which may exist inside the container for all the files. In addition, there's no standard way to capture such aspects of internal files, such as attributes, and we run into problems with things like empty directories.

We cannot create an external full package signature as a part of this standard until we can define how to create a conforming container. We need to do this when we fix the encryption problem, and I'd suggest that we deal with signing the contained archive in the same set of changes, as one may wish to do encryption and/or signing.

An internally stored signature that attempts to emulate an external signature runs into several problems - the first is that it will prevent any other signatures from being modified, and this breaks the intent of XAdES. There's also a problem where it needs to sign the file that contains itself, which introduces dangerous transforms into the mix.

The next step down from a "full package signature" would be to sign all of the files, excepting the documentsignatures.xml itself. This would be a useful interim definition, but we need to remember that this strict a definition precludes the addition of metadata which may be used by data stores, such as search information. It will preclude some functionality which is present in other document formats. This issue could be mitigated by providing a standard place to store such metadata, and allowing that storage not to be signed.

A next step past this is to define what portions of the archive affect the content or appearance of the document, in support of the What You See Is What You Sign principle. While I think this is a great ideal, I also think that practically we don't have time to define this - it is a complex topic.

In addition, while I prefer XmlDSig, I think that we should be careful to only define the signature format for those signature types that we have already defined. So we should say that signatures contained within documentsignatures.xml must be XmlDSig with optional XAdES extensions, but not specify what format should be used for as yet undefined signature types.

> ODF 1.2 Part 3: Unspecified Signature-File Name Allocation
> ----------------------------------------------------------
>                 Key: OFFICE-2687
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2687
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging, Part 1 (Schema), Part 3 (Packages), Security
>    Affects Versions: ODF 1.2 CD 05
>         Environment: This issue applies to ODF 1.2 Part 3 CD01 and its revisions.  The text discussed is as in OpenDocument-v1.2-part3-cd1-rev04.odt
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
> Part 3 Section 2.5 establishes Digital Signatures as stored in one or more files whose "relative pahs" begin with 'META-INF/' and that contain the "term" 'signatures'.   I take this to read that digital signature files SHALL have names of the form 'META-INF/*signature*' in the Zip archive, using conventional wild-card notation.  The format of these files is established in Section 4.
> Part 3 Section 4 says nothing about the naming of the file, although it refers to <dsig-document-signatures> as a root element and it asserts that the schema for the file is that given in Appendix A.  There are no explicit producer conformance requirements.  The only strong requirements on consumers concern differences in signature verification depending on whether or not a digital signature file is encrypted or not (in section 4.2).
> Part 3 Section 7.2.1 on Conforming OpenDocument Packages asserts in (PD1.4-PD1.6) that the only permitted files beside  META-INF/manifest.xml with META-INF/* name structure are those which have name structure META-INF/*signatures* and which are XML 1.0 documents with root element <dsig:document-signatures>, along with a few additional conditions.  (Note that occurrence in /META-INF/manifest.xml is not required, so such files do not have explicit MIME types nor are they subject to encryption when not listed in META-INF/manifest.xml.)
> Part 3 Section 7.2.2 on Conforming OpenDocument Extended Packages does not have any limitation on what can have a META-INF/* form name.
> There is no stipulation that production of META-INF/* and META-INF/*signature* files be implementation defined.  There is no stipulation that consumer-permissive limitations on what is accepted as a valid digital signature are implementation defined.
> The point of the preceding review is to confirm that there is no provision for how META-INF/*signature* name forms are allocated nor whether and how "implementation-defined" appropriation of such a name for a particular purpose is accomplished.   There is similarly no basis for an implementation determining whether the occurrence of such a named Zip archive file is one for which the implementation has been designed.
> There is no provision similar to those in other places where ODF 1.2 provides for explicit identification of implementation-defined provisions via namespace bindings.  
> At the same time, all occurrences of META-INF/*signature* name forms for XML 1.0 documents having <dsig:digital-signatures> root elements and satisfying a few other conditions are permitted as part of Conforming OpenDocument Packages. 
> Likewise, consumers may restrict what is permissible in a digital signature without any requirement that this be implementation-defined and with no provision considering how consumers apply restrictions on what digital signatures there are and which ones are subject to what constraints. 
> An interoperable arrangement is required.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]