Re: [dss] Issue on verification for InlineXML

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Juan Carlos and all,

First of all I'd like to say, that this is a problem fragile legacy XML
signatures (i.e. ones not using exclusive c14n on a ds:Reference level
and as ds:CanonicalizationMethod, not taking care of data type
normalization issues) can generally suffer when inlined into some sort
of xml protocol.

Also, I fear that defining extraction on a DOM level will be highly
implementation and DOM version dependent.
Other transforms like XSL and XML Infoset-to-Infoset transformations, do
not give the impression to be specified as stringent as excl-c14n to
enable an unambiguous way to solve the problem.

On top of that I do not think they could solve another problem we should
not forget about: If the VerifyRequest is processed by other xml tools
or gateways there is no control over what these do to the content inside
<InlineXML> (moving namespace declarations, data type normalizations etc
...), however as long as they do not change <InlineXML> substantially
(i.e. the real information inside <InlineXML>) excl-c14n should produce
the same output. If we don't mandate its usage we'd loose this feature.

I think that this is an important architectural feature of DSS we'd
loose as robustness against influences of potential underlying xml
protocol layers would get lost.

Hence my advise would be, that fragile legacy XML signatures shall
rather be transported opaquely as <Base64XML> or <EscapedXML> or a
WARNING or ERROR should be issued if these are tried to be verified
using <InlineXML>.

Juan Carlos Cruellas wrote:
> [...] If what we have mentioned so far is true, we think that the problem
> is in mandating extraction of the inline xml with exclusive 
> canonicalization
> from the VerifyRequest message.
I don't think we have another choice of an unambiguous stringent well
defined implementation independent way of describing the extraction.
> One thing is mandating an exc canonicalization
> when you are signing and you may put the transformation indication 
> within the
> SignedInfo and something different is mandating to use exc 
> canonicalization for
> extracting XML:
The reason for this was to have a well defined method for extraction.
> in this last case, the server does not have control on the
> transformations applied for computing the signature, and must perform the
> ones indicated in the SignedInfo generated by the signing device....
True, however there is potential for implementors to identify, if such
fragile legacy signatures are sent and to issue a WARNING or ERROR.
> We think that some modification is required in section 4.3.
>
> 1. text in line 1368, text:
> [...] "This document is extracted and decoded as described in 3.3.1 
> Step 1.a or equivalent step in variants of the basic process as 
> defined in 3.3.2 onwards depending of the form of the input document, 
> except when the <Document> content is an <InlineXML> element. In this 
> case, the server should extract <InlineXML> contents without taking 
> inherited namespaces and attributes."
This would be okay for me, if we could assure that other processing
would not touch anything inside <InlineXML>.
However I don't think this can be achieved by anything else but
<Base64XML> or <EscapedXML> or similar opaqueness ensuring techniques to
have a 100% one-to-one transport of the inlined document.
> 2. text in line 1388
> [...]
> "a.    If the input document is a <Document>, the server extracts and 
> decodes as described in 3.3.1 Step 1.a or equivalent step in variants 
> of the basic process as defined in 3.3.2 onwards depending of the form 
> of the input document, except when the <Document> content is an 
> <InlineXML> element. In this case, the server should extract 
> <InlineXML> contents without taking inherited namespaces and attributes".
Having said that, I think we nevertheless should not totally give up to
find a formally well defined way of extracting the relevant Document
from <InlineXML> also taking care of negligible changes due to
processing by underlying xml layers or tools, but I'm not so sure this
will be an easy task.

best regards
Konrad