Re: XML decryption transform number 13

On Tuesday 18 June 2002 01:47 pm, Ari Kermaier wrote:
> I may be missing some of the cumulative intent/state-of-mind of the
> current thread, but I think we're allowing our difficulties with the
> Decryption Transform, which is more closely linked to the Signature
> processing model, to pollute the Encryption specification.

Hi Ari, to wonder back through the thread this is my recollection (folks 
should correct me):

1. Merlin asked how one would use something like compressed XML; I 
responded that one would create such a type, as indicated in the 
EncryptedData.

2. Merlin proposed an additional attribute that allowed you indicate a 
class of types; after discussion we dropped this idea and moved towards 
genercise processing, and let an algorithm ID indicate ciphertext should be 
treated (XML or binary), then the Type can carry other useful information. 
(Merlin also interested in being able to pull/decrypt multiple binaries out 
of a document.) Additionally, the XENC spec should contain information on 
the wrap/serialize/decrypt, not the signature transform. I agree and 
provisionally migrate the text over there. Takeshi mentions that we 
implicitly thinking in terms of XPath node-set, so we should make it 
explcit. We now have some disagreement about that migrated text with 
respect to its abstractness/specificity (i.e., copying nodes) and 
"node-set" discussion.

3. Merlin also notes some other concerns as specified in the CRs: (1) the 
wrap/serialize/parse for every EncryptedData in the present CR might not be 
very efficient, (2) during  the intermediate steps of auto-matic super 
decryption, references within the document will not work. We haven't come 
to complete agreement on this yet (I don't think).

So there's a few issues "in the air" at which point I like to say, "Ok, a 
new draft would help me see where the balls are" -- but folks implementing 
are typically much better jugglers than me so the ideas continue to get 
tossed back and forth! <smile/>

> I'm thinking
> that, since the XML Encryption spec does not express any of its
> processing rules in terms of XPath node-sets (but rather in terms of XML
> elements and UTF-8 octets), neither should the implementation notes. The
> XPath data model may be a higher level of abstraction, but it doesn't map
> completely back to the conventions used in the Encryption spec. I think a
> good discussion of pitfalls/limitations/warnings for decrypt-and-replace
> implementations, from a concrete perspective (parsing context for text
> wrapping, XPointer issues, super-encryption, etc.), might be more
> appropriate than additional abstract rules intended primarily to make the
> Decrypt Transform easier to describe. 

A. Do you support abstract specification of encrypt-replace. It sounds as 
if you don't. Consequently from an editorial point of view, for [1], it 
sounds as if you would advocate we remove sections 4.3.{1,2} (i.e., 
non-normative implementation of decrypt, and decrypt-and-replace), maintain 
4.3.{3,4} (i.e., serialization and wrapping)?
B. Do you support two parameteres in the algorithm URI (&xenc; and &binary)?
C. Do you want to support automatic super-decryption. 
D. How should we address broken references? Do you support the hack:
>> We don't repeatedly dereference exceptions into each decrypted
>> node set; we dereference them once into the input document
>> (because when the signature was generated, that was what
>> they were built for) and then we have a hack that #foo can
>> be dereferenced into a decrypted node set.


[1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
$Revision: 1.212 $

Received on Tuesday, 18 June 2002 15:33:06 UTC