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: RE: [office] [OASIS Issue Tracker] Commented: (OFFICE-2687) ODF 1.2Part 3: Unspecified Signature-File Name Allocation


It is a matter of being able to efficiently interoperate. If one implementation puts document signatures in foosigantures.xml and the other puts it in barsignatures.xml, and a third puts it in bazsignatures.xml, then we all end up with code looking for each file name. If we all agree to put document signatures into documentsignatures.xml, then all of us have simpler code.

The alternative is for an implementation to open *signatures* and then try to guess at the purpose of each signature, when we have not defined a way to designate purpose.

I also place a high value on not breaking an existing implementation, and a lot of value in my code interoperating nicely with the existing implementation, should Microsoft decide to implement signatures for ODF.

-----Original Message-----
From: OASIS Issues Tracker [mailto:workgroup_mailer@lists.oasis-open.org] 
Sent: Wednesday, October 20, 2010 3:55 AM
To: office@lists.oasis-open.org
Subject: [office] [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=22355#action_22355 ] 

Michael Brauer commented on OFFICE-2687:
----------------------------------------

I agree that document signatures should be reserved for that purpose, but believe that this is the case already, unless we adopt the changes proposed in OFFICE-3028.

I fail to see what the remainder of this issue is about. We essentially say that all files that match the *signatures* pattern should be valid XSD signature files. This allows consumers to read these files, to analyze them, and to decides based on what is signed to display to the user what is signed. Is the issue that different producers could us the same file name to provide different kind of signatures. Well, theoretically that may happen, but the worst case is that one application overwrites the signature of another one. Using file names that contain the application or vendor names (that is what I think is proposed) would be wrong solution to this, because the idea is that signatures can be analyzed by application because thay are XSD signatures. It is not intended that application analyze only the signatures they have produced. If that would be case, then we wouldn't even have to mention that there could be other signatures than document signatures.

> 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.
> 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.

--
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

        

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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