Re: XML-Signatures Requirements Last Call

At this point, I think that it is becoming more clear that there will
be different "levels" of conformance with the XNLDSIG standard.

The null canonicalization algorithm has long been required and should
serve the purpose of those who need only perform the primitive
operation of signing immutable binary hunks.

There are vast areas of signing XML objects which will require
something like the canonicalization being produced by the W3C XML
Syntax WG or the canonicalization aspects of the DOM-HASH algorithm.
(And this XML canonicalization will be required whether the signature
is in XML syntax or CMS or whatever.)

See other comments below.

From:  "John Boyer" <jboyer@uwi.com>
To:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Date:  Fri, 20 Aug 1999 14:22:15 -0700
Message-ID:  <NDBBLAOMJKOFPMBCHJOIMENFCAAA.jboyer@uwi.com>
In-Reply-To:  <005b01beeb50$6512e240$6e07a8c0@pbaker-pc.verisign.com>

>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
>Hallam-Baker
>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
>algorithm.

It probably should have said "XML content canonicalization" to be
clearer.

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

Justification has been given elsewhere of the requirement for the
availability of XML canonicalization.  Mandatory implementation is
required for interoperability.  Justification is indeed not provided
in the requirements document but it isn't for other requirements
either.

>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.

Availability of only primitive immutable binary hunk signatures will
result, for a vast range of cases, is some combination of two
outcomes: (1) systems were signature rarely verify due to changes in
the signed object which are insignificant for that application leading
to a choice of non-operation or insecure-operation and (2) ad hoc
application based canonicalization resulting is substantial burdens on
applciation implementers and lack of interoperability.  While some
application specific transformation will be necessary in some cases, I
believe that most of the canonicalization requirements of most
applications can be handled by a tiny number of standard
canonicalization algorithms (including the null algorithm).

>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 reject your attempt to mandate by pure assertion the highly secure
and useless signatures for the vast range of applications that require
non-null canonicalization.  I have posted the IOTP scenario which this
WG is required by its charter to support.  The IOTP specification is
available on line.  Plese prove that practice implementation of IOTP
is possible without canonicalization.

>I propose the following replacement:
>
>3.2 The specification must specify at least one mandatory to implement hash,
>and signature algorithm.

At this point, since we have only one requirements document that does
not distinugish "levels" of conformance to a resulting XMLDSIG
standard, it is probably best to go with vaguer, more general
requirements so we can get this requirements document out and what we
decide later will meet it.  So I do not object to this wording change.
However, I consider it a forgone conclusion that, in order to produce
a usable and interoperable system for signing XML objects for a
variety of applications, we will specify XML canonicalization
algorithms and most likley mandate the implementation of one or two of
them for those that claim conformance to that level of the standard.

Donald

Received on Monday, 23 August 1999 11:48:37 UTC