W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

RE: Alternative XML C14N: Document Subsets

From: John Boyer <jboyer@PureEdge.com>
Date: Mon, 5 Jun 2000 13:20:58 -0700
To: <gregor.karlinger@iaik.at>
Cc: "XML" <w3c-ietf-xmldsig@w3.org>, "Joseph Reagle" <reagle@w3.org>, "John Cowan" <jcowan@reutershealth.com>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Message-ID: <BFEDKCINEPLBDLODCODKKEBGCDAA.jboyer@PureEdge.com>
Hi Gregor,

You can look at that material as a marker to indicate that we *may* need to
do something to deal with the possible loss of information for xml:lang and
xml:space.  However, I do not think it means what you think it means.  Based
on your example below, I would not have expected the internal content of the
poem to appear because its text node does not match the expression given.

However, the expression as given doesn't really do what I want it to do.
What I'd really like to capture is only the ancestors of nodes in X that
have xml:space or xml:lang declarations.  That appears to be a bit more
difficult to express (suggestions welcome).

Actually, the main thing I don't like about the solution I've given is that
it tends to include certain peripheral information that the XPath expression
author really needs to get rid of (hence, the solution is quite unlikely to
stay around).  For example, if you omitted an element's ancestor chain, it
may be your intent to allow the ancestry of the signed element to vary, but
it wouldn't necessarily be able to if the wrong combination of xml:lang and
xml:space appear.

An alternative I've been thinking of is to change the element rendering
algorithm so that any element whose direct parent is not rendered would be
required to run its ancestor chain looking for 'xml:' attributes to
duplicate *within the element's start tag*.

This would set a precedent that 'xml:' attributes *always* apply to
descendants, but it would solve the problem we're currently discussing as
well as deal with the problem we haven't discussed yet, which is what will
happen when XBase becomes a recommendation.  We will need to preserve XML's
understanding of the Base URL in partial documents.  In general, information
lost due to a loss of xml: attributes is contrary to the needs of DSig.  For
a particular XML vocabulary, it is possible to argue that a specific XPath
could not possibly omit meaningful information, but this is based on never
losing relevant information from ancestors.  Unfortunately, XML itself uses
this technique often.  To compensate, we do things like propagate namespaces
down to descendants.  It seems reasonable that we should use the same
practice for xml: attributes, even if no data model currently in
recommendation accounts for this.

I'd be interested to know what you (and the other cc'd people) think of this
alternative.

Thanks,
John Boyer
Software Development Manager
PureEdge Solutions Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Gregor Karlinger
Sent: Saturday, June 03, 2000 4:27 AM
To: John Boyer
Cc: XML
Subject: Alternative XML C14N: Document Subsets


Hi John,

I think the approach you are using in section 5 of the alternative C14N
draft,
is impractical for the main use case inside XML-Signature, namely the c14n
of
the SignedInfo Element. Consider the following (simplified) example:

<MyDocument>
  <PoemFragment xml:space='preserve'>
    Und blicket sie lange verwundert an;
    Drauf spricht er: „Es ist euch gelungen,
    Ihr habt das Herz mir bezwungen,
    Und die Treue, sie ist doch kein kein leerer Wahn –
    So nehmet auch mich zum Genossen an.
    Ich sei, Gewährt mir die Bitte,
    In eurem Bunde der Dritte.
  </PoemFragment>
  <PoemAuthor>
    Friedrich von Schiller
  </PoemAuthor>
  <MySignatureContainer>
    <Signature>
      <SignedInfo Id='SignedInfoId'>
        [...]
      </SignedInfo>
      [...]
    </Signature>
  </MySignatureContainer>
</MyDocument>

Now, I'd like to c14n my SignedInfo element. Refereing to the new draft,
I have to do the following:

* Set context node to document's root node

* Additionally specify my special XPath expression, which is
  "//SignedInfo[Id='SignedInfoId']"

The computation of the XPath results in:

  <PoemFragment xml:space='preserve'>
    Und blicket sie lange verwundert an;
    Drauf spricht er: „Es ist euch gelungen,
    Ihr habt das Herz mir bezwungen,
    Und die Treue, sie ist doch kein kein leerer Wahn –
    So nehmet auch mich zum Genossen an.
    Ich sei, Gewährt mir die Bitte,
    In eurem Bunde der Dritte.
  </PoemFragment>
  <SignedInfo Id='SignedInfoId'>
    [...]
  </SignedInfo>

which is definitely not the result I would like to have.

I don't see a way how to resolve the problem with xml:space and
xml:lang this way, because the preserving these attributes also
effect the output result.

I think there must be a different process to be applied for
document subsets. Part of this process is to collect the necessary
information about theses attributes AS PART OF THIS PROCESSS, but
not by specifying a XPath which collects the information.

Regards, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------
Received on Monday, 5 June 2000 16:21:51 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT