Source: https://issues.oasis-open.org/browse/OFFICE-2687
Timestamp: 2020-08-14 14:44:15
Document Index: 534958589

Matched Legal Cases: ['art 3', 'art 3', 'art 1', 'art 3', 'art 3', 'art3', 'art 3', 'art 1', 'art 3', 'art 1', 'art 3', 'art 3', 'art 3', 'art 3']

[OFFICE-2687] ODF 1.2 Part 3: Unspecified Signature-File Name Allocation - OASIS Technical Committees Issue Tracker
OFFICE-2687
ODF 1.2 Part 3: Unspecified Signature-File Name Allocation
Component/s: Packaging, Part 1 (Schema), Part 3 (Packages), Security
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
1. If META-INF/documentsignatures.xml is intended to always mean full-package signature, reserve it for that purpose in Part 3 and be specific about what it signs. ODF 1.2 Part 1 can then required this signature when there are any signatures in a package.
2. Define the name pattern 'META-INF/tld.host.s3. ... . sn/*' to identify an implementation-defined file for which the authoritative definition is associated with the namespace URI "http://host.tld/s3/.../sn". Such files are defined to be authorittaively-named and the authorittaive definitiion determines further provisions on name structure, file format, and limitations on use and conformance provisions where the files are usable.
3. An authoritatively-named digital signature file is any one where the name pattern '/META-INF/signatures' is also satisfied and the file conforms to those requirements along with those of the authoritative definition.
4. For Conforming OpenDocument Packages, all of the allowed signature files should be authoritatively-named, where /META-INF/document-signatures.xml is included. (It might be taken as having an implicit namespace URL that is under OASIS.)
5. For Conforming OpenDocument Extended Packages, I would require the use of authoritative names there as well, since it is difficult to allow some unknown style to be intermixed unless there is never any confusion with authoritative names.
1. If META-INF/documentsignatures.xml is intended to always mean full-package signature, reserve it for that purpose in Part 3 and be specific about what it signs. ODF 1.2 Part 1 can then required this signature when there are any signatures in a package. 2. Define the name pattern 'META-INF/tld.host.s3. ... . sn/*' to identify an implementation-defined file for which the authoritative definition is associated with the namespace URI "http://host.tld/s3/.../sn". Such files are defined to be authorittaively-named and the authorittaive definitiion determines further provisions on name structure, file format, and limitations on use and conformance provisions where the files are usable. 3. An authoritatively-named digital signature file is any one where the name pattern '/META-INF/ signatures ' is also satisfied and the file conforms to those requirements along with those of the authoritative definition. 4. For Conforming OpenDocument Packages, all of the allowed signature files should be authoritatively-named, where /META-INF/document-signatures.xml is included. (It might be taken as having an implicit namespace URL that is under OASIS.) 5. For Conforming OpenDocument Extended Packages, I would require the use of authoritative names there as well, since it is difficult to allow some unknown style to be intermixed unless there is never any confusion with authoritative names.
Since there is only META-INF/documentsignatures.xml currently defined with the rest proposed to be implementation-defined/-dependent, this issue will need more experience to thrash out. Deferred to ODF-Next.
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.
ALLOCATION OF META-INF/signatures NAMES
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.
15/May/10 5:36 PM
03/Nov/10 12:55 AM