[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: General XML-DSIG questions
I think we've got 2 general XML-DSIG issues, which we could ask that working group for guidance on. Securing Transform Chain - Normally, the relying party can check that the input data is related to the what-is-signed data by the specified (and signed) transforms. But if the transforms include some external data that isn't signed (for instance an imported stylesheet referred to in an XSLT transform), then the relying party can't be sure than both him and the signer are seeing the same transforms - and if an attacker can control the transforms, he could construct different transforms such that different input documents yield the same result, i.e. Input Document 1 + Transform 1 -> What-is-signed Document Input Document 2 + Transform 2 -> What-is-signed Document (identical to above) Even though the signer intends to sign Document 1, the attacker can trick the relying party into relying on Document 2. So external transform data needs to be secured through some out-of-band method, or needs to be covered by the XML-DSIG itself. If the data is to be covered by the XML-DSIG, should it be: a) referred to by a dsig:Reference in the dsig:Signature (and attached as a signed attribute or something, if it's representable in XML)? b) referred to by a dsig:Reference in a dsig:Manifest to the dsig:Signature? Note that how this is done may affect Reference Validation, since the original document's dsig:Reference should only be considered valid if the external transform data's dsig:Reference is. In other words, there's now a dependence among the References. So if it's done as (b), a dsig:Manifest, the relying party isn't required to process the Manifest, which may have security implications. Signing Human-Readable data and XML - The client may want to sign both an XML document and its human-readable transformed version, for use in dispute resolution. How should this be done? One approach is to include two dsig:Reference elements in the signature, the first to the XML document, the second to the same document with human-readable transforms applied. Then a "policy identifier" of some sort should be added as a signed attribute to indicate the relation of these documents. This approach will fail if the human-readable transforms behave inconsistently when applied by the signing and relying parties (perhaps due to implementation differences in the transform engines), and a canonicalization transform for the transform output data is unavailable. This is (apparently) the case with XSLT transforms producing HTML. This could be solved by the signer storing the transform output data at a URL, or sending it with the signature, and referring to it explicitly instead of requiring the verifying party reproduce the transform process. But that may be inconvenient. A different approach is to have the signer add a signed attribute containing "transforms that reproduce what I was looking at when I chose to sign". Since processing these transforms isn't required to verify the signature, it avoids the problem of having the signature fail if the signer and verifier's transform engines produce slightly different output. However, if the engines *are* producing different output, there's now wiggle-room for the signer to claim "oh, my transform engine produced something different, that's not *really* what I was looking at when I chose to sign". So this may just shift the problem of "transform variability" to a different place, not remove it. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]