W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

RE: Minutes from Today's Call Please Review/Correct

From: Phillip M Hallam-Baker <pbaker@verisign.com>
Date: Tue, 24 Aug 1999 13:31:33 -0400
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Message-ID: <002c01beee56$82b2b2e0$6e07a8c0@pbaker-pc.verisign.com>

> Acknowledged: there is no requirement to use c14n for signature generation
> -- we can finish the discussion on the signature itself next week.
> Questioned: even if not, is there an requirement that Signature
> applications
> have a normative c14n algorithm handy in case the sender uses it?
> Philllip,
> are you opposed to using it in your signature generation and/or having to
> implement it regardless?

I am opposed to introducing the possibility of a downgrade or
algorithm substitution attack.

If applications are required to support FOO and a security loophole
is found in FOO an attacker can always choose to use FOO to make an

The argument applies to crypto algorithms as well which is why
PKCS#1 binds RSA to the hash algorithm used to prevent a
substitution attack.

Although similar arguments can be made with respect to crypto
algorithms the analogy is not really valid. IDENTITY is not a
genuine option as a cipher. [*]

Also I do not see a direct comparison between mandating DSA and
SHA-1 and mandating DOM-HASH (or its ilk). The former standards
are independently defined and have many years of scrutiny by the
security community behind them. No C14n algorithm this group
defines will meet that standard.


[* Yes, I know it is now mandatory to implement NULL in IPSEC but
that is for TESTING]
Received on Tuesday, 24 August 1999 13:30:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC