RE: Attribute encryption

The current spec was written with the view that if there was not a concensus
(among the authors) that if a certain feature was required, that feature was
not put into the spec.  The idea is that we start with something very
minimal and only add it to it when there is a strong case for the addition
of a feature.
 
Personally, I am very much in favour of supporting the encryption of
attributes in a way that allows the application to select which attributes
get encrypted.  Indeed, I have already proposed a mechanism for this feature
and written reference code implementing that mechanism.  In my proposal, XML
Encryption would define an EncryptedDataManifest attribute and
EncryptedDataManifest element within the XML Encryption namespace.  The
presence of an EncryptedDataManifest attribute in an element indicates to
the application that there is encrypted data associated with that element;
that data may be either encrypted attributes or encrypted external data.
The value of the EncryptedDataManifest attribute points to an
EncryptedDataManifest element containing one or more EncryptedData elements.
If the type of a contained EncryptedData element is "AttributeValue", then
it contains the encrypted value of the element's attribute identified by the
EncryptedData element's Name attribute.
 
Here's an example to clarify the explanation.  Suppose you have an element:
 
<Element AttributeA="A" AttributeB="B" 
         AttributeValueToBeEncrypted1="super secret info 1"
         AttributeValueToBeEncrypted2="super secret info 2"> 
  ...element content...
</Element> 
<?xml:namespace prefix = p ns =
"urn:schemas-microsoft-com:office:powerpoint" /> 
The above becomes the following when XML Encryption is applied:
 
<Element AttributeA="A" AttributeB="B" 
         AttributeValueToBeEncrypted1="ONI9WvqL7RFN9FBB59kC3A==" 
         AttributeValueToBeEncrypted2="A2e35shNcL5sWwUKfyzHoQ==" 
         enc:EncryptedDataManifest="./EncryptedDataManifest" 
         xmlns:enc="http://www.example.org/xmlenc"> 
  <EncryptedDataManifest xmlns="http://www.exampleorg/xmlenc"> 
    <EncryptedData 
      Name="AttributeValueToBeEncrypted1"
      Type="AttributeValue">
      ...
    </EncryptedData> 
    <EncryptedData 
      Name="AttributeValueToBeEncrypted2"
      Type="AttributeValue">
      ...
    </EncryptedData> 
  </EncryptedDataManifest>
  ...element content...
</Element> 
 
What I like about the EncryptedDataManifest element is that it also works
for external arbitrary data that may be associated with an element.  For
example
 
<img src="secret.gif" alt="A secret description of the referenced GIF"/>
 
becomes the following when XML Encryption is applied:
 
<img src="secret.gif" alt="ONI9WvqL7RFN9FBB59kC3A==" 
         enc:EncryptedDataManifest="./EncryptedDataManifest" 
         xmlns:enc="http://www.example.org/xmlenc"> 
  <EncryptedDataManifest xmlns="http://www.exampleorg/xmlenc"> 
    <EncryptedData 
      Name="secret.gif"
      Type="image/gif">
      ...
    </EncryptedData> 
    <EncryptedData 
      Name="alt"
      Type="AttributeValue">
      ...
    </EncryptedData> 
  </EncryptedDataManifest>
  ...element content...
</Element> 
 
Note that the EncryptedDataManifest attribute and element would not be
mandatory if an application wanted to devise its own way of handling these
types of data.  However, it is my feeling that this syntax would satisfy the
vast majority of existing XML applications.  I'd like to hear others
opinions on this subject.
 
One argument against encrypting attributes is that attribute values are
typically short and a simple length analysis can be used to decipher an
encrypted attribute value.  I recognize this problem but see it equally
applicable to elements with short content.  It seems to me that one solution
would be, upon encryption, to introduce a do PKCS5 padding just after the
plaintext is converted to bytes and, upon decryption, to remove the padding
from the decrypted bytes before thn converting the bytes to XML.
 
Encryption of attributes was briefly discussed at the XML Encryption
workshop last November and a straw poll was held to get an idea of what
support there was for encrypted attributes.  The result of that poll was
very narrow support for the encryption of attributes.  As the XML Encryption
effort becomes more formally established, we will need to more thoroughly
debate and measure support for the encryption of attributes.

Regards, Ed
 
 -----Original Message-----
From: Sanjeev Hirve [mailto:shirve@cyberelan.com]
Sent: Monday, January 08, 2001 9:51 AM
To: xml-encryption@w3.org
Cc: Michael Sakhatsky; Raju Nadakaduty; Marcus A Cuda
Subject: Attribute encryption



The latest proposal does not treat element content consistently.  I propose
the following change to EncryptedData-Type.
Element : no change,
Content : encrypts all attributes and child nodes of element.
NodeList : retain ?
 
The rationale is as follows:
1- one can expect applications where the Name of the element can give away
information, hence we need the ability to encrypt the name.  On the other
hand, leaving the name exposed makes it easier to process a document (eg
moving data to/from database columns).
2- information is typically stored either in content or in attributes.  The
choice sometimes is arbitrary, or driven by other factors.  Thus attributes
data can be as sensitive as child nodes.
 
Thus there will be valid situations where the application needs to hide
attribute data, but leave the element name enclair.
 
However, certain attributes should not be encrypted:
  1- attributes of type ID
  2- namespace attribute
  3- others ?
 
regards
SSH