W3C home > Mailing lists > Public > xml-encryption@w3.org > May 2002

Re: Decryption Transform processing question

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 29 May 2002 14:13:47 -0400
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>, merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-Id: <20020529181347.4D0A485A94@aeon.w3.org>

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 
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.
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.

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?

> 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

> 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?

> 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 14:15:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC