RE: Prefix rewriting considerations

We have two opposing requirements here.

On one hand we have to support complex WS-Security use cases, where there are many different schemas intermixed in the same document, and use of the prefixes in attributes is very common, e.g. wsu:id. The visibly utilized concept is very important here - because people tend to put in a lot of namespace declarations in the top level just in case they need it. Without exclusive Canonicalization there is no chance of signature verification working reliably.

On the other hand we also need to support simple use cases, with just a single schema, and signing only one complete subtree and no qnames in content.

We need to flush out the this simple case. 

Pratik


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, April 13, 2010 8:04 PM
To: Meiko Jensen
Cc: Pratik Datta; public-xmlsec@w3.org
Subject: Re: Prefix rewriting considerations

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

Exclusive c14n already handles this use case. Where it has problems is
with QNames in content, because those have to be handled "inclusively"
to get around the problems with how it's defined. That creates its own
problems by reintroducing the leakage issue, so my suggested fix is to
enable the signer to identify those QNames (where possible) and eliminate
a lot of errors that way.

> The complete "visibly utilized" stuff (that actually made EXCC14N rather 
> complex) can be omitted, since you don't need the namespace declarations
> anymore.

It doesn't seem terribly complex to me, but I think the main reason for that
approach was limiting size, and the changes required to a document to put
it into canonical form. Whether that's "legitimate" or not is worth discussing.

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

I guess maybe the question is whether it fits into one of the proposals
for prefix rewriting, or is maybe a third option (suitably modified to handle attributes
and QName content).

But since I'm still generally skeptical of rewriting and don't think it's strictly needed,
I probably wouldn't be driving that conversation.

-- Scott

Received on Wednesday, 14 April 2010 16:14:20 UTC