RE: encryption in XML & in SMIME

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
-----Original Message-----
From: Don Davis [mailto:dtd@world.std.com]
Sent: Thursday, September 21, 2000 11:29 PM
To: Ed Simon
Cc: xml-encryption@w3.org
Subject: RE: encryption in XML & in SMIME



ed simon wrote:
>>> To avoid the second signing, one could (as you suggest) include
>>> the <From> element as input to the digest of the message to be
>>> encrypted.  This could be done using XML Signature's Transform
>>> facility.

i wrote:
>> i'm disappointed that the double-hash signature
>> doesn't work.  it seemed to be a good alternative
>> solution, for applications that don't want to put
>> names inside the message-body.

ed simon replied:
> The double hash solution (with the Transform fix) is
> quite feasible for our XML e-mail with XML Signature
> scenario. (Transforms are an integral part of XML
> Signatures).  Note: that the Transform does not force
> the sender name to be part of the message, it just makes
> the digest be calculated over both the sender's identity
> and the pre-encrypted message.

hi, ed --

if you apply a Transform that incorporates
the sender's identity into the ciphertext,
then you don't need the double-hash.  the
Transform fixes the "unauthenticated encryptor"
problem handily, and the double-hash adds no
security at all.  as long as the sender's
identity contributes to the ciphertext, it's
sufficient to just sign the ciphertext,
without signing the plaintext, too.

				- don davis, boston



-

Received on Friday, 22 September 2000 09:45:45 UTC