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

Resulting changes in:

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
>to treat element & element content encryption differently. In XPath
>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

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 

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

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
>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

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

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      
IETF/W3C XML-Signature Co-Chair

Received on Monday, 27 November 2000 16:54:01 UTC