XML Signature WG
XML Signature WG
(Sorry for the teleconference problems to that didn't join.)
Reagle Summary:
[
Provoked email thread because
To rephrase: we are not signing a URL. We are signing the Digested Content, and in an odd sense, the class of documents that yield DigestedContent when transformed in as far as those parts that are kept.
]
Bartel: Since encoding seems to be different from the other Transforms, propose that we move encoding into Target (as part of the hint):
<ObjectReference
URI="http://www.mypage.com"
Encoding="UTF-8">
<Transforms>
...
Call seems happy with this.
[Notetakers Question: Can Encoding still appear in the transform, in both places?]
Reagle: say one has to dereference the URL, decode it, XPath it and C14Nize it., if I have a document on hand that has already been XPath'd but no C14Nized, can I just start it mid process?
Solo: Yes: Signer is only saying he signed the DigestContent. Everything else is a hint. If an application knows it does something, it can pick up the chain where it wants.
Bartel: Agrees: if an application applies some of the transforms, save an intermediary step, and completes the other steps later, that is fine
Reagle: The thing I'm not sure about is says there's a sequence of tricky transforms, could someone play a trick?
Reagle: Is there some sort of assertion by the signer such that "there is a class of documents related to this DigestConent via these transforms?"
Solo: No normative assertion, in the end the you are hashing/signing the DigestContent, and if you don't get the right DigestValue, the signature obviously doesn't work.
Eastlake: David might be too stringent, there is some sort of assertion about those other documents.
Boyer: In the users context, he's looking at the thing that is transformed, where certain parts may change or not, not necessarily the DigestContent min I'm focussing.
Reagle: I think we agree that we don't need to make major change in the syntax, we do need to better define the semantics of the assertions within an ObjectReference. Let's take this to the list, please propose a set of assertions that you think are made by ObjectReference.
Todd: in the legal context, sill concerned about the issue of what the user sees and what is signed (particularly) XSLT's. Call feels that the specification makes these distinctions fairly well. ACTION Todd: propose some text (a sentence or two) that he would like to add to spec, WG can then point out where it exists, or adopt.
Boyer: Orthogonal quick question before the call ends: If you use a IDREF, does it include the element within which the ID sets, or only the element's content. Call: IDREF probably returns the element. Boyer: in Richard Himes' scenario, he only wants the content (because that is what is fed into the Base64 decoder if an encoded document is embedded in XML).
Call: suspect if you want only the content, you will have to use a simple XPath like child::text().
[Note taker question: is the IDREF still listed in the ObjectReference, and then the further qualification is in the transform, or does the IDREF/URI="" and the complete Transform follows?]