RE: Attribute encryption

At 16:05 1/17/2001 -0500, Yongge Wang wrote:
>1. For a good design of XML files.  There might need no separate encryption 
>of
>attributes within one element. For example, in the previous discussions, some
>one mentioned
>the following example:
>
><patient  name=".." age=".." contagious="AIDS" CreditCardNumber=".." 
>Price="..">
>... </patient>
>
>This is indeed not a good design. Since the information is not in a "block"
>style. A good design for the above example should be something like:


Hi Yyong,

The problem is that it is not so easy to say, "well sorry, that's bad 
design." As a bit of history, there was a fair amount of argument about what 
features went into XML1.0 itself. Folks argued about what bits to throw out 
and extend (attributes, namespaces, PIs, encodings, etc.) from its mother 
tongue, SGML. In fact, these arguments continue to this day [1] in the form 
of proposals for the next version (2.0) or alternative versions (Simple 
XML). We're fortunate that the arguments about XML 1.0 are over, but we're 
unfortunate in that it is what it is, warts and all! People do use 
attributes in ways that have heterogeneous security requirements.

[1] http://xmlhack.com/read.php?item=116

In the other XML security application <smile> I recall the WG having a 
difficult time trying to come up with the conventions/rules for determining 
when to store a data value in an attribute value or element content [2]. 
While we were concerned with issues of terseness (keep it small in attribute 
values), requirements for nested structures (if it needs to be extended, 
make it an element), and the features provided by attributes such as 
defaults (#FIXED) and attribute typing [3] (ID, IDREF, IDREFS), how things 
would be encrypted was not one of them! This is one of the contributing 
factors to the maxim that we can't expect people to design their schemas to 
our convenience.

[2] http://www.w3.org/Signature/Drafts/xmldsig-ed-conventions-19991019.html
[3] http://www.w3.org/TR/REC-xml#sec-attribute-types

We can make an informed decision balancing application requirements against 
design/implementation complexity. On the issue of application requirements, 
we've had folks argue this is, and is not a requirement. This sort of 
argument doesn't resolve with a satisfying "aha!" because the words can just 
keep going back and forth, but I tend to err on the side of inclusion if a 
chunk of people think it's important. On the issue of complexity, we've had 
folks argue it's unnecessarily complex, and on this issue I tend to err on 
the side of simplicity unless it's demonstrated otherwise. However, to that 
end, Ed's taken the effort to demonstrate that what he wants to do *is* 
possible, which I very much appreciate.

I haven't made up my mind yet, as I'm still learning a lot in this 
discussion. I suspect that if we don't do attribute encryption, when the WG 
starts and represents that in its requirement document and proposal, we'll 
certainly hear from a broader audience about it! 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.) Instead of being two complete 
proposals, something that could be easily plugged in. Sort of like we ended 
up doing with XPath and Signature. This might not be achievable in this 
instance (need to think more) and we might just have to make a hard choice!

With respect to plain text entropy and length, I expect we're going to need 
solutions to these problems regardless.






__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Wednesday, 17 January 2001 18:06:56 UTC