Re: XML Signature - Request for clarification [Virus checked]

Dear Christian Geuer-Pollmann,

I partially agree what you suggest may be a viable proposal for a second
version of XMLDSig, but I disagree that the current normative parts
unambiguously specify what should be done with '#', '%', '[', ']' in the
URI Attribute of a reference.

Hence the only solid choice is to escape these characters if they do not
  initiate the fragment of a URI or an escape sequence or delimit an
IPv6 host respectively.

Christian Geuer-Pollmann wrote:
> [...] your first example
> 
> <Reference URI="#xpointer(//*[@authenticate='true'])">
> 
> is correct.

Well I'd say both are correct, if the assumption for the first example
holds that '[', ']' are moved to the reserved characters for non IPv6
URIs as well.

This assumption in - at least from my point of view - possible, but not
very solid, because albeit RFC 2732 extended RFC 2396 for IPv6 only and
it did not obsolete it.

http://tools.ietf.org/html/rfc2732 :
>    It defines a syntax
>    for IPv6 addresses and allows the use of "[" and "]" within a URI
>    explicitly for this reserved purpose.

However in the spirit of RFC 3986 it is valid to make the previous
assumption, which however is not yet normative for XMLDSig.

RFC 3986 can become normative as soon as it is believed that it will not
cause a conformance affecting change to XMLDSig.

Currently normative for this issue are the following bits:
###
[1] http://www.w3.org/TR/xmldsig-core/#sec-URI

[2] http://tools.ietf.org/html/rfc2396

For IPv6
[3] http://tools.ietf.org/html/rfc2732

and via the schema data type anyURI, but not via the DTD
[4] http://www.w3.org/TR/xmlschema-2/#anyURI
[5] http://www.w3.org/TR/2001/WD-charmod-20010126/#sec-URIs
###

[1] standardizes that '[' ']' are permitted for IPv6 in conformance with
[3]. However the question can be asked whether it is possible for a
fragment only URI reference to be affected by [3] at all as it is a same
document reference and not in touch with IPv6 at all.

[1] suggests that the number sign (#) and percent sign (%) are permitted
everywhere under all circumstances which however would contradict [2].
And hence is questionable.

[1] norms (#) and percent sign (%) are permitted everywhere under all
circumstances which however would contradict [2].

Conclusion: Always escape '#', '%', '[', ']' if not used for their most
fundamental application (i.e. fragment, escaping, IPv6).

The second example and also the following example however is in any way
correct as it strictly complies to RFC 2396 and is not affected by any
of the rules in [1] - [5] to twist the URI:

<Reference URI="#xpointer(//*%5B@authenticate='true'%5D)">

> The other thing *would* be the escape sequence which you
> need when sensing the URI as part of a GET request to some web
> server, i.e. when the URI would be consumed and cracked by an HTTP
> server. That is not the case at XML Signature: the @URI attribute
> here is processed by an XML Signature library, which does not expect
> that escaping.


Well it actually must be able to treat the escaped version as well as
it's neither prohibited by any of [1] - [5] .


> Doing RFC2396 escaping in a ds:Reference/@URI is wrong
> (and just feeding that into a concrete implementation should actually
> give you that answer with some nice exception :)).

Well then that implementation should be changed accordingly, as escaping
is nowhere prohibited.


regards
Konrad

P.S.: Personally I believe what the text in [1] tried to achieve was
what is specified [5], but it confused things a bit.

[5] does not allow number sign (#) and percent sign (%) characters in
their unescaped form, but for initiating the fragment or an escape
sequence.

The same holds true for square brackets as long as the references are
not updated to RFC 3986.

To cut a long story short '#', '%', '[', ']' are not "disallowed
characters" in the sense of [5] however they are to be escaped according
to [2] and [3] if not used as initiating character for the fragment of a
URI or an escape sequence or to delimit an IPv6 host respectively.

Forwarded to http://lists.w3.org/Archives/Public/public-xmlsec-comments/
public-xmlsec-comments@w3.org you may want to subscribe to this list.


Marcus Ertel wrote:
> Ladies and Gentlemen:
> 
> Let me start with a brief introduction of the issue that makes me ask
> for a clarification from your side. My name is Marcus Ertel and I am
> with "Sparkassen Informatik", one of the biggest IT service providers
> in Germany. We are currently busy introducing the new money transfer
> standard EBICS (Electronic Banking Internet Communication Standard;
> please see
> <http://www.ebics-zka.de/english/spec/specification_en.htm>) which
> relies heavily on XML and particularly XML Signature.
> 
> The various implementations of EBICS raised a discussion concerning
> the handling of the Reference URI in the SignedInfo element of an XML
> signature. The issue is, quite briefly, as follows:
> 
> The XML data of an EBICS message contain a <SignedInfo> element with
> a <Reference URI> that contains an XPointer:
> 
> <Reference URI="#xpointer(//*[@authenticate='true'])">
> 
> Now there's an ongoing discussion about the handling of this URI
> before the calculation of the XML Signature. One opinion is as
> follows: In order to obtain a valid, RFC 2396 compliant URI, parts of
> the Reference URI have to be escaped properly. Hence, the URI fed
> into the signature process is as follows:
> 
> <Reference
> URI="#xpointer(%2F%2F*%5B%40authenticate%3D%27true%27%5D)">
> 
> On the other hand, there is quite the opposite opinion. Its
> proponents say that no escaping at all is necessary, because the URI
> consists of just an XPointer. And as all the candidates for escaping
> are parts of this XPointer, they do not infringe the requirements of
> RFC 2396.
> 
> Could you please kindly advise on how to process this special URI? We
> need this clarification because there are ISV's providing the German
> banking software market with these two implementations of the XML
> Signature standard. This in turn leads to products unable to cope
> with each other while all of them claim to be compliant with the XML
> Signature standard.
> [...]




-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm