You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Harakiri <ha...@yahoo.com> on 2009/01/27 19:02:25 UTC
Invalid Signature problem through Empty elements are converted to start-end tag pairs
We created signatures using the SUN XML Signature APIs in JRE 5 Versions.
Due to a bug in SUNs API we like to use the XML Security API from Apache.
However, all our signatures are invalid through possibly a bug in java.
The signatures have been created with the following:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
however it seems that java signed empty tags as:
<param name="myparam"/>
but apache security correctly validates as
<param name="myparam"></param>
Since i cant just change existing signatures, how can I modify the apache xmldsig validation so that it will not compute the hash over the empty tags as <param></param> but as <param/> ?
Thanks!
Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Harakiri <ha...@yahoo.com>.
> From what I can tell, I think you are trying to generate an
> enveloped signature that signs the entire contents of the
> document (excluding the signature). In that case, you should
> replace your code and use the example above as a guideline.
This is what i want to do, but i need to find a way to verify the signatures correctly of the xml sigs that were created with the legacy system. Currently i can only verify that the signature itself is valid, not the refs - maybe there is something to make the ref validiation also valid?
> These appear to be really old from a Sun product (JWSDP)
> that is no longer supported. If possible, I would encourage
> you to move to something more recent, either use the
> xmlsec.jar from a recent Apache XML Security release (which
> will work on JDK 1.4.2 and up) or the XML Security/JSR 105
> implementation built into JDK 6.
Yes i want to move to the xml security of apache, hence why i am having trouble verifiying my old signatures. I cant move to the new one, if my old signatures are shown as invalid (only the reference validiation tho)
Re: Invalid Signature problem through Empty elements are converted to
start-end tag pairs
Posted by Sean Mullan <Se...@Sun.COM>.
Harakiri wrote:
>>>> This is a very strange signature. If you just want
>> to sign
>>>> the contents of the document (the tbone element)
>> without the
>>>> signature, you should just use the enveloped
>> transform:
>> http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
>>> I think the code was based on this example:
>>>
>>>
>> http://svn.apache.org/repos/asf/xml/security/trunk/src_samples/javax/xml/crypto/dsig/samples/GenEnveloped.java
>>
>>
>> But that example uses the Enveloped Signature Transform.
>
> So the sample code i submitted earlier is correct ?
No, I don't think so.
From what I can tell, I think you are trying to generate an enveloped
signature that signs the entire contents of the document (excluding the
signature). In that case, you should replace your code and use the
example above as a guideline.
> Since we use
> enveloped signature transform? Because you said we should better use
> enveloped signature transform. Im sorry im just getting the basics of
> xml signature.
>
>
>> When you say SUN xmldsig jars, I'm still not sure what version of
>> the software you are using. Can you give me more details as to what
>> you are using?
>
> Im really sorry, im trying to maintain a legacy application and do
> not have specific information. I decompiled the jars to figure out
> exactly what version it is - but i havent. I will attach the used
> jars to this message.
These appear to be really old from a Sun product (JWSDP) that is no
longer supported. If possible, I would encourage you to move to
something more recent, either use the xmlsec.jar from a recent Apache
XML Security release (which will work on JDK 1.4.2 and up) or the XML
Security/JSR 105 implementation built into JDK 6.
--Sean
Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Harakiri <ha...@yahoo.com>.
> >
> >> This is a very strange signature. If you just want
> to sign
> >> the contents of the document (the tbone element)
> without the
> >> signature, you should just use the enveloped
> transform:
> >>
> http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
> >
> > I think the code was based on this example:
> >
> >
> http://svn.apache.org/repos/asf/xml/security/trunk/src_samples/javax/xml/crypto/dsig/samples/GenEnveloped.java
>
> But that example uses the Enveloped Signature Transform.
So the sample code i submitted earlier is correct ? Since we use enveloped signature transform? Because you said we should better use enveloped signature transform. Im sorry im just getting the basics of xml signature.
> When you say SUN xmldsig jars, I'm still not sure what
> version of the software you are using. Can you give me more
> details as to what you are using?
Im really sorry, im trying to maintain a legacy application and do not have specific information. I decompiled the jars to figure out exactly what version it is - but i havent. I will attach the used jars to this message.
Re: Invalid Signature problem through Empty elements are converted to
start-end tag pairs
Posted by Sean Mullan <Se...@Sun.COM>.
Harakiri wrote:
> --- On Wed, 1/28/09, Sean Mullan <Se...@Sun.COM> wrote:
>
>> From: Sean Mullan <Se...@Sun.COM>
>> Subject: Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
>
>> This is a very strange signature. If you just want to sign
>> the contents of the document (the tbone element) without the
>> signature, you should just use the enveloped transform:
>> http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
>
> I think the code was based on this example:
>
> http://svn.apache.org/repos/asf/xml/security/trunk/src_samples/javax/xml/crypto/dsig/samples/GenEnveloped.java
But that example uses the Enveloped Signature Transform.
>> You need to also dump out the same pre-digested input when
>> generating the signature and then compare them.
>
> I have been unable to figure out how to dump the pre-digested input when signing with the SUN xmldsig jars. Can you hint on how to enable debugging in my last sample code for signing?
When you say SUN xmldsig jars, I'm still not sure what version of the software
you are using. Can you give me more details as to what you are using?
--Sean
Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Harakiri <ha...@yahoo.com>.
--- On Wed, 1/28/09, Sean Mullan <Se...@Sun.COM> wrote:
> From: Sean Mullan <Se...@Sun.COM>
> Subject: Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
> This is a very strange signature. If you just want to sign
> the contents of the document (the tbone element) without the
> signature, you should just use the enveloped transform:
> http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
I think the code was based on this example:
http://svn.apache.org/repos/asf/xml/security/trunk/src_samples/javax/xml/crypto/dsig/samples/GenEnveloped.java
> You need to also dump out the same pre-digested input when
> generating the signature and then compare them.
I have been unable to figure out how to dump the pre-digested input when signing with the SUN xmldsig jars. Can you hint on how to enable debugging in my last sample code for signing?
Thank you for your help
Re: Invalid Signature problem through Empty elements are converted to
start-end tag pairs
Posted by Sean Mullan <Se...@Sun.COM>.
Harakiri wrote:
> (this is my xml doc created by the SUN XML API)
>
> <?xml version="1.0" encoding="UTF-8"?><tbone>
> <license>
> <param name="myparam">Test</param>
> </license>
> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"><XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" Filter="union">/tbone/license</XPath></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>cp68+Em7EAO6X62j+kw7a8T08qU=</DigestValue></Reference></SignedInfo><SignatureValue>TH3tGkUs0Pnzgzb74OjVjqkrZA/9LqBaC4ZzrPrFevsdPBl94XFKg3hPdofLBdFkvb+vkYb9T9TT
> 0436m+aQOnC6Y9pwk7lCKYPvbPeZcwCwUCFa7ccGh0jGSyp83QgBI6eqomWkaI8xq56WjgcvXKiv
> JvZ4sh7QsdQp3dw2q84=</SignatureValue><KeyInfo><KeyName>My Keyname</KeyName></KeyInfo></Signature></tbone>
This is a very strange signature. If you just want to sign the contents of the
document (the tbone element) without the signature, you should just use the
enveloped transform: http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
I don't understand what you are trying to sign above with the XPath Filter 2
union transform. In particular the XPath Filter 2 specification says this about
the union filter, http://www.w3.org/TR/xmldsig-filter2/#sec-Examples (5th
paragraph down):
"Union filters, by themselves are of no particular use: The initial filter
node-set consists of the entire input document; any union with this will have no
effect, so the output of the transform will be identical to the input. The union
operation is intended to follow a subtract operation, to allow a subtree to be
removed, with the exception of a lower subtree which is still included in the
output."
It is quite likely that this transform above is including the signature element
itself as part of the reference digest which definitely would explain why you
are getting a validation failure.
> This forum post hinted at a possible namespace problem
> http://forums.java.net/jive/message.jspa?messageID=37326
>
> but im not sure - because i dont see the suggested 2 pre-digests output.
You need to also dump out the same pre-digested input when generating the
signature and then compare them.
--Sean
Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Harakiri <ha...@yahoo.com>.
Hello,
after further investigation i found out that the signature itself is valid but the reference validation fails.
The signatures are created using JRE5 xmldsig and the SUN xmlsec APIs.
This is the actual code:
public void signDocumentXPath(Document document, PrivateKey privKey,
String baseXPath)
throws Exception {
// Create a DOM XMLSignatureFactory that will be used to generate the
// enveloped signature
String providerName = System.getProperty("jsr105Provider",
"org.jcp.xml.dsig.internal.dom.XMLDSigRI");
XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM",
(Provider) Class.forName(providerName).newInstance());
// Create a Reference to the enveloped document (in this case we are
// signing the whole document, so a URI of "" signifies that) and
// also specify the SHA1 digest algorithm and the ENVELOPED Transform.
Vector v = new Vector();
XPathType type = new XPathType(baseXPath, XPathType.Filter.UNION);
v.add(type);
XPathFilter2ParameterSpec spec = new XPathFilter2ParameterSpec(v);
Reference ref = fac.newReference(
"", fac.newDigestMethod(DigestMethod.SHA1, null),
Collections.singletonList(
fac.newTransform(
Transform.XPATH2, (TransformParameterSpec) spec)), null,
null);
// Create the SignedInfo
SignedInfo si =
fac.newSignedInfo(
fac.newCanonicalizationMethod(
CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS,
(C14NMethodParameterSpec) null), fac.newSignatureMethod(
SignatureMethod.RSA_SHA1,
null), Collections.singletonList(ref));
// Create a KeyValue containing the RSA PublicKey that was generated
KeyInfoFactory kif = fac.getKeyInfoFactory();
//KeyValue kv = kif.newKeyValue(kp.getPublic());
KeyName kn = kif.newKeyName("My Keyname");
// Create a KeyInfo and add the KeyValue to it
KeyInfo ki = kif.newKeyInfo(Collections.singletonList(kn));
// Create a DOMSignContext and specify the DSA PrivateKey and
// location of the resulting XMLSignature's parent element
DOMSignContext dsc = new DOMSignContext(privKey,
document.getDocumentElement());
// Create the XMLSignature (but don't sign it yet)
XMLSignature signature = fac.newXMLSignature(si, ki);
// Marshal, generate (and sign) the enveloped signature
signature.sign(dsc);
}
(this is my xml doc created by the SUN XML API)
<?xml version="1.0" encoding="UTF-8"?><tbone>
<license>
<param name="myparam">Test</param>
</license>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"><XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" Filter="union">/tbone/license</XPath></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>cp68+Em7EAO6X62j+kw7a8T08qU=</DigestValue></Reference></SignedInfo><SignatureValue>TH3tGkUs0Pnzgzb74OjVjqkrZA/9LqBaC4ZzrPrFevsdPBl94XFKg3hPdofLBdFkvb+vkYb9T9TT
0436m+aQOnC6Y9pwk7lCKYPvbPeZcwCwUCFa7ccGh0jGSyp83QgBI6eqomWkaI8xq56WjgcvXKiv
JvZ4sh7QsdQp3dw2q84=</SignatureValue><KeyInfo><KeyName>My Keyname</KeyName></KeyInfo></Signature></tbone>
When i verify the created signature with Apache XML and enabled debugging i get the following log outputs:
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.DOMSignatureMethod verify
FEIN: Signature provider:SunRsaSign version 1.5
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.DOMSignatureMethod verify
FEIN: verifying with key: Sun RSA public key, 1024 bits
modulus: 90423977268013193772672493202847721746573381377536653055997475685558693423657635618679640933512827048211696104270215394685726992656662856050800019998736714201782694955154594507516110929849902421860824852636310291332896187286679644658867737292920964731844144276040900126543154791203642895978715491940484467691
public exponent: 65537
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.ApacheCanonicalizer transform
FEIN: Created transform for algorithm: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.ApacheCanonicalizer transform
FEIN: isNodeSet() = true
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.DOMSignedInfo canonicalize
FEIN: Canonicalized SignedInfo:
<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"></CanonicalizationMethod><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"><XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" Filter="union">/tbone/license</XPath></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod><DigestValue>cp68+Em7EAO6X62j+kw7a8T08qU=</DigestValue></Reference></SignedInfo>
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.DOMSignedInfo canonicalize
FEIN: Data to be signed/verified:PFNpZ25lZEluZm8geG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxD
YW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvVFIvMjAw
MS9SRUMteG1sLWMxNG4tMjAwMTAzMTUjV2l0aENvbW1lbnRzIj48L0Nhbm9uaWNhbGl6YXRpb25N
ZXRob2Q+PFNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAv
MDkveG1sZHNpZyNyc2Etc2hhMSI+PC9TaWduYXR1cmVNZXRob2Q+PFJlZmVyZW5jZSBVUkk9IiI+
PFRyYW5zZm9ybXM+PFRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDIv
MDYveG1sZHNpZy1maWx0ZXIyIj48WFBhdGggeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDIv
MDYveG1sZHNpZy1maWx0ZXIyIiBGaWx0ZXI9InVuaW9uIj4vdGJvbmUvbGljZW5zZTwvWFBhdGg+
PC9UcmFuc2Zvcm0+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8v
d3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSI+PC9EaWdlc3RNZXRob2Q+PERpZ2VzdFZh
bHVlPmNwNjgrRW03RUFPNlg2Mmora3c3YThUMDhxVT08L0RpZ2VzdFZhbHVlPjwvUmVmZXJlbmNl
PjwvU2lnbmVkSW5mbz4=
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.DOMReference dereference
FEIN: URIDereferencer class name: org.jcp.xml.dsig.internal.dom.DOMURIDereferencer
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.DOMReference dereference
FEIN: Data class name: org.jcp.xml.dsig.internal.dom.ApacheNodeSetData
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.ApacheTransform transformIt
FEIN: Created transform for algorithm: http://www.w3.org/2002/06/xmldsig-filter2
28.01.2009 12:50:20 org.jcp.xml.dsig.internal.dom.ApacheTransform transformIt
FEIN: ApacheData = true
0 [main] INFO org.apache.xml.security.utils.CachedXPathFuncHereAPI - Registering Here function
28.01.2009 12:50:21 org.jcp.xml.dsig.internal.DigesterOutputStream write
FEINER: Pre-digested input:
28.01.2009 12:50:21 org.jcp.xml.dsig.internal.DigesterOutputStream write
FEINER: <tbone>
<license>
<param name="myparam">Test</param>
</license>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"></CanonicalizationMethod><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"><XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" Filter="union">/tbone/license</XPath></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod><DigestValue>cp68+Em7EAO6X62j+kw7a8T08qU=</DigestValue></Reference></SignedInfo><SignatureValue>TH3tGkUs0Pnzgzb74OjVjqkrZA/9LqBaC4ZzrPrFevsdPBl94XFKg3hPdofLBdFkvb+vkYb9T9TT
0436m+aQOnC6Y9pwk7lCKYPvbPeZcwCwUCFa7ccGh0jGSyp83QgBI6eqomWkaI8xq56WjgcvXKiv
JvZ4sh7QsdQp3dw2q84=</SignatureValue><KeyInfo><KeyName>My Keyname</KeyName></KeyInfo></Signature></tbone>
28.01.2009 12:50:21 org.jcp.xml.dsig.internal.dom.DOMReference validate
FEIN: Expected digest: cp68+Em7EAO6X62j+kw7a8T08qU=
28.01.2009 12:50:21 org.jcp.xml.dsig.internal.dom.DOMReference validate
FEIN: Actual digest: P1nwaETN2vl9o4U4FSRVdb6U0Sc=
28.01.2009 12:50:21 org.jcp.xml.dsig.internal.dom.DOMXMLSignature validate
FEIN: Reference[] is valid: false
28.01.2009 12:50:21 org.jcp.xml.dsig.internal.dom.DOMXMLSignature validate
FEIN: Couldn't validate the References
This forum post hinted at a possible namespace problem
http://forums.java.net/jive/message.jspa?messageID=37326
but im not sure - because i dont see the suggested 2 pre-digests output.
--- On Tue, 1/27/09, Sean Mullan <Se...@Sun.COM> wrote:
> From: Sean Mullan <Se...@Sun.COM>
> Subject: Re: Invalid Signature problem through Empty elements are converted to start-end tag pairs
> To: security-dev@xml.apache.org
> Date: Tuesday, January 27, 2009, 2:49 PM
> Harakiri wrote:
> > We created signatures using the SUN XML Signature APIs
> in JRE 5 Versions.
>
> Hmm, which APIs are those? What software are you using?
> Have you tried JRE 6 to see if the problem still exists?
>
> > Due to a bug in SUNs API we like to use the XML
> Security API from Apache.
> >
> > However, all our signatures are invalid through
> possibly a bug in java.
> >
> > The signatures have been created with the following:
> >
> > http://www.w3.org/TR/2001/REC-xml-c14n-20010315
> >
> > however it seems that java signed empty tags as:
> >
> > <param name="myparam"/>
> >
> > but apache security correctly validates as
> >
> > <param name="myparam"></param>
> >
> > Since i cant just change existing signatures, how can
> I modify the apache xmldsig validation so that it will not
> compute the hash over the empty tags as
> <param></param> but as <param/> ?
>
> You can't, as Scott notes. Well, you could hack up the
> code yourself and build your own library but then you would
> just be bug-compatible. The existing signatures would still
> not interoperate with other vendors.
>
> Sorry, but I think your only solution may be to regenerate
> the signatures.
>
> --Sean
Re: Invalid Signature problem through Empty elements are converted to
start-end tag pairs
Posted by Sean Mullan <Se...@Sun.COM>.
Harakiri wrote:
> We created signatures using the SUN XML Signature APIs in JRE 5 Versions.
Hmm, which APIs are those? What software are you using?
Have you tried JRE 6 to see if the problem still exists?
> Due to a bug in SUNs API we like to use the XML Security API from Apache.
>
> However, all our signatures are invalid through possibly a bug in java.
>
> The signatures have been created with the following:
>
> http://www.w3.org/TR/2001/REC-xml-c14n-20010315
>
> however it seems that java signed empty tags as:
>
> <param name="myparam"/>
>
> but apache security correctly validates as
>
> <param name="myparam"></param>
>
> Since i cant just change existing signatures, how can I modify the apache xmldsig validation so that it will not compute the hash over the empty tags as <param></param> but as <param/> ?
You can't, as Scott notes. Well, you could hack up the code yourself and build
your own library but then you would just be bug-compatible. The existing
signatures would still not interoperate with other vendors.
Sorry, but I think your only solution may be to regenerate the signatures.
--Sean
RE: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Harakiri <ha...@yahoo.com>.
Hello,
thanks i knew this - i used this debugging tip here :
http://weblogs.java.net/blog/mullan/archive/2007/08/index.html
and saw the SignedInfo.getCanonicalizedData information.
It is possible that this is not the issue i have, because i havent figured out how to debug the actual signed data with the SUN APIs. I thought i could apply the Reference.getDigestInputStream hint to the SUN Apis to see what bytes have been signed, but that didnt work.
--- On Tue, 1/27/09, Jesse Pelton <js...@PKC.com> wrote:
> From: Jesse Pelton <js...@PKC.com>
> Subject: RE: Invalid Signature problem through Empty elements are converted to start-end tag pairs
> To: security-dev@xml.apache.org
> Date: Tuesday, January 27, 2009, 2:54 PM
> In case it isn't obvious (it wasn't to me at first),
> the fact that an
> element appears as "<param/>" in the signed
> document does not mean those
> are the bytes that were used in generating the signature.
> The point of
> canonicalization is that a canonical form of the document
> is used to
> calculate the hash, but the document that contains the
> resulting
> signature may not be (and generally is not) rewritten in
> canonical form.
>
> Put differently, the canonicalized document is a temporary
> copy.
>
> Sorry if you already knew this. Since you said "it
> seems that java
> signed empty tags" a certain way, not that you were
> certain this is the
> case, I thought it worth pointing out that this might not
> in fact be the
> problem.
>
> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, January 27, 2009 2:31 PM
> To: security-dev@xml.apache.org
> Subject: RE: Invalid Signature problem through Empty
> elements are
> converted to start-end tag pairs
>
> Harakiri wrote on 2009-01-27:
> > however it seems that java signed empty tags as:
> >
> > <param name="myparam"/>
> >
> > but apache security correctly validates as
> >
> > <param name="myparam"></param>
> >
> > Since i cant just change existing signatures, how can
> I modify the
> apache
> > xmldsig validation so that it will not compute the
> hash over the empty
> tags
> > as <param></param> but as <param/> ?
>
> If you're using c14n (either version) as defined today,
> the signature
> digest
> is over the <tag></tag> form, not the other
> form. That's part of c14n. I
> doubt what you're using is really doing that wrong,
> unless it's one-off
> signing code that isn't interoperable at all.
>
> But you can't make Apache's code do this wrong, no.
>
> -- Scott
RE: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Jesse Pelton <js...@PKC.com>.
In case it isn't obvious (it wasn't to me at first), the fact that an
element appears as "<param/>" in the signed document does not mean those
are the bytes that were used in generating the signature. The point of
canonicalization is that a canonical form of the document is used to
calculate the hash, but the document that contains the resulting
signature may not be (and generally is not) rewritten in canonical form.
Put differently, the canonicalized document is a temporary copy.
Sorry if you already knew this. Since you said "it seems that java
signed empty tags" a certain way, not that you were certain this is the
case, I thought it worth pointing out that this might not in fact be the
problem.
-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Tuesday, January 27, 2009 2:31 PM
To: security-dev@xml.apache.org
Subject: RE: Invalid Signature problem through Empty elements are
converted to start-end tag pairs
Harakiri wrote on 2009-01-27:
> however it seems that java signed empty tags as:
>
> <param name="myparam"/>
>
> but apache security correctly validates as
>
> <param name="myparam"></param>
>
> Since i cant just change existing signatures, how can I modify the
apache
> xmldsig validation so that it will not compute the hash over the empty
tags
> as <param></param> but as <param/> ?
If you're using c14n (either version) as defined today, the signature
digest
is over the <tag></tag> form, not the other form. That's part of c14n. I
doubt what you're using is really doing that wrong, unless it's one-off
signing code that isn't interoperable at all.
But you can't make Apache's code do this wrong, no.
-- Scott
RE: Invalid Signature problem through Empty elements are converted to start-end tag pairs
Posted by Scott Cantor <ca...@osu.edu>.
Harakiri wrote on 2009-01-27:
> however it seems that java signed empty tags as:
>
> <param name="myparam"/>
>
> but apache security correctly validates as
>
> <param name="myparam"></param>
>
> Since i cant just change existing signatures, how can I modify the apache
> xmldsig validation so that it will not compute the hash over the empty
tags
> as <param></param> but as <param/> ?
If you're using c14n (either version) as defined today, the signature digest
is over the <tag></tag> form, not the other form. That's part of c14n. I
doubt what you're using is really doing that wrong, unless it's one-off
signing code that isn't interoperable at all.
But you can't make Apache's code do this wrong, no.
-- Scott