W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2002

Re: Comments on the XML Encryption Requirements

From: Rich Salz <rsalz@datapower.com>
Date: Thu, 17 Oct 2002 11:25:20 -0400
Message-ID: <3DAED660.2010209@datapower.com>
To: reagle@w3.org
Cc: XML Encryption <xml-encryption@w3.org>, ross@contivo.com

I found your note very interesting.  Serendipitously, the infoset/byte 
"conflict" has just been coming to the forefront in SOAP/DSIG.  I should 
clarify that while I have much experience here, I am not a member of the 

It seems to me there are two major issues.  The second one is easier to 
deal with:  does it make sense to try validate a partially-encrypted 
document.  I am strongly in favor of saying that this is not a 
requirement on XML-Enc.  This issue should be addressed by adding text 
to the spec.

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

The second issue (the first one you bring up) is more complicated, but I 
believe that -- for now -- it has a similar simple answer.  Cryptography 
is based on byte-streams.  Interoperable cryptography requires everyone 
to have the same serialization mechanism. Fortunatately, XML *is defined 
as* a serialization mechanism. :)  Until there is a standard way to 
render the infoset (or more accurately here, the PSVI), "encrypt the 
infoset" is just plain impossible.  Not hard or infeasible.  Impossible.

If you accept that encryption (and signature, although to a lesser 
extent) implies and/or requires serialization, then I believe most of 
your issues and message text become moot.  I recognize that this is not 
optimal from a schema viewpoint, nor as flexible, but the goddess of 
crypto must be fed bytes.

At this point, I am beginning to think that infoset/serialization is an 
issue for the TAG to consider.

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

Don't the EncryptedData, et al, types provide this?

> children of the_corn are encrypted.


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

Perhaps the spec should make it explicit, but I'd argue "well, duh!" :)
Received on Thursday, 17 October 2002 11:28:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:10 UTC