W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Re: Qn about nested encryption

From: Carl Wallace <cwallace@erols.com>
Date: Thu, 11 Jan 2001 16:24:23 -0500
Message-ID: <001201c07c14$defbadc0$0700a8c0@dmn1.corsec.com>
To: <jimsch@exmsft.com>, "'Sanjeev Hirve'" <shirve@cyberelan.com>, "'xml-enc'" <xml-encryption@w3.org>
Cc: "'Joseph M. Reagle Jr.'" <reagle@w3.org>
I had the same question as Sanjeev when I first read section 2.5.  It seems to me that the statement in question is unnecessary and causes confusion.  That the definition of <EncryptedData> does not permit a child <EncryptedData> should be sufficient indication of structure.

Carl
  ----- Original Message ----- 
  From: Jim Schaad 
  To: 'Sanjeev Hirve' ; 'xml-enc' 
  Cc: 'Joseph M. Reagle Jr.' 
  Sent: Wednesday, January 03, 2001 3:23 AM
  Subject: RE: Qn about nested encryption


  This statement is about structure not about content.  You are permitted to take anc EncryptedData element, encrypted as the content of another EncryptedData element.  What is not allowed is to place a node labeled EncryptedData within a node labeled EncryptedData.

  Thus:
   <EncryptedData>
       ......
       <EncryptedData>
       ......
       </EncryptedData>
       ....
  </EncryptedData>

  is disallowed not

  <EncryptedData>
    ....
    <CipherText> base64 of a an encrypted EncryptedData node goes here</CipherText>
  </EncrypteData>

  jim
    -----Original Message-----
    From: xml-encryption-request@w3.org [mailto:xml-encryption-request@w3.org]On Behalf Of Sanjeev Hirve
    Sent: Tuesday, January 02, 2001 8:13 AM
    To: xml-enc
    Cc: Joseph M. Reagle Jr.
    Subject: Qn about nested encryption


    With ref to the proposal "XML encryption syntax and processing" v 1.0, dated 2000/12/15, by Dillaway et al, I hav the following question.
    Section 2.5 states that "..it is not valid to nest these objects, i.e., an Encrypted Data may not be a child of an Encrypted Data."
    I dont understand the reason behind this constraint.
    Consider the case where a document is encrypted for multiple recipients.  It is reasonable requirement that recipient A is authorized to access an element X and all its descendents, while recipient B may is authorized to access the same element X less some of its descendents, say element Y.
    A simple way to solve this is to first encrypt element Y with key K1, then encrypt element X with key K2.  A has access to K1 and K2 and must decrypt elem X and then Y.

    I think, the following memo:
    http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/att-0011/01-myproof-xml-encryption-position.html
    also refers to the same issue.

    regards
    SSH
Received on Thursday, 11 January 2001 16:20:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT