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

Re: Decryption Transform processing question

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Wed, 5 Jun 2002 00:58:49 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OF5B0A4226.47CE2079-ON49256BCE.004BF22D@LocalDomain>


>>I don't agree.  I don't still think that limiting multiple encryption
makes
>>sense.
>
>We clearly disagree slightly on the relative importance of
>multiple encryption and same-document references. However, in
>my latest proposal (13(rev 2), [1]) I suggest how to support
>multiple encryption, using an explicit Type that indicates
>that recursive EncryptedData should be decrypted. Do you have
>an opinion on this? Does it meet your needs?
>
>[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Jun/0000.html

I don't think that using an explicit Type attribute value is a good
proposal.  It is not an encryptor but a signer that decides whether an
EncryptedData element should be decrypted.  Also, if a signature is
detached, an encryptor cannot know whether an EncryptedData element should
be decrypted.

>>According to the discussion, it seems that you are concerned about
>>the following:
>>
>>1. XPointer evaluation
>>2. Reference to outside of an EncryptedData element
>>
>>I understand that there are some cases where 1 and 2 are not addressed
>>properly, but considering the purpose of decryption transform, I don'
think
>>that we should limit the function of the transform for that reason.
>>Rather, I prefer to limit 1 and 2.  As for XPointer, all we have to do is
>>to note in the spec that it is recommended to use "#xpointer(id('ID'))".
>>As for reference, the transform is not responsible for whether a
reference
>>can be dereferenced or not.  If the reference is not dereferenced, the
>>validation will fail, but that is the correct result.
>
>While 1 isn't of great concern (although it does matter
>to some of our customers), I think that 2 is a terrible,
>inexplicable and unnecessary limitation.
>
>As far as I understand it, you are saying that encryptors
>should be free to encrypt anything in the signed node set
>without restriction, and in the same breath that they cannot
>use same-document references or XPointers? Unfortunately I'm
>not sure we'll ever completely agree on this issue.

I'm sorry for confusing you.  I'm not saying so but saying that:

* An encryptor should be free to encrypt anything in a node-set
* He can use same-document references and XPointers
* He should understand that EncryptedData elements may not be decrypted
successfully because of failures to dereference references, especially when
the elements were super-encrypted.

I believe that my proposal is not opposed but complementary to Merlin's.
The steps would be as follows:

1. If there are any EncryptedData element nodes being decrypted in the
input node-set, decrypt all of the nodes.  References should be
dereferenced.  If there are no such nodes, stop and return the node-set.
2. If there are any EncryptedData element nodes being decrypted in the
resulting node-set, decrypt all of the nodes.  References may not be
dereferenced and some of decryption may fail.  In that case, leave the
nodes in question as they were.  If there are no such nodes, stop and
return the node-set.
3. Go to 2.

Does this meet your needs?

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com
Received on Tuesday, 4 June 2002 11:50:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC