RE: Attribute encryption

Sanjeev,

Can you be more concrete, with an XML + schema example, to demonstrate why
Attribute encryption is required for this application? Based on the
discussion below, I don't see the necessity for it. Sounds pretty much like
straightforward separation of information into header and body sections.  In
fact, you never mention Attributes until your closing assertion that its
needed.

Ed Simon's earlier email stated quite clearly the issue of complexity versus
value many of us are wrestling with. I have yet to see a compelling example
that justifies the complexity and tend to agree with Philip H.'s earlier
comments that "the set of all XML applications that require encryption to be
added under the constraint of inflexible adherence to a legacy schema is the
empty set."

The argument in favor of attribute encryption seems to based on the notion
that a receipient can take advantage of the existance of a known Element in
some legacy schema, even if its attribute values are opaque. I have trouble
with this argument.

To simplify Ed's earlier example. Consider the document

   <myns:MyElement myns:A1="A" myns:A2="super secret info 1"> 
      ...element content...
   </myns:MyElement> 

This is valid with respect to some schema know to the originator A and
recipients B & C. After XML Encryption is applied, we have:

<myns:MyElement myns:A1="A" myns:A2="ONI9WvqL7RFN9FBB59kC3A=="
   enc:EncryptedDataManifest="./EncryptedDataManifest" 
   xmlns:enc="http://www.example.org/xmlenc"> 
   <EncryptedDataManifest xmlns="http://www.exampleorg/xmlenc"> 
      <EncryptedData 
          Name="myns:A2"
         Type="AttributeValue">
          . .. 
      </EncryptedData> 
   </EncryptedDataManifest>
   ...element content... 
</myns:MyElement> 

Except under some very restrictive assumptions, the myns:MyElement is no
longer valid wrt to the original document schema. In particular, the
original schema must have specified that:

- attribute A2 is or type string or base64 encoded binary
- an enc:EncryptedDataManifest attribute is allowed
- an enc:EncryptedDataManifest child element allowed

So, as a rule one expects the myns:MyElement in the encrypted document to be
invalid wrt to the original schema. For B to simply ignore this and
interpret it against the original schema is not a robust approach. I would
argue B must understands the schema against which the encrypted document is
valid and make decisions based on this knowledge. But in this case, why
don't we simply do Element encryption and, if necessary, a document
transform to insure B has access to the information it needs? I don't
believe it requires any more effort for the using applications to take this
latter approach than create a new schema which assumes attribute encryption.

Blair

 

-----Original Message-----
From: Sanjeev Hirve [mailto:shirve@cyberelan.com]
Sent: Tuesday, January 09, 2001 7:45 AM
To: Ed Simon; xml-encryption@w3.org
Cc: Michael Sakhatsky; Raju Nadakaduty; Marcus A Cuda
Subject: Re: Attribute encryption



> In any event, I want to hear from a variety of people designing XML specs
and systems about their requirements for XML Encryption.
 
Following is an actual case.
The current system :
   - A sends XML docs via B to C.  B is a "portal"
   - B examines some of the doc elements to perform message routing,
authentication, etc.
   - B does not need access to the doc payload
   - docs are not encrypted, except for SSL
   - B would like access to some of the doc elements, for data mining, etc
 
The new privacy requirements:
   - some customers of B want end-to-end encryption of business data in the
doc
   - groups of customers may agree to allow B access to some business data,
this varies.
 
There is a large existing base of customers who do not need any encryption,
and a small set of customers that has complex encryption requirements.
  The optimal approach is :
   - to modify B's system to ignore parse errors 
   - if any exist, eliminate access to un-needed elments.
   - A always encrypts the doc as the last step, and 
   - C decrypts doc as the first step.
 
The above is a good example of
  - need for partial encryption, including attribute encryption
  - resistance to change existing XML schemae