You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Anais <la...@hotmail.com> on 2008/08/11 16:26:40 UTC
how sign an xml file ?
Hi,
I'm a newbie in xml signature. I have look at the example : templatesign in
order to sign a xml file with a key in a PEM file but i have the error :
could not find <signature> node
I don't undestand why a <signature> node is requiered because my first file
can't have this node.
In the future i would like to make multiple signature and sign pdf files.
Thanks
--
View this message in context: http://www.nabble.com/how-sign-an-xml-file---tp18926885p18926885.html
Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
RE: how sign an xml file ?
Posted by Scott Cantor <ca...@osu.edu>.
> Thanks for answer.
> I use c++ librairy.
> I just want to know how create a signature node in a xml file ?
Have you looked at the API documentation or any of the test programs that
come with it?
-- Scott
Re: how sign an xml file ?
Posted by Anais <la...@hotmail.com>.
Hi,
Thanks for answer.
I use c++ librairy.
I just want to know how create a signature node in a xml file ?
Nanis.
edward.thompson wrote:
>
> I don't understand your question. If you are signing an XML file, you
> have to create the signature node first:
>
> public static Element signAssertion(Element assertion, Map cred)
> throws Exception {
> Document doc = assertion.getOwnerDocument();
> // somehow the ID attribute is not yet really in the doc
> // so we regsiter the id of interest so the Resolver
> called by sign can
> // find it
> String assertionId =
> assertion.getAttributeNode("ID").toString()
> .substring(4, 37);
> IdResolver.registerElementById(assertion, assertionId);
>
> XMLSignature sig = new XMLSignature(doc, "",
> XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA1,
> Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS);
> assertion.insertBefore(sig.getElement(),
> assertion.getFirstChild());
>
> // create the transforms object for the Document/Reference
> Transforms transforms = new Transforms(doc);
>
> // First we have to strip away the signature element (it's
> not part of
> // the signature calculations). The enveloped transform
> can be used.
> transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE);
> // Part of the signature element needs to be
> canonicalized. It is a kind
> // of normalizing algorithm for XML. For more information
> please take a
> // look at the W3C XML Digital Signature webpage.
> InclusiveNamespaces incNS = new InclusiveNamespaces(doc,
> "ds saml xenc xs");
>
> transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS,
> incNS.getElement());
>
> // Add the above Document/Reference
> sig.addDocument("#" + assertionId, transforms,
> Constants.ALGO_ID_DIGEST_SHA1);
>
> Key privKey = (Key) cred.get("privateKey");
> sig.sign(privKey);
>
> return assertion;
> }
>
> Notice that sig.addDocument is called before the sign()
>
> Not sure if this helps...
>
> Ed
>
>
>
>
> Anais <la...@hotmail.com>
> 08/11/2008 10:26 AM
> Please respond to
> security-dev@xml.apache.org
>
>
> To
> security-dev@xml.apache.org
> cc
>
> Subject
> how sign an xml file ?
>
>
>
>
>
>
>
> Hi,
>
> I'm a newbie in xml signature. I have look at the example : templatesign
> in
> order to sign a xml file with a key in a PEM file but i have the error :
> could not find <signature> node
> I don't undestand why a <signature> node is requiered because my first
> file
> can't have this node.
> In the future i would like to make multiple signature and sign pdf files.
>
> Thanks
> --
> View this message in context:
> http://www.nabble.com/how-sign-an-xml-file---tp18926885p18926885.html
> Sent from the Apache XML - Security - Dev mailing list archive at
> Nabble.com.
>
>
>
>
--
View this message in context: http://www.nabble.com/how-sign-an-xml-file---tp18926885p18958499.html
Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
Re: how sign an xml file ?
Posted by ed...@wachovia.com.
I don't understand your question. If you are signing an XML file, you
have to create the signature node first:
public static Element signAssertion(Element assertion, Map cred)
throws Exception {
Document doc = assertion.getOwnerDocument();
// somehow the ID attribute is not yet really in the doc
// so we regsiter the id of interest so the Resolver
called by sign can
// find it
String assertionId =
assertion.getAttributeNode("ID").toString()
.substring(4, 37);
IdResolver.registerElementById(assertion, assertionId);
XMLSignature sig = new XMLSignature(doc, "",
XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA1,
Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS);
assertion.insertBefore(sig.getElement(),
assertion.getFirstChild());
// create the transforms object for the Document/Reference
Transforms transforms = new Transforms(doc);
// First we have to strip away the signature element (it's
not part of
// the signature calculations). The enveloped transform
can be used.
transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE);
// Part of the signature element needs to be
canonicalized. It is a kind
// of normalizing algorithm for XML. For more information
please take a
// look at the W3C XML Digital Signature webpage.
InclusiveNamespaces incNS = new InclusiveNamespaces(doc,
"ds saml xenc xs");
transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS,
incNS.getElement());
// Add the above Document/Reference
sig.addDocument("#" + assertionId, transforms,
Constants.ALGO_ID_DIGEST_SHA1);
Key privKey = (Key) cred.get("privateKey");
sig.sign(privKey);
return assertion;
}
Notice that sig.addDocument is called before the sign()
Not sure if this helps...
Ed
Anais <la...@hotmail.com>
08/11/2008 10:26 AM
Please respond to
security-dev@xml.apache.org
To
security-dev@xml.apache.org
cc
Subject
how sign an xml file ?
Hi,
I'm a newbie in xml signature. I have look at the example : templatesign
in
order to sign a xml file with a key in a PEM file but i have the error :
could not find <signature> node
I don't undestand why a <signature> node is requiered because my first
file
can't have this node.
In the future i would like to make multiple signature and sign pdf files.
Thanks
--
View this message in context:
http://www.nabble.com/how-sign-an-xml-file---tp18926885p18926885.html
Sent from the Apache XML - Security - Dev mailing list archive at
Nabble.com.
Re: JCEID to Service mapping
Posted by Sean Mullan <Se...@Sun.COM>.
Brent Putman wrote:
> The real test would be if you get different behavior from this:
>
>
> Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding", "BC");
>
> versus this:
>
> Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding");
>
>
> If the first works, but the latter doesn't (throws NoSuchPadding or
> NoSuchAlgorithm exceptions), then that answers the question.
I just tried and both work if you register BC as a provider with Sun's
JDK 1.4.
It sounds as if you are using IBM's JDK though? If so, it may be a bug
in their provider lookup mechanism. I would contact someone from IBM -
they may be able to help debug this further.
> If that proves to be the case: Note that you can specify a particular
> security provider to use in xmlsec for encryption/decryption with the
> XMLCipher#getProviderInstance variants instead of the usual
> XMLCipher#getInstance. That will let you get around whatever preferred
> order lookup behavior might be going on.
Yep, that's always an option if you have control over the code.
--Sean
Re: JCEID to Service mapping
Posted by Brent Putman <pu...@georgetown.edu>.
>
> Hi,
>
> I'm a newbie in xml signature. I have look at the example :
> templatesign in order to sign a xml file with a key in a PEM file but
> i have the error : could not find <signature> node
> I don't undestand why a <signature> node is requiered because my first
> file can't have this node.
> In the future i would like to make multiple signature and sign pdf files.
>
> Thanks
Anais wrote:
> ok that's good for you but nobody can help me about my xml signature ?
>
> Thanks
>
>
I'd be happy to help if I could, but I'm not really sure what you are
doing or what asking. It would be more helpful if you could provide
more details of what your code is trying to do, or distill it down to
more specific questions. Also not clear on whether you are using the
Java or C++ versions of the library - although I now see
templatesign.cpp in the C++ tree, so I assume the latter?
But to try and answer what you did ask: in order to sign something with
XML Signature, you have to one way or another create a ds:Signature
node, either in your existing document for an enveloped or enveloping
signature, or possibly in another document if you're doing a detached
signature, than then populate it with the relevant information.
I'm not familiar with templatesign tool, but looks like that tool works
by you feeding it a file with an semi-empty ds:Signature element and it
computes and adds the relevant digest values for the References and and
then the actual SignatureValue for the Signature. Not sure exactly what
you have to supply there, though, I don't see much in the way of docs,
unless I'm overlooking.
In any event, you have to know some of the basics of XML Signature in
order to supply the right bits for that tool. If you haven't done so,
I'd suggest taking a look at the XML Signature spec to get a sense of
what it does and how it works.
--Brent
Re: JCEID to Service mapping
Posted by Anais <la...@hotmail.com>.
ok that's good for you but nobody can help me about my xml signature ?
Thanks
Brent Putman wrote:
>
>
>
> edward.thompson@wachovia.com wrote:
>>
>> Very helpful information guys, thanx...
>>
>> I am using bouncycastle, which should handle ISO10126 padding even in
>> 1.4 though, right?
>
> Yes, I believe so, although I haven't tried it. But that's the whole
> point of the extensible security provider framework.
>
>
>> The issue then becomes, why isn't it finding the bouncycastle provider
>> under 1.4 like it does under 1.5.
>>
>> I dump the providers and it is there, it just isn't being select (by
>> Cipher?) like it is under 1.5.
>>
>> [2008-08-11 16:22:33,367] DEBUG: Provider=IBMJCE version
>> 1.2:PBEWithSHA-1And128BitRC4
>> ...
>> [2008-08-11 16:22:33,368] DEBUG: Provider=IBMJCE version 1.2:AES
>> ...
>> [2008-08-11 16:22:33,372] DEBUG: Provider=BC version
>> 1.4:RSA//ISO9796-1PADDING
>> ...
>> [2008-08-11 16:22:33,374] DEBUG: Provider=BC version 1.4:AES <<<<
>> target, based on sucessful trace
>> ...
>> [2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:DES
>> [2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version
>> 1.42:PBEWithMD5AndTripleDES
>> [2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:AES
>> ...
>
>
> I'm not sure. Assuming you're loading the providers in the same
> relative order in 1.4 and 1.5: Maybe the provider lookup behavior in
> java.security.Security is different in 1.4 vs. 1.5? Maybe Sean knows.
> Where are you loading the BC provider in the provider list relative to
> the IBMJCE one? If you're loading it after the IBM one, maybe the
> lookup behavior is such that it resolves the
> java.security.Provider.Service (type=Cipher) based only on the algorithm
> (AES) or possibly algorithm + mode (CBC). Then the IBM provider service
> impl gets resolved first, but then doesn't support the padding.
>
> The real test would be if you get different behavior from this:
>
>
> Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding",
> "BC");
>
> versus this:
>
> Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding");
>
>
> If the first works, but the latter doesn't (throws NoSuchPadding or
> NoSuchAlgorithm exceptions), then that answers the question.
>
>
> If that proves to be the case: Note that you can specify a particular
> security provider to use in xmlsec for encryption/decryption with the
> XMLCipher#getProviderInstance variants instead of the usual
> XMLCipher#getInstance. That will let you get around whatever preferred
> order lookup behavior might be going on.
>
> --Brent
>
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/how-sign-an-xml-file---tp18926885p18938866.html
Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
Re: JCEID to Service mapping
Posted by Brent Putman <pu...@georgetown.edu>.
edward.thompson@wachovia.com wrote:
>
> Very helpful information guys, thanx...
>
> I am using bouncycastle, which should handle ISO10126 padding even in
> 1.4 though, right?
Yes, I believe so, although I haven't tried it. But that's the whole
point of the extensible security provider framework.
> The issue then becomes, why isn't it finding the bouncycastle provider
> under 1.4 like it does under 1.5.
>
> I dump the providers and it is there, it just isn't being select (by
> Cipher?) like it is under 1.5.
>
> [2008-08-11 16:22:33,367] DEBUG: Provider=IBMJCE version
> 1.2:PBEWithSHA-1And128BitRC4
> ...
> [2008-08-11 16:22:33,368] DEBUG: Provider=IBMJCE version 1.2:AES
> ...
> [2008-08-11 16:22:33,372] DEBUG: Provider=BC version
> 1.4:RSA//ISO9796-1PADDING
> ...
> [2008-08-11 16:22:33,374] DEBUG: Provider=BC version 1.4:AES <<<<
> target, based on sucessful trace
> ...
> [2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:DES
> [2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version
> 1.42:PBEWithMD5AndTripleDES
> [2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:AES
> ...
I'm not sure. Assuming you're loading the providers in the same
relative order in 1.4 and 1.5: Maybe the provider lookup behavior in
java.security.Security is different in 1.4 vs. 1.5? Maybe Sean knows.
Where are you loading the BC provider in the provider list relative to
the IBMJCE one? If you're loading it after the IBM one, maybe the
lookup behavior is such that it resolves the
java.security.Provider.Service (type=Cipher) based only on the algorithm
(AES) or possibly algorithm + mode (CBC). Then the IBM provider service
impl gets resolved first, but then doesn't support the padding.
The real test would be if you get different behavior from this:
Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding", "BC");
versus this:
Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding");
If the first works, but the latter doesn't (throws NoSuchPadding or
NoSuchAlgorithm exceptions), then that answers the question.
If that proves to be the case: Note that you can specify a particular
security provider to use in xmlsec for encryption/decryption with the
XMLCipher#getProviderInstance variants instead of the usual
XMLCipher#getInstance. That will let you get around whatever preferred
order lookup behavior might be going on.
--Brent
Re: JCEID to Service mapping
Posted by ed...@wachovia.com.
Very helpful information guys, thanx...
I am using bouncycastle, which should handle ISO10126 padding even in 1.4
though, right?
The issue then becomes, why isn't it finding the bouncycastle provider
under 1.4 like it does under 1.5.
I dump the providers and it is there, it just isn't being select (by
Cipher?) like it is under 1.5.
[2008-08-11 16:22:33,367] DEBUG: Provider=IBMJCE version
1.2:PBEWithSHA-1And128BitRC4
...
[2008-08-11 16:22:33,368] DEBUG: Provider=IBMJCE version 1.2:AES
...
[2008-08-11 16:22:33,372] DEBUG: Provider=BC version
1.4:RSA//ISO9796-1PADDING
...
[2008-08-11 16:22:33,374] DEBUG: Provider=BC version 1.4:AES <<<<
target, based on sucessful trace
...
[2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:DES
[2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version
1.42:PBEWithMD5AndTripleDES
[2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:AES
...
This list is the same in 1.4 and 1.5 traces.
Edward Thompson
Sean Mullan <Se...@Sun.COM>
Sent by: Sean.Mullan@Sun.COM
08/11/2008 04:27 PM
Please respond to
security-dev@xml.apache.org
To
security-dev@xml.apache.org
cc
Subject
Re: JCEID to Service mapping
Brent Putman wrote:
> The JCEID algorithm identifier gets looked up by the relevant security
> provider class (e.g. Cipher), and is based on all 3 parameters: the
> cipher, mode and padding.
>
> This is highly platform vendor and version specific but as far as I
> remember, support for the ISO10126 padding for XML Encryption was only
> available in later versions of the default provider stacks that ships
> with the Java runtimes. With Sun's, for example, I believe 1.4 did
> *not* include support for that padding.
This is correct. It is available in JDK 1.5 and up.
> 1.5 does now, although not sure
> about the initial patch revs. I seem to remember we had an issue in
> our project with someone using IBM's 1.5 JRE about a year and a half
> ago, and at that time they did not support that padding in the
> then-current rev of 1.5. Not sure about now. In their 1.4 I'm guessing
> most likely not supported either.
I believe that is also correct (1.5 and up).
BTW, I believe if you encode (or maybe its the other way around, I can't
remember for sure) with PKCS5Padding and decode with ISO10126Padding, it
is ok. It is only the other way around that you get problems. This might
work if the application that encrypts cannot be upgraded (encode with
JDK 1.4 and PKCS5Padding and decode with JDK 1.5 and ISO10126Padding),
although you would have to tweak the algorithm URI mappings in
config.xml to use PKCS5Padding instead.
--Sean
> If you can use recent Bouncy Castle security provider, that should get
> you support for that padding (and larger AES encryption keys) for any of
> the runtime platforms. FYI, depending on what other crypto things
> you're doing, you may have to fiddle with the registered order of the
> providers in order to get everything to work as expected.
>
> --Brent
>
>
> edward.thompson@wachovia.com wrote:
>>
>> This isn't technically an XML Security issue, I know, but any help
>> appreciated.
>>
>> Under Java 1.5 when I try to create a, XMLCipher, XMLCipher.AES_128 is
>> mapped to a JCEID of AES/CBC/ISO10126Padding , whihc is then mapped to
>> a bouncycastle service of AES. All is well.
>>
>> Under Java 1.4, XMLCipher.AES_128 is mapped to a JCEID of
>> AES/CBC/ISO10126Padding, but no service provider can be found with
>> trhat JCEID, even though I can dump the service providers and see 3
>> AES providers.
>>
>> When I say under 1.5/1.4, its actually Websphere 6.0 (which uses 1.4)
>> and 6.1 (whihc uses 1.5). I am going to try to isolate the code
>> outside of websphere to see if the behavior chnages, but trying to
>> understand what maps AES/CBC/ISO10126Padding to a service...
>>
>> Ed Thompson
>>
>>
Re: JCEID to Service mapping
Posted by Sean Mullan <Se...@Sun.COM>.
Brent Putman wrote:
> The JCEID algorithm identifier gets looked up by the relevant security
> provider class (e.g. Cipher), and is based on all 3 parameters: the
> cipher, mode and padding.
>
> This is highly platform vendor and version specific but as far as I
> remember, support for the ISO10126 padding for XML Encryption was only
> available in later versions of the default provider stacks that ships
> with the Java runtimes. With Sun's, for example, I believe 1.4 did
> *not* include support for that padding.
This is correct. It is available in JDK 1.5 and up.
> 1.5 does now, although not sure
> about the initial patch revs. I seem to remember we had an issue in
> our project with someone using IBM's 1.5 JRE about a year and a half
> ago, and at that time they did not support that padding in the
> then-current rev of 1.5. Not sure about now. In their 1.4 I'm guessing
> most likely not supported either.
I believe that is also correct (1.5 and up).
BTW, I believe if you encode (or maybe its the other way around, I can't
remember for sure) with PKCS5Padding and decode with ISO10126Padding, it
is ok. It is only the other way around that you get problems. This might
work if the application that encrypts cannot be upgraded (encode with
JDK 1.4 and PKCS5Padding and decode with JDK 1.5 and ISO10126Padding),
although you would have to tweak the algorithm URI mappings in
config.xml to use PKCS5Padding instead.
--Sean
> If you can use recent Bouncy Castle security provider, that should get
> you support for that padding (and larger AES encryption keys) for any of
> the runtime platforms. FYI, depending on what other crypto things
> you're doing, you may have to fiddle with the registered order of the
> providers in order to get everything to work as expected.
>
> --Brent
>
>
> edward.thompson@wachovia.com wrote:
>>
>> This isn't technically an XML Security issue, I know, but any help
>> appreciated.
>>
>> Under Java 1.5 when I try to create a, XMLCipher, XMLCipher.AES_128 is
>> mapped to a JCEID of AES/CBC/ISO10126Padding , whihc is then mapped to
>> a bouncycastle service of AES. All is well.
>>
>> Under Java 1.4, XMLCipher.AES_128 is mapped to a JCEID of
>> AES/CBC/ISO10126Padding, but no service provider can be found with
>> trhat JCEID, even though I can dump the service providers and see 3
>> AES providers.
>>
>> When I say under 1.5/1.4, its actually Websphere 6.0 (which uses 1.4)
>> and 6.1 (whihc uses 1.5). I am going to try to isolate the code
>> outside of websphere to see if the behavior chnages, but trying to
>> understand what maps AES/CBC/ISO10126Padding to a service...
>>
>> Ed Thompson
>>
>>
Re: JCEID to Service mapping
Posted by Brent Putman <pu...@georgetown.edu>.
The JCEID algorithm identifier gets looked up by the relevant security
provider class (e.g. Cipher), and is based on all 3 parameters: the
cipher, mode and padding.
This is highly platform vendor and version specific but as far as I
remember, support for the ISO10126 padding for XML Encryption was only
available in later versions of the default provider stacks that ships
with the Java runtimes. With Sun's, for example, I believe 1.4 did
*not* include support for that padding. 1.5 does now, although not sure
about the initial patch revs. I seem to remember we had an issue in
our project with someone using IBM's 1.5 JRE about a year and a half
ago, and at that time they did not support that padding in the
then-current rev of 1.5. Not sure about now. In their 1.4 I'm guessing
most likely not supported either.
If you can use recent Bouncy Castle security provider, that should get
you support for that padding (and larger AES encryption keys) for any of
the runtime platforms. FYI, depending on what other crypto things
you're doing, you may have to fiddle with the registered order of the
providers in order to get everything to work as expected.
--Brent
edward.thompson@wachovia.com wrote:
>
> This isn't technically an XML Security issue, I know, but any help
> appreciated.
>
> Under Java 1.5 when I try to create a, XMLCipher, XMLCipher.AES_128 is
> mapped to a JCEID of AES/CBC/ISO10126Padding , whihc is then mapped to
> a bouncycastle service of AES. All is well.
>
> Under Java 1.4, XMLCipher.AES_128 is mapped to a JCEID of
> AES/CBC/ISO10126Padding, but no service provider can be found with
> trhat JCEID, even though I can dump the service providers and see 3
> AES providers.
>
> When I say under 1.5/1.4, its actually Websphere 6.0 (which uses 1.4)
> and 6.1 (whihc uses 1.5). I am going to try to isolate the code
> outside of websphere to see if the behavior chnages, but trying to
> understand what maps AES/CBC/ISO10126Padding to a service...
>
> Ed Thompson
>
>
JCEID to Service mapping
Posted by ed...@wachovia.com.
This isn't technically an XML Security issue, I know, but any help
appreciated.
Under Java 1.5 when I try to create a, XMLCipher, XMLCipher.AES_128 is
mapped to a JCEID of AES/CBC/ISO10126Padding , whihc is then mapped to a
bouncycastle service of AES. All is well.
Under Java 1.4, XMLCipher.AES_128 is mapped to a JCEID of
AES/CBC/ISO10126Padding, but no service provider can be found with trhat
JCEID, even though I can dump the service providers and see 3 AES
providers.
When I say under 1.5/1.4, its actually Websphere 6.0 (which uses 1.4) and
6.1 (whihc uses 1.5). I am going to try to isolate the code outside of
websphere to see if the behavior chnages, but trying to understand what
maps AES/CBC/ISO10126Padding to a service...
Ed Thompson