Thanks Jesse,
I had not realised that the SignedInfo was signed - problem solved ::) (duh me). I'll stick to c14nable changes for SignedInfo.
With regards to the DigestValue, I guess that might be a problem. I'm using the Java version and the following are ALL validated fine:
<ds:DigestValue>bKlPmI0oKdmq24c4lV8jlL533K8=</ds:DigestValue>
<ds:DigestValue> bKlPmI0oKdmq24c4lV8jlL533K8=</ds:DigestValue>
<ds:DigestValue>bKlPmI0oKdmq24c4lV8jlL533K8= </ds:DigestValue>
<ds:DigestValue> bKlPmI0oKdmq24c4lV8jlL533K8= </ds:DigestValue>
The following doesn't validate:
<ds:DigestValue> bKlPmI0 oKdmq24c4lV8jlL53 3K8= </ds:DigestValue>
It appears that Xerces 2.6.2 is trimming the string. I think I might send them a bug report.
The "custom transform" is equivalent to the attached XPath transform (in fact the implementation is only marginally different). It doesn't change the signature (in fact the enveloped signature transform isn't really necessary because it removes the signature as well. As an aside, the TransformXPath class was not very accessible for reuse, so I was forced to mostly clone it. A method [protected String TransformXPath.getXPathStr()] would have been quite nice - I could have overridden it and saved on the nasty copy+paste. I'll provide a patch if you like, but it's a trivial change.
Cheers,
Martin
p.s. The following fits in 69 characters, so I should manage:
<ds:Transform
Algorithm="urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth#PIDF-LO"
/>
Not a lot of room left.
-----Original Message-----
From: Jesse Pelton [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 19 May 2005 10:55 PM
To: security-dev@xml.apache.org
Subject: RE: Whitespace in SignedInfo element invalidating signature?
I don't think there's quite enough information to make a definitive diagnosis (for instance, you don't specify what your "custom transform" is), but it sounds like you're making changes to the SignedInfo element that are not removed in the course of canonicalization of that element in preparation for generating a signature value. (The signature value is calculated over the SignedInfo element, so changes to the canonical form of SignedInfo change the signature value.)
Assuming your CanonicalizationMethod Algorithm is http://www.w3.org/TR/2001/REC-xml-c14n-20010315, whitespace within element tags is normalized. Thus < ds:Reference URI="" > becomes <ds:Reference URI=""> during canonicalization, and the extra whitespace does not affect the signature value.
Whitespace within element content, on the other hand, is preserved during canonicalization. This means that if you add whitespace to the content of a SignedInfo element after the SignatureValue is generated, you're (permanently) changing the SignedInfo from what was signed, so the resulting signature value differs, and signature validation must fail.
Why you're able to alter DigestValue content without invalidating the signature I don't know. I can't introduce whitespace into a DigestValue without invalidating the signature, which is what I would expect. I can't tell from your example whether you're using the C++ library, as I am. If you're using the Java code, I'd suggest that it may have a bug.
Check the XML-Signature Syntax and Processing (http://www.w3.org/TR/xmldsig-core/) and Canonical XML (http://www.w3.org/TR/2001/REC-xml-c14n-20010315) recommendations for details.
You may not be able to represent your document within 69 columns without breaking the signature. You may have to include a note to that effect, and perhaps instructions as to how to reassemble the document. It's admittedly ugly, but the needs of XML documents were notably missing when the RFC format was designed. ;-)
-----Original Message-----
From: Martin Thomson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 18, 2005 7:31 PM
To: security-dev@xml.apache.org
Subject: Whitespace in SignedInfo element invalidating signature?
Hi all,
Possible bug?
I have produced a document that includes an enveloped signature and I am trying to reformat it so I can include it in an RFC (69 characters per line and all). That means tinkering with the whitespace. So far I've been able to change all the parts of the document that are excluded by transforms without signature validation failing, except for the ds:SignedInfo element.
I'm using the following to check that the signature was correctly applied:
XMLSignature sig = new XMLSignature((Element)nl.item(i), "");
X509Certificate cert = sig.getKeyInfo().getX509Certificate();
if (! sig.checkSignatureValue(cert))
For some reason, if I modify the whitespace within the SignedInfo, signature validation fails. I can't explain this, since I'm using the enveloped signature transform, which should rule out any changes to the signature that don't actually change parameter values.
I can change a few things in the SignedInfo element: the whitespace within the actual tags (< ds:Reference URI="" > is as good as <ds:Reference URI="">), and I can use '/>' for empty elements in place of a closing tag. Interestingly, the whitespace in the ds:DigestValue element is the only whitespace that can be changed without effect.
I've expressly printed the output of my custom transform and there is no difference between a successful validation and a failed one.
Martin
domain-auth-transform.xml
Description: Binary data
