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

Re: Signing and Encryption

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 31 Jan 2001 12:30:24 -0500
Message-Id: <4.3.2.7.2.20010131113309.0205aef8@rpcp.mit.edu>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: "Joseph Ashwood" <jashwood@arcot.com>, <xml-encryption@w3.org>, hal@finney.org
In http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0087.html
At 16:07 1/26/2001 +0900, Takeshi Imamura wrote:
>data will make signature invalid, but to recover the signature, we
>introduce EncryptedReference element.  The element can be used as follows
>(I wrote before that the element may appear within ds:SignaturePropery
>element, but I changed my mind ...).

Hi Takeshi, I didn't realize that EncryptedReference in the recent proposal 
[1] is supposed to be used as part of a transform in a Signature. I know 
there's been similar proposals (of NoDecrypt in SignatureProperty), but 
looking at in light of your example, this seems like a good candidate.

[1] 
http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html#_Toc501424249

I've tried to run the proposal past my little checklist of problems <smile>:

1. Does it prevent subsequent encryption for fear of invalidating the 
Signature?

No, others can encrypt all they want and the Signature application will 
still know exactly which bits it must leave encrypted and decrypted (decrypt 
everything but the exception) so as to obtain the original document for 
validation.


2. Does it leave signature data available to aid plain text guessing attacks?

You've encrypted the SignatureValue (enc3) to help prevent an attack on 
(enc2), however, it's the DigestValue that has the information that will be 
useful to you in attacking (enc2), right?


3. What does this offer over the simple rule of when you encrypt an element, 
encrypt any Signature's over that element?

It improves on the two problems discussed in?
http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0081.html


3.a Detached Signatures

As far as I can see this works. It's not relying upon any element nesting to 
represent an ordered operation. If the Signature is detached, it should 
still be chased and portions encrypted so as to not leak information.

3.b Problem of "Alice Encrypts element A and the Signature over the parent 
of A. Bob Encrypts element B (sibling of A) but *not* the Signature since he 
doesn't know about it. Alice then decrypts A and it's Signature, providing 
information to a subsequent plain text attack."

Given that most of the Signature is still available, Bob can still see that 
there's a Signature about the content he just encrypted. However, if he 
encrypts SignatureValue, Alice might not realize she must ask him to decrypt 
first in order to restore the document.

However, if you encrypt the DigestValues (instead of the SignatureValue), 
would this offer anything?


4. Semantics

My concern with some proposals is they slid in an implicit processing 
behavior of Signature, which isn't in that spec.

In this case, the "decrypt everything but these" transform is very nice. If 
a signer who isn't encryption aware doesn't use that EncryptedReference, and 
someone subsequently encrypts, the signature will be broken, but that's ok, 
that's as it should be as Joseph points out. However, your proposal also 
means that if it uses this *explicit* transform, subsequent encryption can 
be reversed.

__
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 Wednesday, 31 January 2001 12:30:55 GMT

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