Re: Decryption Transform processing question

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