RE: Attribute encryption

I think that the mode of application for XML encryption has to be carefully
considered
 
Mode 1: Promiscuous Encryption
    Application XYZ has defined a DTD or schema and would like to encrypt
random portions thereof while being entirely backwards compatible.
 
Mode 2: Application leverages XML and XML Encryption
    A new application that has security requirements is proposed, the XYZ
schema is a basis for a new schema that has encrypted components.
 
 
I simply do not agree that Mode 1 has any real utility. XML frameworks are
by design flexible. If there is a need for backwards compatibility then XSLT
can be used to paper over any inconsistency. Viz;
 
Message A is in (old) schema XYX
 
Parts of message A need to be encrypted:
 
Message B is in schema XYZ-ENC where 
    B = Encryptify ( Transformify ( Message A), slt), key)
 
The point is that the fact of encryption by necessity means that we are in a
very different namespace, in most cases Message B will not be legal in the
XYZ schema - I can't imagine how this could be possible!
 
 
What this comes down to is two cases:
 
Case 1:
    Message B states that it is in schema XYZ-ENC and asserts that if one
knows how to decryptify and detransform it the result is valid in schema XYZ
 
Case 2:
    Message B states only that it is in schema PQR which is the standard
schema for the application and incorporates the XML encryption schema. The
node encryption was considered at the time the schema was created.
 
 
Attribute encryption is not a requirement IMNSHO because the schema of the
encrypted document must by necessity be some transformation of the original
document. 
 
 
        Phill

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