Re: [dss] Issue on verification for InlineXML

[Ed Shallow <ed.shallow@rogers.com>]

EscapedXML is not really "something we invented".

Changing < to &lt;
and      > to &gt;
and      "\n" to <br>

has been around for years and causes the DSS processor (while parsing
request input) to look at the EscapedXML element content as pure
content at a leaf node level while also preserving PIs and comments.
Quite simple and effective.

Ed 

--- Konrad Lanz <Konrad.Lanz@labs.cio.gv.at> wrote:

> Hi JC,
> 
> some very very quick comments below, I'll answer in more detail in
> the 
> telco where necessary.
> 
> best regards
> Konrad
> 
> Juan Carlos Cruellas wrote:
> > [...] 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 mentioned that in the past:
> Please see the thread around 04.10.2005 19:05 
> "<VerifyRequest>/<SignatureObject>/<ds:Signature> & inclusive 
> <ds:CanonicalizationMethod> issue".
> >
> >> 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>.
> Sure.
> > 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).....
> I'm not sure I understand what you are trying to say with "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?
> I'd say that we defined it for situation where it's either uncritical
> to 
> use it (becuase it's simple), or if all precautions are taken to get
> it 
> right. (robust signatures are used)
> > 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>."
> I'd rather prefer to have the protocol robust against such
> ineterference.
> >
> > 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'm against banning <InlineXML> as it works if it is treated
> properly.
> > 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....
> Why not, xs:base64Binary is a standard whereas <EscapedXML> is
> something 
> we defined.
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 
>