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 node
I don't undestand why a node is requiered because my first
file can't have this node.
In the future i would like to m
[EMAIL PROTECTED] 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
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
y
use the public key for wrapping and the private key for unwrapping (in the
code private key is pkey).
Sorry for the misunderstanding. I hope you can give me a hand.
Thank you in advance.
Sergio.
Brent Putman wrote:
You have it backwards. You should encrypt/wrap the AES data encryption
key wit
You have it backwards. You should encrypt/wrap the AES data encryption
key with the recipient's *public* key. The recipient then decrypts with
their *private* key.
If you think about the use cases, you'll quickly realize why that is.
--Brent
sermagico wrote:
Hi all,
I try to develop an ap
(Please hit reply-to-all when you reply so that your email goes to the
list and not just to me).
Jean-Charles Laurent wrote:
Hi Brent,
Yes I did write to a file and I validate it with a Java tool (found on
the web) or with a Java program that I got in the sample directory of
xml security
Jean-Charles Laurent wrote:
Thanks Brent,
I agree, the removel of line break is not the perfect solution. My
guest would be be some kind of serialization or deserialization problem.
That's probably the most common problem with signatures that fail to
validate after being sent to a remote
en an option to set the
algorithm, though, if it's determined by the key type.
- Dennis
Brent Putman wrote:
Well, it appears you are in fact trying to use an RSA key:
org.bouncycastle.jce.provider.JCE*RSA*PrivateCrtKey
So that won't work. Realize you do have to have an instance
Well, it appears you are in fact trying to use an RSA key:
org.bouncycastle.jce.provider.JCE*RSA*PrivateCrtKey
So that won't work. Realize you do have to have an instance of a DSA
key to use the DSA signature algorithm.
Are you sure you don't have a typo somewhere when you generated the key
Also, you said "encryption", but the exceptions below seem to indicate
that you are trying to sign, not encrypt.
Jesse Pelton wrote:
Why would you want to encrypt with a private key? Anyone with the
corresponding public key (which is, after all, public) can decrypt the
message, rendering the
Ian Hummel wrote:
signature = new XMLSignature(signatureElement,
System.getProperty("java.io.tmpdir"));
That second arg doesn't look right, it's the base URI for resolving
relative URI references. The examples you saw may have that because
they were signing files that live
Well, it's undocumented AFAIK, so I don't know if this is considered
"stable", but: You can set a system property
"org.apache.xml.security.resource.config", prior to calling
Init.init(), which controls which resource is loaded as the config file.
Here's the code from Init which does the actua
Brent Putman wrote:
>
>
> Scott Cantor wrote:
>
>
> I was just about to send this out, but Scott beat me to it. :-)
> Here's where that code comes from:
>
> http://svn.middleware.georgetown.edu/view/trunk/src/org/opensaml/xml/util/XMLHelper.java?root=java-xmltoo
Scott Cantor wrote:
>
>> You don't happen to have a code snippet around that does exactly that
>> (Java)?
>>
>
> I don't do Java any more (see headache above). The xmltooling code underneath
> opensaml-j, which I didn’t write, has helper routines that provide one way to
> do it, and th
rlyders wrote:
Once the element has been encrypted and signed, the result is shown below.
The web service that we are integrating with is not a full fledged SOAP WSDL
web service, but rather it simply uses HTTPS and XML. Our existing XML
document format where the XML Signature is enclosed by t
Brent Putman wrote:
>
>
> I don't see how it could be getting the two KeyInfo's confused. All the
> Apache EncryptedData.getKeyInfo() does is return a data member, it
> doesn't do any searching or resolution.
>
>
>
>
Hi,
I'm not completely clear on what you're doing, but it sounds like at a
minimum you're perhaps doing something that's not legal. More below.
rlyders wrote:
> Brent,
> Your comments lead me to debug the XMCipher java class to find out that my
> enveloped Signature is confusing the default decry
Hi Wolfgang,
Since it's falling into the code branch in decryptToByteArray(Element)
that indicates that you did not specify a data decryption key to
XMLCipher#init(int, Key), then I assume you want to use an EncryptedKey
to carry the carry the data decryption key and that you want the library
to ha
Hi Wolfgang,
This is great, thanks a lot. I posted a link to the Bugzilla entry over
on our OpenSAML users list, hopefully the user who was interested will
give it a go.
I had some comments about the ID resolution, I'll put those in the Bugzilla.
Thanks,
Brent
Wolfgang Glas wrote:
>
>
> Hi B
One of our OpenSAML users was inquiring about support for verifying
signatures with XPointer References. His specific use case was:
URI="#xpointer(/*[local-name()='Envelope']/*[local-name()='Header']/*[local-name()='Security']/*[local-name()='Assertion'][1])"
>From looking at the code, it seems
Sean Mullan wrote:
>
> Yes, that should be fixed. It is not the same problem as the xalan
> workaround which copies all the namespaces to every element in the doc.
> I think the problem is in XMLUtils.createElementInSignatureSpace. It
> really should only set the namespace attribute if it is the
Raul Benito wrote:
> Can you post an example of the behaviour (a code and an output)?
>
Ok, here is a little test program I wrote. It's not OpenSAML-based,
it's just straight DOM-based code. Parses the assertion.xml and signs
the saml:Assertion, using enveloped and exclusive c14n on the single
Scott Cantor wrote:
>
> Alright, then there's another case in which the namespaces appear, these are
> nothing but enveloped + excl c14n.
>
> -- Scott
>
>
To add to what Scott said: I did a quick test and this also happens with
detached signatures with an external URI reference (so no envelop
When I generate a signature using XMLSignature, the library is
redundantly adding the signature namespace declaration on every child
element of the ds:Signature element. Is there any way that this
behavior can be avoided or turned off? Am I doing something wrong? I
looked in the docs, I couldn't
>>
>>
>> The system configuration versioning is limited by an application
>> server and is:
>>
>>
>>
>> JDK 1.4.11
>>
>> XML Apache Security Library 1.2.0 with xmlsec-1.2.96.jar
>>
>
>
> Pretty sure that version is too old to have the SAML 1.1 support
> described. If you can't upgrade to a ne
Phillip Duba wrote:
>
> Hopefully someone can point me in the right direction to solve this
> problem. I have a SAML 1.1 Assertion being verified, however, it fails
> verification as I receive a “Cannot resolve element with ID …” error.
> The issue arises, from what I can tell doing a Google sear
Sean Mullan wrote:
> Oops, you're right I missed that. I have updated it to use the length of
> the namespaces array, please check it.
>
>
I tested it. It seems to correctly resolve all three SAML 1.x ID types
now. Thanks for fixing.
--Brent
>
> The IdResolver should be modified to include this namespace URI in the array
> at
> line 164, and the code at line 266 should be updated to differentiate the 2
> namespaces.
>
>
Thanks for looking at this. With the above, I didn't mean to imply
those line references were the *only* thin
28 matches
Mail list logo
