RE: Multiple DataReference elements

At 13:04 3/29/2001 -0500, David Montgomery wrote:
> > 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),

The use of the Reference is optional, and I'm not sure what *requiring* 
every EncryptedData to be identified does...?

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

My mistaken interpretation of this that actually satisfies your concerns is 
that the ReferenceList should be moved from being publicly accessible as a 
child of EncryptedKey into the encrypted portion -- hidden in CipherData. So 
when I process an EncryptedKey I don't know what data it encrypts, but if I 
decrypt its CipherData I will find a KeyInfo with a symmetric key and a 
ReferenceList that lists the elements encrypted by that key.

This doesn't necessitate a EncryptedDataSet (I think I need more 
specification to understand).

A confusing representation of what I understand is:

Given the present case of:
         EncryptedData
          - ID=ED1
          - KeyRetrievalMethod=#EKBob
          - KeyRetrievalMethod=#EKEve
          - Cipher Data

         EncryptedData
          - ID=ED2
          - KeyRetreivalMethod=#EKEve
          - CipherData

         EncryptedKey
          - ID=EKBob
          - DataReference=#ED1
          - DataReference=#ED2
          - CipherData (only available to Bob)
            - KeyInfo
              - SymKey1

         EncryptedKey
          - ID=EKEve
          - DataReference=#ED1
          - CipherData (only available to Eve)
            - KeyInfo
              - SymKey1

Eve can infer that: If she and Bob have access to #ED1; and if an
EncryptedKey for Bob (#EKBob) that states it can be used to decrypted
#ED1 and #ED2; Eve can also decrypted #ED2.


However, if the DataReferences are secured:

         EncryptedKey
          - ID=EKBob
          - CipherData (only available to Bob)
            - KeyInfo
              - DataReference=#ED1
              - DataReference=#ED2
              - SymKey1

         EncryptedKey
          - ID=EKEve
          - CipherData (only available to Eve)
            - KeyInfo
              - DataReference=#ED1
              - SymKey1

Eve can infer nothing as she cannot 'evesdrop' in on the references in the 
EncryptedKey intended for Bob.



__
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 Thursday, 29 March 2001 18:46:56 UTC