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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Tue, 04 Jun 2002 01:26:51 +0100
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: xml-encryption@w3.org
Message-Id: <20020604002651.BF2744432D@yog-sothoth.ie.baltimore.com>


Hi Takeshi,

r/IMAMU@jp.ibm.com/2002.06.03/01:16:33
>>Bear in mind that applications that encrypt parts of a signed
>>document cannot, by definition, be ignorant of XML security
>>concerns. They must understand that namespaces cannot be
>>rewritten, whitespace cannot be changed, comments cannot
>>be stripped, etc. With this in mind, trying to produce
>>a specification that can undo arbitrary changes made by
>>arbitrary security-ignorant applications is, in my opinion,
>>a white elephant. These applications must be aware of the
>>limitations of the tools that they have available to them.
>>Multiple encryption is a minor limitation of this tool.
>
>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

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

Merlin
Received on Monday, 3 June 2002 20:28:18 UTC

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