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

RE: ID/DTD/c14n/dsig mischief?

From: John Boyer <JBoyer@PureEdge.com>
Date: Thu, 12 Jul 2001 10:34:39 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B520C341F@tigger.PureEdge.com>
To: "Thomas Maslen" <maslen@dstc.edu.au>, <w3c-ietf-xmldsig@w3.org>


Hi Thomas,

Fabulous work.  Hasn't been done to death and is quite original.  A
beautiful example of the dangers inherent in being forced to accept the
limitations of 'existing technology'.

My immediate reaction to any omission of data is 'document closure',
i.e. if an article of data is necessary to the interpretation of a
document, then don't omit it.  It often happens that only the
application designer is capable of fully assessing this.

In the case of the DTD, either design the application so that the DTD is
largely superfluous or, if it is needed, then find a way to include it
in the signature, even if C14N excludes it.  One could put a Reference
to the dtd file and an Object containing a copy of the internal DTD
subset in the signature before signing.  After a core signature
validation, the application could check to make sure that no change of
DTD occured.

It may seem disappointing that core validation is not enough, but I
think many of us have long believed that there are a lot of applications
for which it simply won't do.  In particular, implementing the maxim
"What you see is what you sign" requires (at a minimum) a
post-processing step to ensure that the presentation layer stylesheet
used to render data actually matches the one included in a signature.  I
personally have found a number of other steps useful/necessary in
complex signature scenarios involving signatures over partial documents.

Despite the existence of application-specific solutions, your example is
excellent.

John Boyer
Senior Product Architect, Software Development
Internet Commerce System (ICS) Team
PureEdge Solutions Inc. 
Trusted Digital Relationships
v: 250-708-8047  f: 250-708-8010
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	
 	



-----Original Message-----
From: Thomas Maslen [mailto:maslen@dstc.edu.au]
Sent: Thursday, July 12, 2001 5:20 AM
To: w3c-ietf-xmldsig@w3.org
Subject: ID/DTD/c14n/dsig mischief?


[ Has this been done to death before?  I looked in the archives and
didn't
  see this exactly, but if I missed it can someone steer me toward it? ]

Canonical XML makes use of information that may have started life in a
DTD
(e.g. entity declarations and attribute types) but does not directly
include the DTD in the c14n output.

Section 1.3 of the Canonical XML Recommendation discusses cases where
this
may lead to (possibly false) negatives, i.e. discarding or changing the
DTD 
can produce different c14n results, which when used in dsig will lead to

digest mismatches.  In particular, the second-last paragraph discusses
the
effect on attributes whose type is ID.

I'm wondering about the converse -- cases that can lead to false
positives, 
i.e. changing the DTD doesn't change the pile of bits that comes out of
c14n 
(so, when used in dsig, the digest will still match and the signature
will 
still verify), but the document now means something different.

The example that I have in mind uses attributes whose type is ID, and it
goes something like this...  say I'm a disgruntled screenwriter, and for
the 
next episode of the soap that I'm working on I produce a plot outline
like
this:

	<!DOCTYPE Soap [
	  <!ELEMENT Character ... >
	  <!ATTLIST Character
	      name     ID    #REQUIRED
	      nickname CDATA #IMPLIED
	  >
	]>

	<Soap>
	  <Characters>
	    <Character name="alice"> ... </Character>
	    <Character name="bob">   ... </Character>
	    ...
	    <Character name="susan" nickname="alice"> ... </Character>
	    <Character name="tim"   nickname="bob"  > ... </Character>
	  </Characters>
	  <Actions>
	    <Kill killer="#alice" victim="#bob" />
            <!-- (Uses URI fragments but could also use IDREF
attributes) -->
	  </Actions>
	</Soap>

and get sign-off from the series producer.  (For concreteness, say he
signs
the entire document using an enveloped signature, and puts the signature
just before the closing "</Soap>").

Now I modify the ATTLIST declaration, changing the ID attribute from
"name"
to "nickname", and end up with

	<!DOCTYPE Soap [
	  <!ELEMENT Character ... >
	  <!ATTLIST Character
	      name     CDATA #REQUIRED
	      nickname ID    #IMPLIED
	  >
	]>

	<Soap>
	  <Characters>
	    <Character name="alice"> ... </Character>
	    <Character name="bob">   ... </Character>
	    ...
	    <Character name="susan" nickname="alice"> ... </Character>
	    <Character name="tim"   nickname="bob"  > ... </Character>
	  </Characters>
	  <Actions>
	    <Kill killer="#alice" victim="#bob" />
            <!-- (Uses URI fragments but could also use IDREF
attributes) -->
	  </Actions>
	  <Signature xmlns="..."> ... </Signature>
	</Soap>

This still verifies, but now Tim dies instead of Bob, which isn't the 
outcome that the series producer thought he was signing.

Thomas Maslen
DSTC
Received on Thursday, 12 July 2001 13:35:10 UTC

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