RE: Multiple DataReference elements

At 18:19 3/23/2001, Joseph M. Reagle wrote:
> 
> I don't see what was sent in Eve directs her (or gives her 
> access to ) what was sent to Bob.
> 
Eve and Bob share a symmetric key, so Eve can try her key on any
EncryptedData emitted by Alice and encrypted for Bob, whether in the same
document or not.

> 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.
> 
Yes, Eve can decrypt DataB, yet Xenc syntax does not indicate that
explicitly, as your synopsis shows.
> 
> 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.
> 
Exactly. 

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

I would prefer that Xenc syntax explicitly identify all EncrytedData
elements that are encrypted by the same symmetric key, so I like (3), but I
agree that those semantics are difficult to express within the current Xenc.
I would have liked XEnc to provide an element that contains references to
all EncryptedData elements that are encrypted by the same symmetric key.
That element, EncryptedDataSet say, would also contain references to the
recipients' EncryptedKeys;  the EncryptedData elements would not point
directly at the recipients.  Similarly, EncryptedKey would not directly
reference the EncryptedData elements of that set, it would reference the
EncryptedDataSet itself.

Optionally, EncryptedDataSet might specify an encryption procedure that
applies to the set as a whole. For example, the IV must not be re-used
between EncryptedData elements that share a symmetric key (otherwise,
patterns in the plaintext are apparent in the ciphertext).  Instead of a
fresh IV for each element, one might prefer to define a single IV for the
set and chain CBC throughout its elements.  [This also deters an attack that
swaps EncryptedData elements.]  

IMHO, if a recipient requires access to a proper subset of the elements that
are encrypted by a particular symmetric key (Eve's situation), that should
be communicated outside the scope of Xenc;  the EncryptedKey (or
EncryptedDataSet) should identify all such elements.

Entrust Technologies Inc. We Bring Trust to e-Business
D.S. Montgomery, mailto:david.montgomery@entrust.com