Re: [dss] Issue on verification for InlineXML

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Konrad and all,

First of all, I must say that I agree with Konrad in that formally 
defining a processing
way by which we could assure that we may safely extract xml without 
being affected
by  negligible changes due to processing by underlayihng xml layers or 
tools  could not
be an easy task. Having said that, please find my comments intermixed.
Konrad Lanz wrote:

> 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.
>
Yes, you are right....but we do not have control on that, and appart from
writing some "best practices" recommendation, there is not much we can
do about it if people outside generate them.... Maybe we may expect 
exclusive
canonicalization will gain acceptance and usage in from regular 
canonicalization
but this is a decision to be taken by generating tools, profiles 
designers, etc

> Also, I fear that defining extraction on a DOM level will be highly
> implementation and DOM version dependent.

I would not be in favour of explicitly mention an extraction on a DOM level,
and in fact the text proposed does not do that. One thing is to clearly 
indicate
that no inheritance of namespaces and attributes within xml namespace should
take place and other is to say that this must be done by using DOM 
operations.
What the text does is to give rules for extraction, not ot indicating tools
to be used. One thing is that DOM tools incorporate an operation that 
does so,
and one other is that other tools may also incorporate similar 
operations, or
if not, designers may define such a new operations....

> 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 agree that the potential changes performed by gateways could alter
the <InlineXML> contents up to the point of making the validation to fail.
Could not we put a warning on this issue?
Something that reading your text has come to my mind is
why we should assume that <InlineXML> is the only one element that they
could touch? could not they also modify <SignatureObject>? and if so, could
not they alter the <Signature> element and make to fail the signature value
computation on <SignedInfo>? By the way, we are not being so stringent
with the extraction of <Signature>: we only say "the server retrieves 
either the
ds:Signature objects", and we do not mention either the inheritance of
namespaces/attributes, and this is a piece of XML with something that must
be digested.

> 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>.
>
I would say that we could strongly recommend this, but not sure if we 
should mandate....
There could be a number of occassions where there are no gateways 
changes and
implementations correctly extracting the <InlineXML> and the <ds:Signature>.

Of course the price to pay is that in certain occassions the client 
could not
know if a failure was due to a bad signature or to a gateway touching the
contents of <InlineXML> (BTW: should I say <InlineXML> or 
<ds:SignedInfo>? if so,
then we have even a stronger problem).....

And here there is an implementation issue: clients should decide how to
build up the request, and if we ban the usage of InlineXML in certain 
occassions,
then we put on the client side the work of analizing the ds:Signature 
contents....
which could end up in proliferation of clients not using at all the 
<InlineXML>
just for avoiding any potential problem....and asking themselves why 
these guys
defined the InlineXML if this is so problematic?

Just to summarize, could not be possible to make a note highligthing the 
problem
of potential danger in gateways modifying the contents of <InlineXML>, 
recommend
usage of <EscapedXML> but not banning the usage of <InlineXML> for the 
"fragile"
signatures as qualified by Konrad? in this way, services themselves 
could instruct
their clients to select one way or the other depending on their 
infrastructure.

this note could be something like:

"WARNING: service providers should be aware of the presence within their 
supporting
infrastructure of gateways that could significantly modify XML contents 
of the request
so that the <InlineXML> element could be altered in a way that would 
eventually lead
to a failure in the verification of the ds:Signature. In such 
occassions, server providers
MUST instruct their clients to send XML documents protected against such 
changes
within <EscapedXML>."

Now, the only doubt I have is the one mentioned on changes to 
ds:SignedInfo...

In any case, if the committee eventually selects to ban the usage of 
<InlineXML>
I would be in favour of <EscapedXML>...you know,
defining a XML protocol and transporting XML documents in base64 is not 
the kind
of things one expects to do....

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

Could not ds:SignedInfo be touched as well?

> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php