- From: merlin <merlin@baltimore.ie>
- Date: Thu, 30 May 2002 00:36:22 +0100
- To: reagle@w3.org
- Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
- Message-Id: <20020529233622.C07594432D@yog-sothoth.ie.baltimore.com>
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
Attachments
- text/html attachment: xmlenc-decrypt2.html
Received on Wednesday, 29 May 2002 19:37:42 UTC