Re: Comments on the XML Encryption Requirements

On Wednesday 16 October 2002 06:44 pm, Ross Thompson wrote:
> Greatings, encryption folk!

Hi Ross, thank you for your comments. (BTW: I redirected your original 
comments to the list, but note that your response to Rich did not make it 
through. This list moved just moved to the new W3C archive approval system 
[1], so I hope they'll come through after you give approval ... (?) ).

[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Oct/0002.html

> XML Schema working group has reviewed the XML Encryption Requirements
> document.  I have been asked to send you the following comments.
> Please feel free to forward any questions of clarity or intent back to
> me.

Just to share some context and expectations, the XENC specifications are now 
in PR. So while these comments on our last call from 12 months ago are 
welcome, the threshold of "entanglement" <smile/> is *extremely* high as 
Michael agreed to [2]. (Not that I think any substantive change or 
entanglement follows from your email!)

[2] http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0041.html

> Virtually all of the issues mentioned below arise because of this
> level mixing.  The Schema working group has, from time to time,
> considered the viability of co-occurrence constraints, which might be
> used to alleviate some of the problems, but Schema has no immediate
> plans to include such constraints.  We also discussed the possibility
> of using complex type unions to address some of the concerns, but we
> similarly have no immediate plans to introduce such types.

Indeed, I would like to see operational experience and pragmatic solutions 
to resulting problems proposed and used before I'd advocate a complex 
requirement on future versions of schema.

> Finally, substep 1 of step 3 of the encryption processing rules
> (listed in section 4.1) specifies the encryption of character strings.
> Would it be better to sign or encrypt pieces of the infoset?

As Rich points out, encryption works on octets/bits which typically 
represent characters. You need *something* to serialize as an input into 
the encryption algorithm. XENC is design to support the encryption of 
serliazations of arbitrary resources, we provide REQUIRED mechanisms for 
XML 1.0 element and element content as described in [3]. (As an aside, 
Christian has proposed his own DOM/Infoset based "pool" encryption [4].)

[3] http://lists.w3.org/Archives/Public/xml-encryption/2002May/0076
[4] 
http://www.nue.et-inf.uni-siegen.de/~geuer-pollmann/publications/xmlEncryptionWS-2000-11-02/all.htm

> To amplify this point, consider the following two cases:
>
>     1) Infosets may exist for which no XML serialization is ever
>     created.  Consider a document created through a DOM, stored in an
>     XML database that uses optimized internal representations of the
>     Infoset.

Yes, as stated in [4], "The octects could be anything, a serialized 
representatin of a Infoset item, a pickled python DOM node, compressed 
data, etc." In version 1.0, we specify what to do for element and element 
content, though future extensions/versions could do more.

>     This says that there is a strong requirement that no application
>     ever change namespace prefixes on a document with encrypted
>     elements.  We find this to be worthy of a very salient warning to
>     users and implementors, at the very least.  

I've included a more specific bit of text in section 1.2 to note that 
discussions regarding instance processing and validity are in the 
requirements document.

http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-Design
  The design philosophy and requirements of this specification 
  /+(including the limitations related to schema validation)+/ are
  addressed in the XML Encryption Requirements [EncReq].

We could  more text on this note if proposed.

> These two points together argue strongly that it is the contents of
> the infoset that should be signed, and not the serialization of the
> infoset.

As Rich mentions, we still need a serialization, the trick is that we would 
first need a non-ambigous and non-lossy serialization format for Infoset.

> - If the XML processor does not know the decryption keys, then the XML
>   infoset will contain the elements that represented the data in its
>   encrypted form.  In this case, there are severe limitations on
>   schema validation, because as far as validation is concerned, the
>   encryption elements have no special status.  In particular:

Correct. Your points are similar to those that we documented in our 
requirements document [5]. This document is somewhat dated -- we've clearly 
decided to take an XML 1.0 based approach, and limit ourselves to element 
and element content -- but capturesthat we were only constrained to produce 
well-formed XML, and that applications could take a few different 
approaches (including a pre *and* post encrypted schema). 

[5] http://www.w3.org/TR/xml-encryption-req#sec-Processing


> A possible approach to resolving this problem, which Schema would
> encourage you to consider, is to specify not a specific element, but a
> complex type of encrypted data.  This would allow the schema author to
> specify element X and an encrypted form of X as alternatives.  So, the
> original schema might be rewritten thus:

This is an interesting approach however this would require XML Encryption 
applications to be schema processors. This might be the case in future 
versions, but not the present one.

> (It was observed in discussing this proposal that developers of
> encryption processors may prefer an element, which they could be
> guaranteed of recognizing by its QName

As we do now.

> to a type, which would require
> them to use a schema processor upstream.  One solution to this dilemma
> might be to specify a required attribute with a fixed value as part of
> the complex type (so that elements of types husk-enc, say, was
> required to have the attribute value specification
> enc:EncryptedData="...").  The value of the attribute, could be a
> boolean, or a version number, or information about the key, or a
> public key, or whathaveyou.)

Yes, this should be considered by a future version of XENC that is 
Infoset/Schema based.

> (Another observation made during the discussion: An agent in posession
> of a schema for the plaintext document will be able to infer
> information about what tags are encoded.  If a schema calls for
> elements A, B, and C, in order, and the instance document contains A,
> B, and an EncryptedData tag, it is fairly obvious what tag has been
> encrypted.  This could, perhaps, facilitate some decryption attacks,
> because it gives the attacker knowledge of some of the plaintext.  In
> particular, it is very likely that the text begins with "<C" and ends
> with "</C>".  We recommend a note for implementors and users of XML
> Encryption that warns them of this.)

Yes, as we state in the requirements [5], "(i.e. applications that encrypt 
the element structure are purposefully hiding that structure." and the spec 
[6] "Given that XML data is redundant (e.g., Unicode encodings and repeated 
tags ) and that attackers may know the data's structure (e.g., DTDs and 
schemas) encryption algorithms must be carefully implemented and used in 
this regard."

[6] http://www.w3.org/TR/2002/PR-xmlenc-core-20021003/#sec-Nonce

> If the places where the encryption can appear in the instance document
> is fairly small, then doctoring the schema as above is practical,
> though perhaps painful.  If it is not small, then it is really
> impractical, which in turn means that validation of documents
> containing encrypted content is not practical for a processor that
> does not have access to the decryption keys.

Yes, as we captured in the requirements, we are going to rely upon 
operational experience to guide future work with respect to how folks fit 
encryption into their larger XML processing pipeline.

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

Received on Thursday, 17 October 2002 14:15:12 UTC