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: Thu, 09 Nov 2000 18:18:56 -0500
Message-Id: <4.3.2.7.2.20001109175313.02982f08@rpcp.mit.edu>
To: "Gerald Huck" <huck@darmstadt.gmd.de>
Cc: <xml-encryption@w3.org>
At 04:53 11/3/2000 -0500, Gerald Huck wrote:
>Dear Members of the W3C encryption mailing list,
>
>after following the ongoing discussions for a while,
>this e-mail intends to identify and discuss important
>requirements and goals for the design of an
>'XML Encryption Standard' from our point of view.

Hi Gerald and Huck,

I looked carefully at your document, nice job! I'm just catching up from the 
workshop last week [1] and much of that discussion and some of the actions 
are relevant to your discussion. Beginning of next week (tomorrow's an MIT 
holiday) I want to revisit the requirements document. What I'll try to do is 
take what I learned from the workshop, the continued discussion and your 
document and integrate it all in. Then if I miss anything you (and others) 
should propose further additions/clarifications.

Hopefully we'll have a decent REQ document then. In my experience of writing 
these things frequently people think that many of the requirements are too 
obvious or it doesn't make sense! <smile> But after a while it focused on 
those things that are needed for scope and direction so as to mitigate 
contention. To that end, I have some questions on yours [2]

[1] http://www.w3.org/2000/11/02-xml-encryption-ws/minutes.html
[2] 
http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/att-0004/01-enc-requirements_2000-10-31.html

>R2.1.1                XES MUST support encrypted representation of
>-          Elements (Each element with its attributes and content)
>-          Text Data (PC-DATA/CDATA at direct child level)
>-          Attributes (name and value of an attribute)
>These represent the basic building blocks of an XML-Document. However, 
>there exist additional levels of granularity and data within an 
>XML-Document which could be target of encryption:
>R2.1.2   XES SHOULD support encrypted representations of
>-          Attribute values
>-          Whole XML Documents (?)
>-          Processing-Instructions, comments, entities (???)

I'm not sure this must/should distinction is material as it affects the 
processing and data model. From the Workshop there's a strong sentiment to 
limit the scope to element, element content, and maybe attribute values. Are 
you advocating otherwise?

>R2.2    XES MAY provide for encrypted representations of non XML data
>
>These can e.g. comprise MIME-objects. However, XES should assume the 
>existence of standardized XML representations for these, applying its 
>standard XML-encryption to them. IT MUST-NOT be the scope of XES to define 
>such XML representations.

Does this mean separate data objects, and consequently mean that we'll need 
at least one XML root element to wrap things that were previously non-XML 
data. (So take a PDF, encrypt, base64, then stick in a content carrier 
element?)

>R3.4.1                XES MUST define a uniform naming scheme for 
>serialization/transformation/encryption algorithms

What does this mean? I don't _think_ we've identified a desire to create a 
transformation process like that in Signature. Also what do you mean by 
transformations?

>R3.5.2   XES SHOULD support additional representations for binary data.

Meaning providing ONLY base64 (as the case in dsig) is not sufficient?

>R3.7    XEL SHOULD allow for separation of encryption information from 
>encrypted data, and support stable reference mechanisms for addressing 
>encryption information from encrypted data sections.
>
>For various reasons (document modifications), XPath based references do not 
>fulfil such stability criteria, whereas ID/IDREF attribute based approaches 
>offer better stability.

However, this requires that the schema author provides those attributes. 
If  not, then that content can't be encrypted.

>R3.8.3   Plain-text encryption information MUST comprise:
>-          key-information and key-method which are needed to obtain a 
>valid decryption key
>-          encryption algorithm and (optionally) its initialization 
>parameters

This will likely be optional as it is in dsig.

>R3.8.4   Encryption Information for which encryption MUST be possible:
>-          the type of XML data encrypted
>-          chosen serialization and transformation algorithms

What do you mean by type of XML data?

>R4.3    XES MUST define the location/position of decrypted data.
>
>We propose here also a scheme which eliminates the need for XPath 
>expressions identifying the target location. Instead, encrypted 
>representations of elements or PC-DATA should obey a simple replace 
>semantic, i.e. they will exactly be placed at the location where the 
>encrypted data was positioned before.
>
>Changing the context (either by moving the XEL representation or defining a 
>new parent) will then have the same effect as for the corresponding 
>plain-text representation.

This approach is interesting. Instead of relying upon XPath, you continue 
under the schema of replacing CDATA with the encoded data. In instances 
where you need to include elements in the CDATA, you encode it. You might 
want to send this as a separate proposal to the list. My two initial 
concerns with this is that:
1. In those instances where you want to preserve validity (this is a 
subset), it seems counter-intuitive to be hiding XML (via encoding) to 
preserve the validity of a document given,
2. At the workshop Simon pointed out in schema validated instances, there is 
very little real CDATA as even most string like data will be typed, and 
replacing even that will break schema validity.

However, I suspect to you aren't doing this for validity; instead you want 
to remove external EncryptionInfo/Data references and their need of XPath...?

>R5.1    XES MUST predefine a set of key-identification and key-management 
>methods to be supported by a compliant processor.
>This minimal set could e.g. comprise: Standardized key identification (e.g. 
>from X509), Key agreement (e.g. X9.42),  in band Key transport (e.g. RSA), 
>out of band Key transport (e.g. 3DES)

Jim Schaad has an action to send a list of candidate algorithms for 
discussion.

>R5.6    XES MUST facilitate integration and usage of additional key 
>encryption algorithms.
>R5.7    XES MUST predefine a set of serialization/transformation algorithms
>These algorithms address environmental needs, e.g. arising from 
>XML-Signature, by allowing the definition of additional transformations to 
>be applied to XML-Data before encryption takes place, e.g. normalization or 
>compression.

What does this mean?


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Thursday, 9 November 2000 18:19:02 GMT

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