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

Re: Decryption Transform processing question

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
Message-Id: <20020529185909.8A63C4432D@yog-sothoth.ie.baltimore.com>

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

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.

    <EncryptedData CipherReference=#data />
    <EncryptedData <Data Id='data' /> />
  <Data Id='data' />

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:

  <EncryptedData />
  <EncryptedData />

  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.


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

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