OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: In relation to DSS Action Item - 06-04-24-01 - C14N Note




Konrad,

Based on our last discussion, I propose the following description.

----

When an arbitrary XML document is inserted within another arbitrary XML
document, the problem of computing and correctly verifying a XML digital
signature over the original document becomes very complex and in fact
may not be possible in the most general case. Yet imbedding XML in this
way is a common feature of XML based communication protocols. If
spurious XML digital signature verification errors were to become
relatively common, the result might be a tendency to avoid the use of
XML digital signature entirely or worse still to assume errors were
always spurious and always ignore them.

It is well known that problems of spurious validation errors can occur
with XML Digital Signature due to the inclusion of different namespace
declarations under the signature than those included when the signature
was calculated. The Exclusive Canonicalization Algorithm was devised to
address this issue. 

However, during our work, the OASIS Digital Signature Services Technical
Committee has discovered that there seems to be no general mechanism for
referencing the imbedded document which guarantees the proper infoset
will be obtained in the general case.

If expressions (XPath-Expressions) inside XPath-Filters (or
XPath-Filters 2.0), XSLT etc.. used in the chain of transforms (i.e.
<ds:Reference>/<ds:Transforms>/<ds:Transform>) are used in a way so that
they may also refer to parts of the surrounding context, e.g. a
transport protocol, the output will be different depending on whether
the document is inside that context or not.

Such transformations walk up the XPath ancestor-axis or refer to
absolute parts that may be changed by processing and include or exclude
elements depending on the existence or values of attributes or elements
of the transport protocol. This will produce a validation error. 

As an alternative to the use of XPath, reference may be made to an Id
Attribute, however this method has its own attendant problems. For one
thing, the flat namespace of Id Attributes makes a duplicate and hence
ambiguous reference likely, especially when the documents in question
are large and generated by distinct software elements. Also the
insertion or removal of Id Attributes will break previously computed
signatures over the elements in question. Additionally, a number of
potential security attacks have been identified which may occur when
signature references to Id Attributes are used in particular ways.

A number of specifications have defined special purpose solutions to
this problem, but there sees to be no solution in the general case. The
means identified by the OASIS Digital Signature Services Technical
Committee to assure consistent behavior is "context free extraction"
of signed inline XML content as in section 3.3.2 Process Variant for
<InlineXML> 
<http://docs.oasis-open.org/dss/v1.0/oasis-dss-1.0-core-spec-cd-r4.pdf#p
age=22>.

---

Hal


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]