Re: Decryption Transform processing question

r/reagle@w3.org/2002.05.29/17:02:36
>On Wednesday 29 May 2002 04:06 pm, merlin wrote:
>> Right, but if you are constructing an XPointer then the
>> dummy node still exists from an XPath-processing perspective
>> so if you wish to write full XPointer exceptions, the form
>> #xpointer(/dummy/Blah) will be needed. I think this is a
>> rare and documentable case.
>
>Ok, apologies for my brain block on the iteration, step 4 is very clear. 
>
>> It is, as I say, contrived. The inner Data element containing
>> arbitrary data is first encrypted (EncryptedData#2). Then
>> EncryptedData#1 is generated and its ciphertext is put in a
>> new Data element that happens to have the same Id as the one
>> that is now encrypted. So there never was an invalid document.
>> Now, run this through the decryption transform as currently
>> specified and the behaviour is indeterminate.
>
>Would doing something as simple as saying "select the first e in document 
>order" for each iteration solve this problem?

It would be a bandage over the nondeterminism; however, the
current processing model is still unnecessarily inefficient (a
full serialize, wrap, parse and trim is performed for *each*
EncryptedData, where only one such step is necessary), broken
(it doesn't work, as currently specified; and, even if fixed,
references into (i.e., exceptions) and out of (i.e., key and
data references) the first EncryptedData will be with respect
to the initial document, whereas for subsequent EncryptedData
they will be with respect to dummy documents) and, IMHO, just
plain wrong. I can cite more reasons; XPointer exceptions
basically can't be used; the output node set is radically
different if none of the input happens to be encrypted,
super-encryption is automatically undone, etc.

I also have a new requirement:

I would like to be able to indicate that certain custom Type
URIs should be treated as XML. For example, I would like to
be able to have <EncryptedData Type="&foo;PrivateKey" ... />
to indicate that encrypted data are a PrivateKey element. I
agree that this is just &enc;Element; however, the alternative
type is more informative. For a proposed solution, see the
attached (which is my suggested changes with another change).

However, all these changes boil down to a large refactoring
of the decryption transform spec; and, if I am unique in
my viewpoint, then I am at an impasse and must cede to the
majority view and stand by my former stated views on the
subject.

Merlin