- From: merlin <merlin@baltimore.ie>
- Date: Thu, 02 May 2002 16:30:45 +0100
- To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
- Cc: Ari Kermaier <arik@phaos.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, reagle@w3.org, xml-encryption@w3.org
Hi, I was labouring under delusions when I got confused about the wrapping of elements, so it seems safe to ignore what I wrote about wrapping. However, my other question remains: >I don't think that it is weird. If we define the processing rules over >node-sets, we replace some nodes in a node-set with ones in the other >node-set. It looks easy, but is not possible because, according to the >XPath spec, a node-set is defined as a set of nodes in a document tree. >That is, it is because the relation between node-sets from distinct >document trees is not defined. So we defined the processing rules over >octet streams. Does this make sense? It makes sense under the assumption that XPath node sets cannot be manipulated in both form and content, but I do not understand why you say the XPath spec states that this is not possible? The XPath spec does indeed state that a node-set is a set of nodes in a document tree. It does not state that I cannot manipulate the set and tree. In fact, given any XPath implementation, I probably can manipulate both of these. Regardless, I think the current model requires at minimum one of the following changes: 1. Stay with the current processing model; that is, for each EncryptedData we serialize, wrap, decrypt, insert, parse. In this case, we need to respecify Except. The URIs "#foo" and "#xpointer(/path/to/enc:EncryptedData)" are same-document references; they will never identify nodes in these new documents. Except would need to be changed to have an ID reference attribute (although not of type IDREF) and we should state that this ID will be used to identify an element of type enc:EncryptedData with matching Id attribute in the node set being processed. 2. Change to a model where we decrypt all non-excepted EncryptedData in the input node set; then serialize, wrap, insert and parse the entire node set in one go. In this case, Except URIs will work because the references will identify EncryptedData elements in the original document. However, multiple levels of encryption will not be decrypted and it should be noted that the output node set will be of a different document than the input node set. Merlin >>but I believe the confusion >>on wrapping is really just an infelicity of the language in the text. When >>it says "wrap the decrypted octet stream" I think it really means "wrap >the >>octet stream resulting from decrypting and replacing e in X". (See >>Takeshi's answer to my question in [1].) >> >>Under this reading, I think the following would hold for a signature over >>"#foo": >> >><Bar xmlns:baz="http://example.org/baz"> >> <Foo xml:something="other" Id="foo"> >> <enc:EncryptedData ...>...</enc:EncryptedData> >> </Foo> >></Bar> >> >>Dereferencing, decrypting and replacing results in: >> >><Foo xml:something="other" Id="foo"> >> <plaintext /> >></Foo> >> >>Since <Bar>'s namespace is in scope for the first element of the input >>node-set, <Foo>, parsing context C is {xmlns:baz="http://example.org/baz", >>xml:something="other"}. > >Sorry for confusing you. The text defining the parsing context should be >tweaked. In this case, C is {xmlns:baz="http://example.org/baz"}. Please >consider the meaning of the word "parsing context". > >>So the result of wrapping would be: >> >><dummy xmlns:baz="http://example.org/baz" xml:something="other"><Foo >>xml:something="other" Id="foo"> >><plaintext /> >></Foo></dummy> > >The result would be: > ><dummy xmlns:baz="http://example.org/baz"><Foo xml:something="other" Id >="foo"> > <plaintext /> ></Foo></dummy> > >>Parsing, unwrapping and canonicalizing would result in: >> >><Foo xmlns:baz="http://example.org/baz" xml:something="other" Id="foo"> >> <plaintext /> >></Foo> >> >>If this is correct, my proposed text in [2] for decryptXML(X, e, C) and >>decryptOctets(X, e) would be OK. Am I missing anything? > >Thanks, >Takeshi IMAMURA >Tokyo Research Laboratory >IBM Research >imamu@jp.ibm.com > > ----------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com
Received on Thursday, 2 May 2002 11:30:58 UTC