RE: Attribute encryption & Blair's message

Although I support the idea of attribute encryption in general,
the practical aspects of key distribution in Steve Wiley's example
elude me. How do we ensure that only those that require access to
encrypted attributes have access to the keys. Which health care
professionals have a need to know?
It seems that we're mixing up authentication with authorization
here. By encrypting attributes for various departments, we encode
authorization levels into the message itself; something that is 
usually left externally configurable. A better solution here might
be to have the entire message encrypted with one key, and have the
accessing applications sort out authorization based on role,
transforming the original message to one that is appropriate for the
individual (or role).

-DanT

Daniel Toth -- dtoth3@ford.com
Senior Integration Architect, PL Implementation - IT Research & Planning
Desk:(313)322-9103    FAX:(313)621-8392


> -----Original Message-----
> From: Steve Wiley [mailto:steve@myProof.com]
> Sent: Friday, January 12, 2001 6:48 PM
> To: Blair Dillaway; 'Thane Plambeck'; 'xml-encryption@w3.org'
> Subject: 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 Monday, 15 January 2001 14:16:28 UTC