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

Re: XML decryption transform number 13

From: merlin <merlin@baltimore.ie>
Date: Tue, 04 Jun 2002 02:00:34 +0100
To: reagle@w3.org
Cc: xml-encryption@w3.org
Message-Id: <20020604010034.B15584432D@yog-sothoth.ie.baltimore.com>

>On Friday 31 May 2002 08:23 pm, merlin wrote:
>>   o For each unexceptional EncryptedData in the node set:
>>     * If its Type is &xenc;(Content|Element) then decrypt
>>       it, wrap it in the parsing context of the EncryptedData
>>       element, parse this and trim it. (Aside: I think that
>>       this definition of the processing of these Types
>>       should be in the xmlenc spec. We could then allow
>>       decrypt-and-replace mode to operate uniformly on any
>>       Type whose "processing" result is a node set. I am not
>>       asking for wrap/parse/trim to be their specification,
>>       just that the "result" of processing these types is
>>       defined to be a node set, a non-normative implementation
>>       of which is wrap/parse/trim.)
>This sounds like a good idea.

How should I process your approbation? That this might actually
be a useful change to the xmlenc spec, or that it would just
be an interesting approach.

>>     * Save these node sets; they will be the replacements for
>>       the EncryptedData elements; they may be element or
>>       element content.
>>   o Canonicalize the input node set but, in place of every
>>     unexceptional EncryptedData, canonicalize the replacement
>>     node set. Note that the result may not be in canonical
>>     form.
>By this I presume you mean you agree with my earlier (off-list) comment 
>that a c14nized document with parts of itself replaced with other c14nized 
>fragments itself (all-together) might not be in c14n form? (The boundaries 
>between the original document and the "holes" were content being replace 
>with c14nized fragments might exhibit some non-c14n variants when looked at 
>as a whole.)


>> . Every EncryptedData in XML mode must, after decryption
>>   and processing in accordance with the Type attribute, result
>>   in a node set. This is simply a requirement that we place on
>>   apps that encrypt data for subjection to &decrypt;XML. Use
>>   another transform if you don't like this.
>Why must it be a nodeset (and not octets?)

Because it would seem, to me, that a Type representing
encrypted XML would not in general correspond to serialized
XML, but rather to data that can be translated into XML,
which we generalize as a node set, by some mechanism.

Types &xenc;Content and &xenc;Element do correspond to
serialized XML, as do &gzip;Content and &gzip;Element; and,
by wrapping, parsing and trimming this (which I advocate
being their defined processing) we get a node set. Type
&java;SerializedObject, when deserialized, will be a
node set.

Any Type that actually represents serialized XML needs
to define how that should be parsed (does it need to be
wrapped), etc. Rather than forcing our interpretation of the
parsing process on such types, I think we should mandate
that they define how they are processed to produce a node
set; and, as a result, that's what we accept.

If we accept serialized XML as an octet string, then
the optimization below is not possible.

>> . A smart implementation will realize that, if this processing
>>   is followed by a canonicalization transform (e.g., if this
>>   is the last transform and the next step is digest) and it
>>   can formulate its replacement node-set canonicalization to
>>   be *identical* to what canonicalization of that node set
>>   in-place would be, then it can omit the redundant parse
>>   and c14n steps.
>Yes (see comments above), to know how hard this would be would take some 
>toying about with it?

It appears relatively straightforward; not much toying is

>> . In terms of performance, we parse the content of each
>>   EncryptedData once, and then do a c14n/parse step on the
>>   whole node set, so this will be reasonably efficient;
>>   particularly if the previous point is followed.
>Efficiency is always a good thing!

In some cases, this may be the most efficient approach. In
others, not. The single-phase approach I described previously
could be better in those cases.

>It sounds as if you and Takeshi might have a straightforward disagreement 
>about requirements. (Correct my summary if I'm wrong).
>Takeshi likes auto-super-decryption and isn't too worried about the problem 
>of XPointer evaluation and references outside of an EncryptedData still 
>working. (And he suggests using "#xpointer(id('ID'))" *would* still work, 
>is this true...?)
>Merlin is concerned about XPointer evaluation and references outside of an 
>EncryptedData and doesn't find the auto-super-decryption that compelling. 
>(I wonder about this mysef. If I have an application where I know I'm 
>encrypting element X and Y, is super-encryption all that likely?)
>So it would seem we have a tension between these two requirements. If there 
>is no other way to resolve these tensions, at least by making it a specific 
>parameter/transform, the application can make its own choice...

This appears a reasonable summary; however, I am now proposing
automatic super-decryption *if* the encryptor asks for it,
which falls back to my statement that the encryptor *MUST*,
by definition, be XML security-aware.

Received on Monday, 3 June 2002 21:02:03 UTC

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