W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2000

RE: Requirements and Goals for the Design of an 'XML Encryption Standard'

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 27 Nov 2000 16:24:38 -0500
Message-Id: <4.3.2.7.2.20001127151354.0354c398@rpcp.mit.edu>
To: "Gerald Huck" <huck@darmstadt.gmd.de>
Cc: <xml-encryption@w3.org>
Resulting changes in:
        http://www.w3.org/2000/11/15-xml-encryption-req.html

At 05:31 11/20/2000 -0500, Gerald Huck wrote:
>In order to avoid non orthogonal design of encryption targets, we prefer
>inclusion of e.g. text nodes (text data) for encryption.
>Having means to define encryption for these items would eliminate the
>need
>to treat element & element content encryption differently. In XPath
>notation
>one could e.g. specify:
>         //foo
>to encrypt all foo elements (with its children/descendants) whereas
>         //foo/node()
>could e.g. be used to encrypt only foo elements' children, or
>         //foo/text()
>could e.g. be used to encrypt only the direct text data children of foo
>elements.

Ok, I'll note your requirement as an alternative to the other that, 
"Granularity is limited to the note-set specified by an XPath expression 
{List: Huck}[Note there concerns that XPath not be required for XML 
Encryption.]"

>Encrypting attributes (name,value) instead of attribute values increases
>security as it can prevent from guessing the values of attributes based on 
>their
>names.

Right, but as started out elsewhere, it also might help prevent attacks 
whereby the attacker sees/knows the same attribute name use repeatedly 
(depending on how the encryption is done).

>The order here is wrong.Wrap the data item in XML, according to a
>generic standard to
>be defined e.g. for representing arbitrary mime-objects. Then encrypt
>these representations.
>Thus, XES must not define the wrapping, but rather should rely on
>existing ones.

So you would be opposed to something like an Object tag in xlmdsig? There an 
encoded bunch of bits with an optional type.

> >From the minutes, we identified that there are proponents and opponents
>for
>adding transformation behavior to encrypted data.
>In our opinions, transformations are useful (and thus should be
>considered) e.g. for
>achieving the following:
>1) redundancy removal
>2) canonicalization (c14n)
>3) Advanced Padding
>4) Checking Authenticity

Ok, I will note these.

> > >R3.5.2   XES SHOULD support additional representations for
> > binary data.
> >
> > Meaning providing ONLY base64 (as the case in dsig) is not sufficient?
>Our opinion here is that it should allow for the binary data
>representations proposed
>by XML-Schema which are 'base64' and 'hex'.

Ok, I will note this.

>No. This is solely the task of an encryption processor to generate
>these ID/IDREF attribute pairs. By choosing these attributes from the
>XES namespace
>they will not be in conflict with any schema related to the original
>data.

Ok, I agree if you are only concerned with the data being well-formed.

>First, there seems to be a misunderstanding. It is not our
>intension to provide special treatment of CDATA (In the above we
>have used PC-DATA as representative for textual data - not structure or
>tagging)

Ok, as I noted before, I'm not capturing specific design from the various 
proposals in the requirements document, so I recommend making your proposal 
independent of the requirement discussion and trying to build support for it.


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Monday, 27 November 2000 16:54:01 GMT

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