RE: Attribute encryption & Blair's message

At 02:39 PM 1/11/2001 -0800, Blair Dillaway wrote:
>I remain unconvinced that there is sufficient value in encrypting only 
>attribute values, while trying to maintain some similarity to the original 
>schema. I simply don't buy the argument that recipients of such encrypted 
>docs can do meaningful and robust interpretation of the containing 
>elements while ignoring the cipher text and encryption information. If the 
>recipient only understands the original schema, then the encrypted 
>document in invalid. On what basis should they decide to ignore improperly 
>encoded and/or extraneous data within an element? Simply ignoring 
>everything you don't understand in an element, while assuming the rest is 
>something you do understand, seems incredibly brittle and error prone.

Here is an example that is close to real applications that our company is 
working with.  It is very workable without forcing the customer to change 
their XML schemas.

Medical establishment example:

<Patient contagion-alert="blood" contagion-level="high" . . . . >
   <name>Jane Doe</name>
   <address> . . . . . .
   <account-balance>$120.00</account-balance>
   . . .
</Patient>

The above patient record alerts practitioners that the patient has a highly 
contagious blood condition (possibly HIV). The practitioners need to know 
this, but for patient privacy the billing department should not see this 
information.  Likewise the medical practitioners should not see the 
<account-balance> because all patients should be treated equally.

The following document is sent to both departments:

<Patient contagion-alert="HJE8...UHE==" contagion-level="IjBHy...jkJM=" . . 
. . >
   <name>Jane Doe</name>
   <address> . . . . . .
   <account-balance>UHyhJ...J87Hn</account-balance>
   . . .
</Patient>

The company could distribute a single application for viewing patient 
records.  The treatment room has the key to decrypt the 'contagion-alert' 
and 'contagion-level' attributes. Someone in the treatment room would  see 
this display:

The patient name is: Jane Doe
Contagion Info: WARNING, high risk of blood contagion
Account balance: UHyhJ...J87Hn

The billing department has the key to decrypt the <account-balance>. 
Someone in the billing department would see this display:

The patient name is: Jane Doe
Contagion Info: NOT AVAILABLE
Account balance: $120.00

The application assumes that if 'contagion-level' is not "high", "low", or 
"none" then the information is not available.  At worst the application can 
just display the cypher-text.

In the case of the <account-balance>, it just displays the data.  If it 
isn't readable, that is what is desired.  Or, the application could check 
for currency formats but it is not necessary.

As for automated processing of the information, the billing department 
application should not need to process the 'contagion-alert' and 
'contagion-level' attributes.

The treatment room record processing does not need to process the 
<account-balance> element.

It all works.  It is not complex.


>Robust processing of encrypted docs implies knowledge of the schema 
>against which the encrypted document is valid. Hence, moving sensitve 
>attribute info into child elements for those few apps that only want the 
>attribute encrypted, doesn't seem that onerous to me. Especially if it 
>signficantly simplifies building encryption/decryption processors.

It could be very onerous for companies that have pre-existing XML data and 
applications.

But the main issue for me is "What is my job as a software engineer?".  I 
believe that (in the XML world) it is my job to provide simple and 
maintainable applications and standards for handling data.  Elements 
contain significant data.  Attributes contain significant data.  My job is 
to supply solutions for encrypting that data if there is a need for 
it.  And, there is a need for it.

Good development tools should simplify the building of 
encryption/decryption processors.  Restricting the flexibility of business 
applications is not a good way to simplify.  Attributes were designed into 
XML to be used.

>BTW, I am still open to changing my mind on this if we can identify 
>applications where the value of attribute only encryption justifies the 
>complexity.

See the <Patient contagion-alert. . .> example above.

I admit that as a designer I am looking at these issues from a business 
perspective rather than an academic perspective.  I can supply some other 
examples if need be.  I want to give businesses easy concepts to 
understand.  I would much rather sell or explain a simple concept to a 
customer, and write more complex code, than the reverse.  Customers are 
used to using attributes and elements to store data.  I really do not want 
to have to explain why they can only store non sensitive data in attributes.

Respectfully,
Steve Wiley

Received on Saturday, 13 January 2001 11:57:00 UTC