Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.04.02/15:39:21
>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.
>
>Regards,
>Christian
>
>--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.
   http://www.baltimore.com

Received on Tuesday, 2 April 2002 10:56:25 UTC