W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Exactly how complex is Attribute Encryption

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 31 Jan 2001 16:46:03 -0500
Message-Id: <4.3.2.7.2.20010131163252.02014f08@rpcp.mit.edu>
To: Blair Dillaway <blaird@microsoft.com>, Ed Simon <ed.simon@entrust.com>, Phillip hallam-Baker <pbaker@verisign.com>
Cc: "Public XML Encryption List" <xml-encryption@w3.org>
In a previous message I wrote:
>http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0058.html
>I'm also wondering if there's a middle ground between Blair/Phil/Thane's 
>point of view and Ed/Steve/Sanjeev's point of view so the WG could migrate 
>its design if need be once we start getting wider review, and I suspect 
>this would also serve the effort of hitting the end user sweet spot of 
>scope versus complexity (forcing attribute encryption implementation on 
>everyone versus abandoning the requirements of a part of the community.)

I've been thinking some about the above with the idea that a good proto 
design (on something contentious) is one in which a change in requirement 
(supporting, or not, attributes) does not necessitate replacement of design, 
but migration. So I've been wondering what exactly are the differences 
required by Ed's proposal and wondering how complex they are compared to the 
alternative:

Ed's proposal:

1.  requires a EncryptedDataManifest (since there now can be more than one 
chunks of encrypted data for an element). Easy.
2. a Name attribute which identifies the resource for whom the ciphertext 
applies.
2.1 This could be a Name for which the processor then needs to do a match: 
go parse the tree for an attribute with this name. I'm unsure of the 
complexity but it would need more specification as attribute names 
themselves are not guaranteed to be unique.
2.2 This could also be an XPath which is more straightforward, but then 
requires XPath.
2.3  This also would be useful for "detached" encryption -- not being 
required to always place the EncryptedData in the document Encrypted. This 
could be a feature, and a source of bugs as we already have bidirectional 
key indirections and it could get complicated...

Alternative:

The one alternative that come's to mind is that if an application has 
heterogeneous sensitivity across elements/attributes, it should transform it 
into a simple XML (where everything is represented as element+content). 
Would this necessitate XML Encryption add the feature of Transforms?


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Wednesday, 31 January 2001 16:49:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT