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

Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

From: Tom Gindin <tgindin@us.ibm.com>
Date: Tue, 2 Apr 2002 13:11:11 -0500
To: merlin <merlin@baltimore.ie>
Cc: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>, Karel Wouters <Karel.Wouters@esat.kuleuven.ac.be>, Aleksey Sanin <aleksey@aleksey.com>, xml-encryption@w3.org
Message-ID: <OF4759ED90.C45554FF-ON85256B8F.006330B4@pok.ibm.com>

      Actually, there are two RSA signature schemes (1.5 and PSS) and only
the older one works in the way you describe.  The newer one, which is still
in draft, uses "mask generation functions" inside the signature, so if you
verify the signature with the wrong hash function it should break.

            Tom Gindin

merlin <merlin@baltimore.ie>@w3.org on 04/02/2002 10:59:25 AM

Sent by:    xml-encryption-request@w3.org

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
Subject:    Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

[ I believe I mis-sent the last copy of this. ]

The attack is to break a message digest algorithm, and to replace the
signed data with text indicating that the broken digest is to be used,
such that the new signed data under the broken message digest algorithm
has the same hash as the original signed data under the original message
digest algorithm. If the digest algorithm isn't in the signed text, just
change its setting in the appropriate place; possibly the application's
configuration file.

This isn't practical against DSA because its use of SHA-1 is currently

Under RSA, the solution (that we also inherit) is to include the signature
OID within the RSA ciphertext. The attacker cannot replace this instance
of the algorithm specifier, and so this attack will be readily apparent.

Given our current signature algorithm support, SignatureMethod may safely
be omitted. However, the dsig spec is beyond change so a discussion to
make it optional is somewhat fruitless.

Personally, I don't see the benefit of the optionality of these
algorithm identifiers. It doesn't seriously save much space, it doesn't
add security, it makes the long-term durability of documents much more
fragile, and it makes it more difficult to design a friendly API that
exposes the full capabilities of the specification.


>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
>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
>> 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
>> 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
>>> I would prefer the second (both optional) since application can have
>>> information from the context.
>>> Aleksey Sanin <aleksey@aleksey.com>
>>> http://www.aleksey.com/xmlsec


Baltimore Technologies plc will not be liable for direct,  special,
or consequential  damages  arising  from  alteration of  the contents of
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 13:12:58 UTC

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