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

Dear Members,

we got some response from the mailing list wrt. our requirements.
Here we want to discuss and clarify issues.

>
> >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?
Partially, yes.
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.
Providing further means to represent sequences of encrypted nodes
atomically
would have the same effect as providing encryption of element content as
basic
feature.

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

> >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?)
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.

>From this perspective, an XES standard may define means to decrypt
externally represented
encrypted data via EncryptionInfo specifications (~DSIG).


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

>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
This can e.g. be achieved via compression techniques. Eliminating
redundancy
decreases the chance of known plain-text attacks - even if the
compression algorithm
is known.
2) canonicalization (c14n)
If schema information can not be preserved (which we think will be the
case) then
canonicalization plays an important role in providing information
preserving
representations, e.g. by explicating implicitly (DTD) defined attributes
and namespaces.
3) Advanced Padding
There definitely exist scenarios where values/content of
attributes/elements will only be
taken from a small set of enumerated items. In such cases the length of
encrypted
data could give a hint to the originally/decrypted value. In order to be
able to address
these attacks, additional padding algorithms should be provided which
can e.g. guarantee
that encrypted data is always represented by a minimal length - and thus
no attacks
can take advantage of the length information.
4) Checking Authenticity
Applying signature algorithm as part of the transformations applied to
encrypted data can
be useful to verify the authenticity of encryted information - and
corresponds to
crypt-sign scenarios.


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

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

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

Agreed. If participating parties know about the encryption
contexts, then this information need not be given.

> >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?
Element, Text, Attibute, List of items, ... - in principle that can
correspond to the Info-Set items.

> >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...?
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)
Validation is not our main concern - thus addressing 1) and 2) is not
the important point
here. Rather, we try to avoid brittleness when partially encrypted
documents
are further modified.
Giving the target location by XPath expressions is often not possible in
a
modification-safe way. Thus, we try to eliminate them and propose
instead
a simple and intuitive in-place decryption behavior for encrypted data.
This approach can guarantee much more stability than an XPath based one.
Changing hierarchy or sequential order of encrypted data can break
XPath based addressing whereas the in-place decryption behavior proposed
by us does not rely on this context.

> >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?
As we noted above, we vote strongly for integrating transformations
within
XES. By defining some of the to be offered by every compliant
implementation
offers a minimal level of interoperability - and addressing them then
requires an
implemntation independent naming scheme, e.g. the namespace/uri based
one proposed in the minutes.
However, for particular applications there should be the possibility to
add new ones as well.
No guarantee can then be given that all processors can treat such
documents meaningfully.
However, fixing the set of available transformations and algorithms in
advance would prevent
use of XES for some application scenarios.

Providing extensibility is therefore a MUST for addressing (unknown)
requirements.

Received on Monday, 20 November 2000 09:28:48 UTC