RE: Attribute encryption

[This is just a resend of my previous note.  I noticed that the archived 
version seems to expose an Office 2000 formatting instruction that was not 
visible to me when I composed the note.]

The current spec was written with the view that if there was not a concensus 
(among the authors) that 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>

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

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Received on Monday, 8 January 2001 14:57:31 UTC