XML Encryption: A third proposal (with attachment)

Christian,

Interesting analysis and proposal! [1] A couple of comments follow:

1. The diagrams are very useful in understanding the differences, but could 
you provide an example fo the resulting syntax from the "result of 
encryption" under your proposal (the 3rd tree on page 4)?

>2.2 Comparison
>This "new" model has some advantages, as well as some disadvantages: ...
>  the re-assembling of the tree allows public visible nodes deep inside a 
> almost
>completely encrypted subtree.

2. I haven't given much thought to this problem of permitting a child of 
encrypted parents to be transparent. My quick thoughts prior to reading your 
note was that (a) I wondered if this is a likely scenario and (b) I wondered 
if such a thing could be achieved by encrypting each infoset element node 
item independently (or through some fancy XPath).

>• To attach the position information to all nodes, the size of the 
>encrypted document is increased.

3. In fact in reading your analysis I have this unsubstantiated feeling that 
if we used the Infoset data model your approach might follow naturally.

>• Each node needs it’s own cryptographic key, so much key material is needed.

4. That's the case as you proposed, but it's not necessary to the design is 
it? If I'm encrypting 7 nodes, but I have only 2 recipients, I don't have to 
use 7 different node keys, right?

[1] http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0042.html

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 31 October 2000 14:11:46 UTC