- From: merlin <merlin@baltimore.ie>
- Date: Wed, 29 May 2002 19:59:09 +0100
- To: reagle@w3.org
- Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
r/reagle@w3.org/2002.05.29/14:13:47 >On Thursday 09 May 2002 12:12 pm, Takeshi Imamura wrote: >> Thank you for the detailed explanation. I think that I understand, but I >> don't still like a single phase of decryption. > >I'm not sure I understand this issue completely, but I would like to close >it. So how to do that...? <smile/> Ok, I'll state two requirements that I'd >support: >1. If more than one "layer" of decryption is required (to peel back >super-encrypted elements) then multiple decryption transforms should be >used, with the input of a later transform being the output of the preceding >decryption transform. This is what I advocate. That is, a single decryption transform operates on all the unexceptional EncryptedData elements in its input node set in a single phase, without iteration. If super-encryption has occurred then multiple decryption transforms are required. The second decryption transform will explicitly and clearly be operating in the context of a dummy-rooted document and so can be correctly constructed in this accord. >2. Relative URIs should be interprated with respect to their layer only -- >though one can have instances in which relative URIs have no target >(they've been obscured/encrypted). Having to specify URIs with /dummy in >the path should be avoided. Relative URIs should be interpreted with respect to the owner document of their input node set. In the case of a single decryption transform over a same-document reference, then this will be with respect to the signature document. In the case of a single decryption transform over a remote reference, then this will be with respect to the root of that document. Subsequent decryption transforms will be operating on a dummy-rooted document and so their exception URIs can be easily constructed with this in mind. >So I think Takeshi and I are in agreement with respect to the first >requirement. Has it proven impossible to support the second and first >requirement together? Is Merlin's advocacy for multi-round so that >requirement two is met or for a different reason? My advocacy is for single-round. Well, presuming that our semiotics are synchronized. I tried to describe it in the [1] that you quote below. >> Rather, I >> would like to suggest restricting the input node-set in order to support >> multiple phases of decryption, where each EncryptedData element in the >> node-set should not reference the outside of the element in the same >> document. > >How would you enforce this? (Have you guys had a chance to look at some of >the ways that XInclude addresses these issues [a]). Merlin, do you agree >with this? > >[a] http://www.w3.org/TR/xinclude/#references-property No, I think that reference what thou wilt should be the whole of the law. In the usual case of a single decryption transform, decrypted data will be processed in the context of the entire input document and so they can reference what they wilt. If an application seeks to perform multiple encryption and then use multiple decryption transforms, then it must understand that inner ciphertexts will be decrypted in the context of a dummy-rooted node set and so their (and only their) same-document references will be limited. >> I think I've said my piece on this matter. If no one else has >> an opinion then let us leave the transform as-is and note, >> for the record, my opinion that it appears to be inconsistent >> and non-deterministic > >Merlin, in what way is it non-deterministic? If I have a signature with two >decryption transforms as presently specified, won't they yield the same >thing each time? The current specification states that we shall iteratively and stochastically decrypt, wrap and parse elements until there are no more unexceptional EncryptedData. The first element that is decrypted will have references and exceptions resolved with respect to the initial document. All subsequent will have then be processed within a dummy document. The random nature of this gives rise to the non-determinism for a single decryption transform. <Document> <SignedPart> <EncryptedData CipherReference=#data /> <EncryptedData <Data Id='data' /> /> </SignedPart> <Data Id='data' /> </Document> If I decrypt EncryptedData #1 first, then it will get its data from the outer Data element. If I decrypt EncryptedData #2 first, then EncryptedData #1 will be processed in a document where only the new Data exists, so it will get its data from there. This is contrived but stochastic. The rules I suggest are deterministic: Both will be encrypted within the context of this document during a single phase. Also, consider this: <Document> <EncryptedData /> <EncryptedData /> </Document> Except URI = #xpointer(/Document/EncryptedData[2]) During round 1 of the current spec, I will except the second EncryptedData. During round 2, the Document is gone so I will try and decrypt it. Merlin >> and should be reformulated as [1] in >> supersedence of what I may have said in the past. > >Takeshi, do you agree with these changes? > >> [1] http://lists.w3.org/Archives/Public/xml-encryption/2002May/0016.html > >-- > >Joseph Reagle Jr. http://www.w3.org/People/Reagle/ >W3C Policy Analyst mailto:reagle@w3.org >IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ >W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ >
Received on Wednesday, 29 May 2002 15:00:21 UTC