Re: Decryption Transform processing question

r/reagle@w3.org/2002.05.30/12:13:44
>1. In the present WD, we say we support the xmldsig profile XPtr (which is  
>same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))'. Anything 
>else is optional. You seem to be using more sophisticate pointers, are you 
>advocating a change in this level of support? (BTW: I think I've heard that 
>folks are reviving the XPtr work by breaking it into different 
>profiles/specs.) I'd prefer to keep this real simple and rely upon IDs.

"All other support for XPointers is OPTIONAL", and I'd keep it
that way. However, we have customers who require more sophisticated
XPointer support and there is no reason the spec should disallow
them. We also already have language in the spec about use of here()
in XPointers, which implies optional support of full XPointers.

>2. In decryptIncludedNodes() why did you switch the order of steps 2 and 3? 
>(Makes it difficult to see the diffs, but maybe you had a reason.)

The language simply happened to flow in that direction.

>3. In decryptXML, if I have three elements I'm decrypted, via process one 
>do they all go into one octet stream, or is a group of 3 octets sets?

<Foo>
  <EncryptedData <Bar /> />
  <EncryptedData <Baz /> />
</Foo>

Both EncryptedData are decrypted; then one octet stream
is produced, consisting of the concatentation of:

'<?xml version="1.0">
<dummy>'

'<Foo>
  '

'<Bar />'

'
  '

'<Baz />'

'
</Foo>'

'</dummy>'

Or, explicitly:

'<?xml version="1.0">
<dummy><Foo>
  <Bar />
  <Baz />
</Foo></dummy>'

This octet stream is formed by serializing X, but whenever you
hit a decrypted EncryptedData element, instead emit the plaintext.
Then wrap this.

This octet stream is then parsed, trimmed and the result is a
single node set, created from a single phase decrypt*, serialize,
wrap, parse, trim.

Merlin

Received on Thursday, 30 May 2002 12:37:26 UTC