Re: Multiple DataReference elements

At 10:49 3/23/2001 -0500, David Montgomery wrote:
>The use of multiple DataReference elements allows the following flawed 
>relationship;  Alice must encrypt EncryptedData-A and EncryptedData-B with 
>the same symmetric key, which is encrypted with Bob's public key in 
>EncryptedKey-Bob.  If Eve is a second recipient of EncryptedData-A, she 
>gains indirect access to EncryptedData-B, which Alice did not 
>intend.  (Same applies to KeyReferences.)

I'm not sure if I follow this scenario, I suppose there are two ways I could 
interpret it and I'm adding KeyRetrieval since I'm not sure what was leaked 
without it.

[You might not want to waste time on my syntax, and just read the possible 
"Security Concerns"  recommendations.]

   SK1=symmetric key 1
   PKB=Public Key Bob
   PKE=Public Key Eve
   DR=Data Reference

1. These things are not in the same document.

The following is sent to Bob (two EncryptedDatas and EncryptedKey)
   1:((DataA)SK1,ID="AB", KeyRetr="Bob'sSym1")
   2:((DataB)SK1,ID="BB", KeyRetr="Bob'sSym1")
   3:((SK1)PKB,KeyName="Bob'sSym1", DR="AB" DR="BB" )

The following is sent to Eve (EncryptedData and EncryptedKey)
   4:((DataA)SK1,ID="AE", KeyRetr="Eve'sSym1")
   5:((SK1)PKE,KeyName="Eve'sSym1", DR="AE")

I don't see what was sent in Eve directs her (or gives her access to ) what 
was sent to Bob.

2. As you represent in your document, these things are in the same document? 
The thing I don't understand in your diagram is are you saying the 
EncryptedData-A is actually represented to Bob *and* Eve as:
   1:((DataA)SK1,ID="AB", KeyRetr="Bob'sSym1" KeyRetr="Eve'sSym1")
   Hence, Bob'sSym1=Eve'sSym1, and since
   2:((DataB)SK1,ID="BB", KeyRetr="Bob'sSym1")
   She has access to DataB.
__

Regardless of any of references (assume none), Eve might note that when a 
Data Encrypted for Bob looks just like a Data Encrypted for Eve, she might 
try her symmetric key on other things Encrypted for Bob.

So, I don't think we can or want to prevent this functionality because of 
this, but we could make two sorts of recommendations:
1. A symmetric key should *not* be shared amongst multiple recipients. (This 
prevents useful functionality.)
2. Don't use references. (This prevents useful functionality.)
3. where a symmetric key is shared amongst multiple recipients, its 
encapsulating EncryptedKey should not reference or be referenced by other 
data not intended for all of those multiple recipients. (Kind of complex...?)
4. Where a symmetric key is shared amongst multiple recipients, that 
symmetric key should *only* be used for the data intended for those multiple 
recipients. (Quite strong.)


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

Received on Friday, 23 March 2001 18:19:23 UTC