RE: encryption in XML & in SMIME

Perhaps I misunderstand but it seems like you are suggesting
the two transforms need not always be applied sequentially.
Indeed, the XML Signature spec requires that all the specified 
transforms be applied sequentially when either signing or
verifying.

Regarding the statement "but this requires
the creation and specification of this new "double hash"
mechanism, which isn't particularly necessary for any
security purpose besides your e-mail application".

Actually, XML Signature is designed exactly so that one signature
can cover one or two or more hashes precisely because there
is a lot of need for this functionality.  For example, to sign
a Web page, you would want to sign not just the main HTML or XML
page but also any imbedded pages (eg. FRAMEs), images, stylesheets,
etc.  With XML Signature, each component is hashed, the hashes are
listed, the list is then hashed, and that super hash is then signed.

Ed

-----Original Message-----
From: Don Davis [mailto:dtd@world.std.com]
Sent: Friday, September 22, 2000 4:21 PM
To: Ed Simon
Cc: xml-encryption@w3.org
Subject: RE: encryption in XML & in SMIME


ed simon wrote:
>>>> one could... include the <From> element as input to the
>>>> digest of the message to be encrypted... using XML
>>>> Signature's Transform facility.

ed simon continued:
>>> the Transform... just makes the digest be calculated over
>>> both the sender's identity and the pre-encrypted message.

i replied:
>> the Transform fixes the "unauthenticated encryptor" problem
>> handily, [but] the double-hash adds no security at all.

ed simon replied:
> such a hash could be useful for system elements that need
> to verify the <From> field without decrypting the message.

hi, ed --

i think then that your Transform should be applied twice,
to incorporate the <From> element:
	1. with the plaintext,  as input to the encryption;
	2. with the ciphertext, as input to the signature.

in this version, no double-hash is necessary.  the blocker
and the recipient both apply the second Transform, so as
to verify the signature without seeing the plaintext.  when
the recipient decrypts the ciphertext, he sees the first
Transform's <From> element, compares this to the signed
external <From> element, and if they match, he concludes
that the message was not surreptitiously forwarded.

you could instead use the Transform to prepare two hashes
as above, and then sign the hashes.  but this requires
the creation and specification of this new "double hash"
mechanism, which isn't particularly necessary for any
security purpose besides your e-mail application.
i'm sure still other mechanisms can achieve the same goals
for email, but i just want to show that the double-hash
signature, despite its elegance, isn't really necessary
in this case.

also, please note that double-hashing is simplest when one
uses RSA to calculate signatures, because then one can put
the two 100+ bit hashes side-by-side into the 500+ bit RSA
input buffer.  for DSA signatures, it's not so simple,
because DSA uses a 160-bit input, which is too small for
two SHA-1 hashes concatenated together.  an extra hashing
step could solve this DSA problem, but of course the extra
step mars the elegance of double-hashing.

				- don davis, boston



--------------------------------------------------------------

At 9:39 AM -0400 9/22/00, Ed Simon wrote:
>You are right that the hash over the entire <EMail> does not
>add to securing wrt the "unauthenticated encryptor".
>
>However, I think such a hash could be useful for system
>elements that need to verify the <From> field without
>decrypting the message.  I am thinking, for example, of
>a module for blocking certain senders that wants to have
>the <From> field signed (and verifiable without having to
>read the message) so that it can block the kind of faked
>sender emails we discussed way back in August; the type
>where receiver B has blocked sender C so sender C creates
>an e-mail field to look like the sender is really A.
>(Note:  Requiring the blocker to be able to read the message
>simply to verify the sender could be a security loophole
>in itself.  The double-hash overcomes this.)
>
>Does the above example seem to be a plausible reason for
>having a double hash?  I ask this as someone who is not
>an email expert.
>
>Ed



-

Received on Friday, 22 September 2000 16:10:43 UTC