W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2002

Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

From: merlin <merlin@baltimore.ie>
Date: Tue, 02 Apr 2002 16:56:17 +0100
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: Karel Wouters <Karel.Wouters@esat.kuleuven.ac.be>, Aleksey Sanin <aleksey@aleksey.com>, xml-encryption@w3.org
Message-Id: <20020402155617.1889043BEA@yog-sothoth.ie.baltimore.com>
>Hi Karel,
>but this attack is always possible, isn't it? If the verifying application 
>allows (accepts) weak signature methods, an attacker can change the 
>ds:SignatureMethod/@Algorithm value and the ds:SignatureValue . This attack 
>does not depend on whether the SignatureMethod is optional or not.
>Or am I completely on the wrong track.
>--On Dienstag, 2. April 2002 16:00 +0200 Karel Wouters 
><Karel.Wouters@esat.kuleuven.ac.be> wrote:
>> Hi,
>> I think that SignatureMethod in ds:SignedInfo should be present in
>> each signature, because it restricts the attacker:
>> If I leave out SignatureMethod, the attacker might be able to come up with
>> a weaker SignatureMethod, tamper with the references and claim that the
>> signature was produced with this method.
>> RSA with a weak hash algorithm would suffice.
>> (actually, he might produce 'any' signature if the hash function is weak
>> enough)
>> So specifying the SignatureMethod ensures the verifier that this signature
>> is generated with a solid technique.
>> (mailinglist, correct me if I'm wrong)
>> Karel.
>> On Mon, 1 Apr 2002, Aleksey Sanin wrote:
>>> Sorry for mistype, actually Imeant SignatureMethod in XMLDSig:
>>> A minor issue but probably it's worth to fix it: the EncryptionMethod
>>> in XMLEncryption and SignatureMethod in XMLDSig both have the same
>>> meaning: algorithm selection. However, EncryptionMethod is *optional*
>>> element and SignatureMethod is *required*. From my point of view it is
>>> inconsistent. Either both should be required or both should be optional.
>>> I would prefer the second (both optional) since application can have this
>>> information from the context.
>>> Aleksey Sanin <aleksey@aleksey.com>
>>> http://www.aleksey.com/xmlsec

Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Received on Tuesday, 2 April 2002 10:56:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC