Groupe Jean Coutu (PJC) Inc.
tél: 450-463-1890 (3363)
fax: 450-646-0567
[EMAIL PROTECTED]
Brent Putman <[EMAIL PROTECTED]>
27/05/2008 06:10 PM
A
Jean-Charles Laurent <[EMAIL PROTECTED]>,
security-dev@xml.apache.org
cc
Objet
Re: question
(Please hit reply-to-all when you r
(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
IL GON KIM wrote:
I am studying on WS-Security and have a question about it.
As far as I understand it, WS-Security defines security elements in
header part of the SOAP messages, by combining WS-Signature and
WS-Encryption standards.
I think it is possible to define security elements in body
You will have to look at the feasibility of putting
everything in the body as well as achieving SOAP
intermediary functionality.
WS-Security is an elegant and generalized solution.
The concept of security tokens pertains to username ,
X.509, or SAML tokens. For encryption, having
EncryptedKey sepa
Davanum Srinivas wrote:
my 2 cents, whatever is in the soap body is destined for the
application that consumes/needs the soap request/response. the header
is a location where intermediate nodes or the soap engine(s) at the
end can add custom information independent of the application that
sends/
my 2 cents, whatever is in the soap body is destined for the
application that consumes/needs the soap request/response. the header
is a location where intermediate nodes or the soap engine(s) at the
end can add custom information independent of the application that
sends/receives the soap request/r
urity-dev@xml.apache.org
Subject: RE: question on data directory
Sorry for not making myself very clear.
I'm using xml-security-bin-1_2_1.zip.
xml-security-1_2_1/src_samples/org/apache/xml/security/samples/signature
When I run the samples in the above directory (eg CreateSignature.java)
...
TED]
Sent: Saturday, August 13, 2005 12:59 PM
To: security-dev@xml.apache.org
Subject: Re: question on data directory
Anthony,
this list discusses two libraries implementing standards
concerning signature and encryption of XML documents.
One java and one C++ library.
AFAIK there is no obvious
Anthony,
this list discusses two libraries implementing standards
concerning signature and encryption of XML documents.
One java and one C++ library.
AFAIK there is no obvious executable. Neither any preset data
directroy is to be found.
Perhaps you confused the mailing lists? Or are you workin
> All,
>
> a question to the c14 gurus on the list.
>
> I set up an Element node and set the default namespace
> to "" using the following code:
>
>elem.setAttributeNS(WSConstants.XMLNS_NS, "xmlns", "");
>
> This seems to work.
>
> The element is c14n'ed using the following code:
>
>XMLUtil
steel scorpion wrote:
From: Erwin van der Koogh <[EMAIL PROTECTED]>
Somewhere in your code you have a reference to a particular ID, but
it's not always possible to see what attributes are of type ID. To
Not sure I understand this completely. Does this mean that, from a
parser/resolver point of
From: Erwin van der Koogh <[EMAIL PROTECTED]>
Somewhere in your code you have a reference to a particular ID, but it's
not always possible to see what attributes are of type ID. To
Not sure I understand this completely. Does this mean that, from a
parser/resolver point of view, it is impossible t
When I sign or open a signed XML document, I see the following warning
messages:
Apr 27, 2004 3:40:53 PM org.apache.xml.security.utils.IdResolver
getElementById
WARNING: Found an Element using an insecure Id/ID/id search method:
claim:MemberID
...
What does that mean exactly?
Somewhere in your
One of the really cool things about c14n is it doesn't necessarily
result in valid XML .
C14n takes as an input a node-set, which may not be a complete XML
document. That means you can use it to canonicalise only the data in
the document that you are interested in signing.
As an example - if
> Sean,
> Update the junit test result -
> http://nagoya.apache.org/~dims/xmlsec-junit/. Here's my config.xml
> http://nagoya.apache.org/~dims/xmlsec-junit/config.xml. Results are
> just slightly better.
>
> Can you please update config.xml and send us something that passes all
> the tests?
OK -
Sean,
Update the junit test result - http://nagoya.apache.org/~dims/xmlsec-junit/. Here's my
config.xml
http://nagoya.apache.org/~dims/xmlsec-junit/config.xml. Results are just slightly
better.
Can you please update config.xml and send us something that passes all the tests?
thanks,
dims
---
Here are the missing algorithms, please update config.xml
and rerun the tests:
MessageDigest: Provider "SUN" supports MD5, SHA-256, SHA-384, & SHA-512
Signature: Provider "SunJSSE" supports MD5withRSA, SHA1withRSA
MAC: Provider "SunJCE" supports HmacMD5, HmacSHA256, HmacSHA384, HmacSHA512
We do
I'll look into these failures and get back to you. The signature algorithms definitely
should all work - my guess is it is likely a config problem.
Thanks,
Sean
Davanum Srinivas wrote:
Sean, Berin,
Done. Here's the updated JDK1.5 run after commenting out lib.jce from classpath.libraries.
-- dims
Sean, Berin,
Done. Here's the updated JDK1.5 run after commenting out lib.jce from
classpath.libraries.
-- dims
--- Berin Lautenbach <[EMAIL PROTECTED]> wrote:
> Just looked in more detail - you also need to install the strong crypto
> policy files.
>
> Cheers,
> Berin
>
> Davanum Srin
Just looked in more detail - you also need to install the strong crypto
policy files.
Cheers,
Berin
Davanum Srinivas wrote:
Sean,
Here's my run with JDK1.5 with BC commented out:
http://nagoya.apache.org/~dims/xmlsec-junit/
-- dims
--- Berin Lautenbach <[EMAIL PROTECTED]> wrote:
Sean,
Hmm. Interesting - must have a look at the signature stuff. I am
currently only trying encryption.
Davanum Srinivas wrote:
Sean,
Here's my run with JDK1.5 with BC commented out:
http://nagoya.apache.org/~dims/xmlsec-junit/
-- dims
--- Berin Lautenbach <[EMAIL PROTECTED]> wrote:
Sean,
test_
Sean,
Here's my run with JDK1.5 with BC commented out:
http://nagoya.apache.org/~dims/xmlsec-junit/
-- dims
--- Berin Lautenbach <[EMAIL PROTECTED]> wrote:
> Sean,
>
> test_five_content_aes128_cbc_kw_aes192
> test_five_content_3des_cbc_kw_aes128
> test_five_data_aes256_cbc_3des
> test_five_data
Sean,
test_five_content_aes128_cbc_kw_aes192
test_five_content_3des_cbc_kw_aes128
test_five_data_aes256_cbc_3des
test_five_data_aes192_cbc_aes256
Basically any interop test where a symmetric key wrap is used. The
wrap/unwrap tests work, which leads me to believe that I am calling
using the wron
Can you tell me which test vectors are failing?
--Sean
Berin Lautenbach wrote:
Peoples,
I have just checked in a new version of config.xml that works for most
encryption algorithms under SunJCE (have not yet checked sig).
One question - I am having issues with symmetric key wraps. The
Baltim
25 matches
Mail list logo
