RE: Signing encrypted data

Let me expand my original note so that the meaning is clearer...



Though Joseph's shorthand is appropriate, I just want to remind everyone 
that one can just encrypt the content of the <DigestValue> elements in the
XML 
Signature rather than encrypting the whole <Signature> element. Doing so,
allows 
applications to see the signature and see what has been signed in addition
to
other signature details. 

Encrypting the content of the <DigestValue> elements may be done BEFORE
or AFTER calculating the content of the 
<SignatureValue> element. If one did choose to encrypt the content 
of the <DigestValue> element AFTER calculating the signature value over
the <SignedInfo> element, it becomes necessary to encrypt the resultant
content 
of the <SignatureValue> element to ward off the attack being discussed. If
one
encrypts the content of the <DigestValue> elements BEFORE calculating the
hash
of the <SignedInfo> element, then the signature value does not need to be
encrypted.

Yet another possiblity (which may be regarded as bizarre by some but I'll
detail for fun) is to:
1) Calculate digests D1...Dn.
2) Create <Reference> elements for D1...Dn in which the content of the
<DigestValue> elements are UNENCRYPTED digests.
3) Encrypt digests D1...Dn to get E1(D1)...E1(Dn).
4) Create <Reference> elements for E1(D1)...E1(Dn) in which the content of
the <DigestValue> elements are the ENCRYPTED digests (wrapped in
<EncryptedData> elements of course).
5) Create the <Manifest> (optional) and/or <SignedInfo> elements which
encompass all the <Reference> elements created above.
6) Digest and sign the <SignedInfo> element to create the content of the
<SignatureValue> element.
7) Now, encrypt the content of the <DigestValue> elements created in step 2
to get E2(D1)...E2(Dn).  Note that one can choose different encryption
details than one used in step 3 so that is why I've used E2 rather than E1
in my notation; E2, of course, may be equal to E1.

Amir wrote:
BTW: why can't you encrypt the whole <Signature> element, if verification
requires decryption capability anyway?

I reply: I'm not saying you can't do as you suggest, I just suggesting
possible approaches that <b>might</b> be worth pondering.  For example, by
not encrypting the whole <Signature> element, even if an app cannot verify
the signature it can note that something was signed, what was signed, and
how it was signed; that info may be valuable or it may not, that entirely
depends on your specific app. The wonderful thing about XML Signature and
XML Encryption is that it is very flexible in ways that simply were not
possible with CMS and PKCS7.  Frankly, I'm also using this thread as an
opportunity to encourage thinking outside the pre-XML cryptography box.

Ultimately, the decision on the best way to apply XML Signature and XML
Encryption to a particular application requires direct familiarity with that
application.  The important thing is to be confident you have not missed any
potentially valuable approaches to the problem.

Ed

 -----Original Message-----
From: Amir Herzberg [mailto:AMIR@newgenpay.com]
Sent: Thursday, March 22, 2001 6:19 AM
To: xml-encryption@w3.org
Subject: RE: Signing encrypted data



Re Ed's messsage below...
 

Providing an plaintext <SignatureValue> computed over the plaintext
<DigestValue> may allow a guessing attack, if no encrypted randomization is
used, against a low-entropy message. Therefore, one should either:
 
-- Encrypt both <SignatureValue> and <DigestValue> 
-- If the signature should be verifiable by entities without access to the
plaintext (& decryption key): sign (and digest) the ciphertext, not
plaintext. If furthermore a signature is needed also on the plaintext (e.g.
for non-repudiation), use an appropriate secure (non-revealing) commitment. 
 
The second option is what I'm interested in as it is needed for e-commerce
(and in particular e-payments) applications.
 
BTW: why can't you encrypt the whole <Signature> element, if verification
requires decryption capability anyway?
 
Best regards,
Amir Herzberg
CTO, NewGenPay Inc. 

See our demo and overview/tutorials on secure e-commerce in
http://www.NewGenPay.com <http://www.newgenpay.com/>  

-----Original Message-----
From: Ed Simon [mailto:ed.simon@entrust.com]
Sent: Wednesday, March 21, 2001 7:03 PM
To: xml-encryption@w3.org
Subject: RE: Signing encrypted data



Though Joseph's shorthand is appropriate, I just want to remind everyone 
that just encrypt the content of the <DigestValue> elements in the XML 
Signature rather than encrypting the whole <Signature> element. 

This may be done before or after calculating the content of the 
<SignatureValue> element. If one did choose to encrypt the content 
of the <DigestValue> element AFTER calculating the signature value, 
I think it may then be necessary to encrypt the resultant content 
of the <SignatureValue> element to ward off the attack being discussed. 

Ed