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

RE: XML-Signatures Requirements Last Call

From: John Boyer <jboyer@uwi.com>
Date: Fri, 20 Aug 1999 14:22:15 -0700
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Dovetailing on Phill's point, it was my understanding that 'null' c14n would
be one of the possibilities.  It is necessary that the null c14n be
mandatory due to the vast number of people who will want to create
signatures of level 0 compliance while also sticking to the original format
of the data being signed (the bits on the wire, as Phill puts it).

If this is true, then choosing the null c14n as the required c14n would seem
to solve the problem.  If this is not what you meant, then you should
probably change the requirement to say "two c14n algorithms" (null and
whatever else you had in mind).

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Phillip M
Sent: Friday, August 20, 1999 2:10 PM
To: Joseph M. Reagle Jr.; chairs@w3.org
Cc: IETF/W3C XML-DSig WG; w3c-xml-plenary@w3.org; Donald E. Eastlake
3rd; Jon Bosak
Subject: RE: XML-Signatures Requirements Last Call

I object to the following requirement:

3.2 The specification must specify at least one mandatory to implement
signature canonicalization, content canonicalization, hash, and signature

No justification is provided for requirng mandatory implementation of a
canonicalization algorithm. A canonicalization algorithm is not required
to create a signature.

The simplest implementation of a signature verifier is to validate the
hash of the bits on the wire.

The simplest implementation is desired because it is the least likely
to have errors.

A canonicalization algorithm introduces potential ambiguity into the
bit-stream presented and is therefore a security risk. If an application
is presented with a bit stream which does not validate it MUST be
permitted to reject the signature. It MUST NOT be required to manipulate
the data to make the signature verify.

I propose the following replacement:

3.2 The specification must specify at least one mandatory to implement hash,
and signature algorithm.
Received on Friday, 20 August 1999 17:23:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:31 UTC