Re: XML Encryption: A third proposal (with attachment)

Hi, Joseph

> 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)?

The image was a little bit incorrect: Encryption is only dsplayed as a 
black node without further information and there does not exist any key 
material. Till thursday, I'll have more clarifying examples.

> 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 (a): I don't have a _real_world_ scenario, in which something like this 
would be absolutely nececary, because some re-arangements in the specific 
schema will allow it to put public information out of such a subtree. The 
main reason for this was that the access control people could perform such 
transformations and our subtree encryption couldn'd, so I was looking for a 
solution.

To (b): Do you think that such a transformation is not possible?

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

No, even more: you have 7 element-keys (K_noden) AND 2 key-encryption-keys 
for the 2 recipients (K_recipientn).

Assume that recipient1 can see nodes 1,3,5, while recipient2 is allowed to 
see all but 3. Then you have the key packages for the recipients 
(E_{K_1}(A|B) means A and B are encrypted under key K_1):

Keyblock for recipient1: E_{K_recipient1}(K_node1|K_node3|K_node5)
Keyblock for recipient1: 
E_{K_recipient1}(K_node1|K_node2|K_node4|K_node5|K_node6|K_node7)

Received on Tuesday, 31 October 2000 17:28:10 UTC