[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2656) NEEDS-DISCUSSION:Clarify when signatures operate on encrypted and when on unencrypted files.
[ http://tools.oasis-open.org/issues/browse/OFFICE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19097#action_19097 ]
Dennis Hamilton commented on OFFICE-2656:
-----------------------------------------
Michael,
"Regarding #2: I fail to see how the resolution of a "#fragment" URI results in an empty URI. Can you explain which steps lead to that result?"
I applied the rules in OpenDocument-v1.2-part 3-cd1-rev02-editor-revision.odt sections 2.7 as modfied by section 4.3. SHORTCUT HINT: Look at the example for "#s" in [RFC3986] section 5.4.1.
Here it is step by step.
1. The signature being processed is in file META-INF/documentsignature.xml (that is it's full-path or what is sometimes called its file-entry-path in Part 3).
2. The IRI is the value of <ds:Reference> URL attribute or <ds:SignatureProperty> Target attribute. Provisions of section 2.7 and 4.3 apply because these attribute values are of XML Schema datatype anyURI.
3. The IRI is "#a-fragment-here" and there is an element in the <ds:Signature> element that has an Id="a-fragment-here".
4. We don't know what the package base IRI is, because it is not clear what rule in [RFC3986] section 5.1 applies. However, it doesn't matter because we will remove it later anyhow. So assume the package base IRI is simply some "package-base-IRI" (where the actual form is a legitimate absolute IRI, we just don't how what it is in this exercise).
5. Section 4.3 instructs us to use the package base IRI instead of the file entry base IRI. So treating that as if it is the file entry base IRI, we come back to section 2.7 and continue in [RFC2986] with the package base IRI as base URI.
6. The base IRI is "package-base-IRI" and the relative IRI reference is "#a-fragment-here".
7. The rule for relative-ref defined in [RFC3986] 4.2 is satisfied. The reference "#a-fragment-here" satisfies the rule with these pattern cases:
relative-ref = relative-part "#" fragement
where
relative-part = path-empty
and the rule and the constraints are satisfied.
8. NOTE: See 13 below. [RFC3986] 4.4 is not invoked in the ODF 1.2 Part 3 section 2.7 provisions. Maybe it is intended, but this is not accounted for in section 2.7. It's also not time yet (see 15 below). The effect of 4.4 normally happens automatically as expected under section 2.7 whenever the base IRI is the file entry base IRI. That is not the case with the base IRI we are using. Also, section [RFC3986] 5.1 gives an exception to establishing a base URI and it would seem that, under 4.4, we're done, except we have been told there is a base URI by 2.7 and 4.3. Based on what follows, it appears that 4.4 is about avoiding refetching of whatever the base resource is. It is not about short-circuiting the section 5 processes in [RFC3986]. (Another way to put this is that if you have a document and it has no base URI, then the only kind of relative-ref it can use is a fragment reference. That does not mean that a relative-ref that is only a fragment reference is always to the current document despite what the base URI is.)
9. In applying section 5.2, we have to assume that whatever an actual "package-base-IRI" might be, all of the adjustments in 5.2.1 can be carried out.
10. In 5.2.2, "#a-fragment-here" is parsed into an empty scheme, an empty authority, an empty path, an empty query, plus the actual fragment.
11. Because the path is empty, T.path is the Base.path. T.query is Base.query, T.authority is Base.authority, and T.scheme is Base.scheme. There is no Merge Paths (section 5.2.3) nor Remove Dot Segments (5.2.4).
12. If we put it all back together as in [RVC3986] 5.3, we get "package-base-IRI#a-fragment-here".
13. *** BIG NOTE ***: This is consistent with the example in 5.4.1 that expands "#s" to "http://a/b/c/d;p?q#s"; given Base URI "http://a/b/c/d;p?q";
14. OK, coming back from [RFC3986] to ODF 1.2 Part 3, we see that all of the conditions for this being a package file entry reference are satisfied.
15. The package base IRI si removed from the "absolute" IRI, ""package-base-IRI#a-fragment-here". The result is, of course, "#a-fragment-here". ** ANOTHER BIG NOTE ** If something were to be done with [RFC3986] 4.4, this would appear to be the place it would apply. However, the assumption is still that the "same document" in that sense is whatever the package-base-IRI resolves to, and I think that is no help here.
16. We don't have to remove any leading "/" unless one was somehow left-over from the creation of the absolute URI.
17. We remove the fragment identifier. That leaves "".
18. We now have to find that file in the package. Good luck.
> NEEDS-DISCUSSION: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]