- From: Meiko Jensen <Meiko.Jensen@rub.de>
- Date: 13 Apr 2010 23:05:18 +0200
- To: "Scott Cantor" <cantor.2@osu.edu>
- Cc: "'Pratik Datta'" <pratik.datta@oracle.com>, public-xmlsec@w3.org
Scott Cantor schrieb: >> Don't you get such qname problems as well with rewriting prefixes to >> "ns$i" or to base64(hash(ns-uri))? >> > > Yes, but we're handling that now (to the extent we can). The point is, what > does "simplifying" the other cases buy us if we still have to address the > prefixes anyway? > This depends on the scenario. If the XML Signature is intended to be placed and verified on a single document, there is no need to rewrite the prefixes at all, agreed. However, if you want to "recycle" a signature, e.g. use the same signed fragments of an XML document in new documents (e.g. data variables in SOAP messages of Web Service compositions), you might run into problems with the prefixes chosen on signature application. Another benefit is that PFC14N can easily and rapidly be done in the streaming case, without the need to store namespace definition stacks or ponder about where to put which namespace declaration. The complete "visibly utilized" stuff (that actually made EXCC14N rather complex) can be omitted, since you don't need the namespace declarations anymore. > >> I mean, this is about >> canonicalization, hence direct input to digest computation. If you'd do >> a prefix rewrite in *any* way, such references to "xsd:string" will be >> broken in the c14n'ed XML. >> > > Unless you rewrite them too. > OK, I got the point. Agreed, this is something that PFC14N indeed does not support. > >> Regarding attributes: you'll only need prefixes if an attribute is from >> a different namespace than its element (rare case). >> > > It's not really that rare (xsi:type being one obvious case, SOAP being > another). > > >> Then you can define >> an arbitrary prefix (e.g. using the "ns$i" approach) at that element, >> which thus is only relevant for that single attribute(s) at this >> particular element. Advantage is that you don't have to deal with issues >> of identical prefixes mapping to different namespace uris. >> > > The point is that it defeats the simplification you're suggesting exists > when the exceptions are quite common. > well, the tradeoff here is either dealing with some attributes or dealing with lots of namespace mappings in XML subtrees. I think it largely depends on the scenario, but I have to admit you're right: PFC14N is not suitable to support all use cases. best regards Meiko
Received on Tuesday, 13 April 2010 21:05:17 UTC