W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2000

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

From: <priewe@darmstadt.gmd.de>
Date: Mon, 20 Nov 2000 21:37:58 +0100
To: xml-encryption@w3.org
Cc: reagle@w3.org, geuer-pollmann@nue.et-inf.uni-siegen.de
Message-ID: <OF568F11FA.E084612E-ONC125699D.00368F60@gmx.net>
>>Wouldn't transforms make sense? At the workshop, there was the 
diecussion 
>>about c14n and compression, which read (if I understood it right):
>>
>>* If you want to c14n you instances before encryption - do so!
>
>There is a desire that c14n not change the Infoset of the encrypted XML, 
yes 
>the serialization might be a little different after decryption but that 
>doesn't matter as it does in Signature. I think the question of whether 
>Canonical XML meets this desire is still ~slightly~ open (schema and 
>internal subset issues), but I think it's in everyone interest for this 
not 
>to be the case (and if Canonical XML doesn't provide this a priori for 
all 
>XML instances, if you construct your XML instance appropriately, it 
will.)
>
>>* If you want to compress you instances before encryption - do so!
>
>People didn't seem keen on compression.
Maybe we should use the term "redundancy removal" instead of compression.
This should be possible to harden encrypted docs against known-plaintext 
attacks.
How this is technically achieved should be considered later.
But it may be achieved via compression.

According to the meeting minutes there mainly seem to be legal 
considerations 
against compression. Aren't there any patent free compression algorithms?
We think on gzip or bzip that are published under GNU license.

>
>>but how do we indicate what we did if we don't have a list of 
>>transformations? This would make the "compression or not" discussion 
>>obsolete, because the application could choose.
>
>I was just asking really. I haven't seen a super strong use case on one 
>hand, but on the other hand most of the work is already done by Signature 

>(but do we still want to include transform capability in this spec?)
We recommend that transforms should be included in this spec for two 
reasons:
1) Encryption and Signature require different transforms (like length 
hiding/padding,
   redundancy removal/compression)
2) The transforms in Signature and Encryption are processed differently.
   The transforms in signature must be applied in the same order
   by the signer and the verifier to work properly.
   For encryption they must be applied in reverse order.
   So this spec must specify how to process transforms for 
encryption/decryption.


Best regards,
Gerald Huck                       Arne Priewe

IPSI - OASYS                      Student of Computer Science at the
GMD Darmstadt                     University of Frankfurt
Germany                           Germany
E-mail: huck@darmstadt.gmd.de     E-mail: priewe@darmstadt.gmd.de
Received on Monday, 20 November 2000 16:01:44 GMT

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