Re: [dss] Issue on verification for InlineXML

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

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.