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

An issue and a typo in Decryption Transform Oct 18th draft

From: Amir Herzberg <AMIR@newgenpay.com>
Date: Wed, 14 Nov 2001 17:40:21 +0200
Message-ID: <078EE8822DCFD411AAA1000629D56ADC162EC4@imp01.newgenpay.com>
To: <imamu@jp.ibm.com>, <maruyama@jp.ibm.com>
Cc: <xml-encryption@w3.org>
Hi, 

First a small typo (in Oct. 18th draft - maybe fixed already): in
section 1.1, `Purpose`, 1st paragraph:
	
	s/Two validate/To validate/

Now to a more substantive issue, which I don't recall having seen
discussed; my apologies if it was discussed and I forgot/missed it, and
for raising it so late. 

The transform currently allows two operations on encrypted data inside
the scope of a reference element: 
-- Decrypt the encrypted data before validating the signature - this is
obviously the only solution to signed-then-encrypted data. 
-- Retain encrypted data as is - this is suggested as the solution to
encrypted-then-signed data. 

Section 6.2 raises valid security concerns with `encrypted then signed`
data. Specifically, it makes the argument that applications... `one MUST
NOT infer that a signature over encrypted data is also a signature over
its plain text form, nor that the meaning of that signature over the
encrypted data also applies to the plain text. `

However, there is another solution: do not _sign_ the encrypted data in
the first place. Namely, the transform could have a third operation
which completely removes encrypted-then-signed elements, e.g. by having
a decrypt:Remove element as another direct child of ds:Transform (in
addition to the decrypt:Except element currently in the spec). 

What are the advantages of decrypt:Remove? 
1. Simpler and less error-prone - why sign something you do not want to
sign and have a big warning the the signature is not meaningful, when in
most applications there is no significant performance penalty to signing
with this ciphertext removed?
2. Avoidance of `chosen plaintext` - one of the problems with signing
encrypted data whch is unknown to the signer is that this may be used by
an attacker to generate signatures over chosen messages, known as
`chosen plaintext` attack, giving the attacker potentially a powerful
attack mechanism. This threat should be added to section 6.2. 
3. Flexibility - by not signing the ciphertext, we allow changes to the
ciphertext. This may be bad (e.g., the signature element will not detect
a corruption to the ciphertext until the message reaches its
destination), so it's important to retain the existing `decrypt:Except`
functionality. However, allowing changes to the ciphertext may also be
beneficial in some scenarios, in particular, when we may want/need to
change the encryption key or method for some reason. Notice that we may
sometimes use two signatures, e.g. a MAC with decrypt:Except (to detect
clogging attempts with corrupted ciphertext) and RSA digital signature
with decrypt:Remove (to have a proper digital signature). Also note that
this may be often complemented by a Reference to the plaintext (often in
Manifest element to allow use of the signature also when the plaintext
is not available(. 
4. Efficiency - in fact, if the length of the encrypted content is
significant, we can even save a bit of processing time by not signing
it. 

Best regards, 
Amir Herzberg
Please use from now my new e-mail: Amir.Herzberg@newmail.net
Received on Wednesday, 14 November 2001 10:40:38 GMT

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