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
I have been trying to sign an XML file using the apache security package.
I seem to be able to verify the signature on my side but it cannot be
verified on the client side. What I can explain is why the
CanonicalizationMethod Algorithim is
"http://www.w3.org/TR/2001/REC-xml-c14n-2001031
response!
Ulrich
-Ursprüngliche Nachricht-
Von: security-dev@xml.apache.org
Gesendet: 22.06.07 14:51:02
An: security-dev@xml.apache.org
Betreff: Re: Interop question
Hi Ulrich,
It's probably a c14n issue. What you should do is enable logging on each
side, and then compare the canonica
on in
JDK 6 or XMLSec 1.4.1, which is more up to date.
--Sean
Ulrich Ackermann wrote:
> Hi all,
>
> I have got a question concerning the interoperability between the
> Apache XML Security framework (we are currently using the version
> 1.3.0) and the Sun implementation of XML DS
Hi all,
I have got a question concerning the interoperability between the Apache XML
Security framework (we are currently using the version 1.3.0) and the Sun
implementation of XML DSIG (Java XML Digital Signature API, 1.0 EA2).
Currently we are running into problems because the opposite
ation.
Thanks again for all the help.
Regards Dominik
> -Ursprüngliche Nachricht-
> Von: security-dev@xml.apache.org
> Gesendet: 08.12.06 14:57:41
> An: security-dev@xml.apache.org
> Betreff: Re: Basic hash value question
> Hello Raul,
>
> I'm not quite
Hello Raul,
I'm not quite sure if I understood your question right. There was no signing
and transforming involved outside the code I posted. I just took the Base64
encoded String and converted it into a hex String to show, that it matched the
result Dominik got from the CrypTool.
Maybe
ou expected:
hexFromBase64 = a19308142f1b7720db1787b8d90176ba0afedf43
Cheers,
Ulrich
-Ursprüngliche Nachricht-
Von: security-dev@xml.apache.org
Gesendet: 06.12.06 21:45:05
An: security-dev@xml.apache.org
Betreff: RE: Basic hash value question
Hello again,
Thanks for the answer before. I discovered an online
y-dev@xml.apache.org
Betreff: RE: Basic hash value question
Hello again,
Thanks for the answer before. I discovered an online tool doing exactly what I
wanted: http://www.softwaremaker.net/DotNetApps/B64BytDecHex/index.aspx
After playing around a little bit I discovered a difference in the hash v
correctly? What do I have to
do to make both hash values comparable?
Thanks again! Dominik
> -Ursprüngliche Nachricht-
> Von: security-dev@xml.apache.org
> Gesendet: 06.12.06 00:02:42
> An:
> Betreff: RE: Basic hash value question
> > As far as I understand, the Dige
> As far as I understand, the DigestValue is the base64
> representation of the calculated binary hash value. How can I
> compare this calculated SHA1 hash value with the one
> calculated with a different tool where the hash value looks
> something like 8011 FAB5 3D6D 20D0 E8B5 3F72 00F1 7D81 E
Hello,
I've a basic question about the calculated hash values with Apache XML Security
1.3 (Java). Say I get the following result for a signature calculation (I took
it out of one of the samples):
ds:Reference URI="">
http://www.w3.org/2000/09/xmldsig#sha1";>
F+toCRW
Team,
I had a question about how xmlsec (the standard) processes elements that are
base64 encoded.
Will these two structures be hashed to the same value? Will the encoding
attribute be added to the hash? Will both "6dnN..." payloads be base64
decoded before being processed?
Thanks
Berin Lautenbach <[EMAIL PROTECTED]> writes:
> BTW - Am really glad someone has picked up the debian thing. I had an
> ITP filed for a long time, but I never got around to actually doing the
> packaging.
Did the ITP get closed, or is there still one floating around that I need
to make sure I cat
Scott Cantor wrote:
>>Second, and this is one of those things that doesn't really matter but I
>>promised to at least ask, there were a few Debian developers who responded
>>to my Intent to Package notification who were wondering why the package
>>was called XML-Security-C when it was written in C+
> Second, and this is one of those things that doesn't really matter but I
> promised to at least ask, there were a few Debian developers who responded
> to my Intent to Package notification who were wondering why the package
> was called XML-Security-C when it was written in C++.
Just a guess on
Hello folks,
First, I wanted to introduce myself and mention that I and Quanah
Gibson-Mount are currently working on packaging Shibboleth for Debian and
therefore are also packaging XML-Security-C as a prerequisite. Quanah has
finished a first pass at the packaging and I'm currently working on a
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
functionality even if you have achieved
elegance and generalization.
-rams
> *question 1) * Is there other reasons why
> WS-Security defines
> especially security elments in header part of SOAP
> message.
>
> As I mentioned in an original e-mail, I believe that
> security element
messages, in WS-Security.
*question 1) * Is there other reasons why WS-Security defines
especially security elments in header part of SOAP message.
As I mentioned in an original e-mail, I believe that security element
defined with XML-Signature and XML-Encryption could be located in
either
/response.
-- dims
On 3/14/06, IL GON KIM <[EMAIL PROTECTED]> 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-Encryptio
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 part of the
SOAP
Hi Stefeno,
I think you have hit a bug in the changes I do for xpath between 1.2
and 1.3, do you mind to open a bug report in bugzilla?
Please, attach a test case that shos the bug(This increase the speed
of fix a lot...).
Regards,
On 1/27/06, Berin Lautenbach <[EMAIL PROTECTED]> wrote:
>
> Stef
Stefano Del Sal wrote:
I'm trying to sign a document using the transform TRANSFORM_XPATH2FILTER,
but I get a bad signature if I try to use ONLY the filter
XPath2FilterContainer.SUBTRACT
1) Ex:
String filters[][] = {
{XPath2FilterContainer.SUBTRACT, "//NotToBeSigned"}
};
transforms.ad
I'm trying to sign a document using the transform TRANSFORM_XPATH2FILTER,
but I get a bad signature if I try to use ONLY the filter
XPath2FilterContainer.SUBTRACT
1) Ex:
String filters[][] = {
{XPath2FilterContainer.SUBTRACT, "//NotToBeSigned"}
};
transforms.addTransform(
Transforms.T
there are quite a few oddities with the xml you
posted.
1. security element does not belong to the wsse
namespace
2. username token appears in the body
But, anyway, that does not cause a problem with your
signature verification.
Looking at the keyinfo, it looks like the code will
take a path whe
- Forwarded by Nicholas
G Harlow/Santa Cruz/IBM on 12/15/2005 12:38 PM -
Nicholas G Harlow
12/15/2005 12:33 PM
To:
[EMAIL PROTECTED]
cc:
From:
Nicholas G Harlow/Santa Cruz/[EMAIL PROTECTED]
Subject:
DSig Question
Dear,
Our organization is planning a big project which
is a Linux-Embedded system and will be sold as
products in the market.
It is necessary for us to choose a Xml security
product. From internet, we found your Xml security
product -- Xml-security, and we are very interested in
it, so we
I'm answering my question myself because I found the solution.
There is an OfflineResolver class that can be modified to specify different
data paths.
Anthony Sangha
-Original Message-
From: Anthony Sangha [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 13, 2005 1:42 PM
To: sec
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
I would like to have a different data directory. Currently
the data directory, as I understand, has to be in the path of the executable.
Is there a way to do this?
Anthony Sangha
[EMAIL PROTECTED]
Paul Buhler wrote:
I have what I hope is a simple question. I am trying to sign the
EncryptedData element in an XML document. This element has an id attribute
of "ed1".
If I use a same-document reference URI of "#ed1" I get the desired result;
i.e., the digest is onl
I have what I hope is a simple question. I am trying to sign the
EncryptedData element in an XML document. This element has an id attribute
of "ed1".
If I use a same-document reference URI of "#ed1" I get the desired result;
i.e., the digest is only calculated for the Encry
Hi Berin,
you're absolutely right, and I understand it. If it was a requirement to
use CDATA tags for text nodes, we wouldn't have such problems. All other
contents could be considered subject to change. However, i'm using
Castor and it seems that the deserialisation process (marshalling)
rem
Mike Haller wrote:
i don't know why Canonicalization doesn't address this problem at all.
It sounds like being incomplete to me. One the one hand, there is taken
effort to "normalize" the XML document so it can be signed to
avoidproblems with formattings - on the other hand something simple li
Yes Berin, thanks,
i don't know why Canonicalization doesn't address this problem at all.
It sounds like being incomplete to me. One the one hand, there is taken
effort to "normalize" the XML document so it can be signed to
avoidproblems with formattings - on the other hand something simple li
Mike Haller wrote:
But after some marshalling/unmarshalling with Castor, the resulting
Document has no newlines any more, hence the SignatureValue of the
SignedInfo element is invalid.
How do I tell XMLSignature to add newlines into the SignedInfo before
validation? Or should I remove the ne
Hi,
in hope this is the correct mailing list, here my question:
Signing works, verification works.
But after some marshalling/unmarshalling with Castor, the resulting
Document has no newlines any more, hence the SignatureValue of the
SignedInfo element is invalid.
How do I tell
> Scott - you are the person with the most experience in schema validation
> and signatures. Is it worthwhile adding some form of switch to tell the
> library to output base64 data in normalised form? (I.e. no line feeds
> etc.) That way normalisation won't touch the data and schema validatio
Peoples,
I've been doing some work to clean up for a 1.2 release. In particular,
I have just :
1. Started going through and cleaning up the various bugs that haven't
yet been fixed
2. Stripped out all requirements for RTTI
3. Stripped out requirement for MFC in debug build
4. Now builds aga
rting to incoporate a few pieces of the XML Encryption classes into
some of my project, and I had a question about the XSECEnv class,
specifically about the DOMDocument parameter in the c'tor, and how to use
this class.
Is this object supposed to be created per XML instance being manipulated?
I'm starting to incoporate a few pieces of the XML Encryption classes into
some of my project, and I had a question about the XSECEnv class,
specifically about the DOMDocument parameter in the c'tor, and how to use
this class.
Is this object supposed to be created per XML inst
Hi,
I'm signing an xml document using hmac-sha1. I was just wondering what do people normally fill in for the element? I assume that you don't incorporate this element into the document because you can't/shouldn't store the secret in it. Or is there some way to incorporate this information
[EMAIL PROTECTED] wrote:
Well,
In the current c14n implementation changing the behaviour is only a how
the symb table is create(i.e. When I create the symbol table the
xmlns="" binding is marked as rendered, so it is not emitted), I can
parametrized this behaviour.
But what happend in the excl c1
Dittmann Werner wrote:
This behaviour is absolutely necessary in order that exclusive
canonicalization can function correctly in the case of
changes to apex definitions of the default namespace. The
canonicalization specifications should both have been
defined to always emit apex xmlns=""; this la
> Berin,
>
> well I don't know if it is the same reason as for
> encryption. During the discussion I also asked
> one of the WSS gurus about the topic. Here is his
> answer to my question:
>
>
> This behaviour is absolutely necessary in order that exclusive
Berin,
well I don't know if it is the same reason as for
encryption. During the discussion I also asked
one of the WSS gurus about the topic. Here is his
answer to my question:
This behaviour is absolutely necessary in order that exclusive
canonicalization can function correctly in the ca
Dittmann Werner wrote:
* Finally, employ the canonicalization method specified as a parameter to the transform to
serialize N to produce the octet stream output of this transform; but, in place of any
dereferenced element Ri and its descendants,
process the dereferenced node set Ri' instead. Dur
m can be sloved.
Regards,
Werner
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 27. Mai 2004 17:22
An: [EMAIL PROTECTED]
Betreff: Re: AW: Question on c14n exclusive
Raul,
thanks.
However, the element that I
On 27/05/2004, at 17:34, Dittmann Werner wrote:
Raul,
already tried that hack, the problem with that is that
c14n outputs either a byte buffer that is the XML
docu as String or as a node set - this has to be
serialized then deadlock.
Well, I try to ask the WSS guys how they think this
problem c
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 27. Mai 2004 17:22
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: Question on c14n exclusive
>
>
> > Raul,
> > thanks.
> >
> > However, the element that I c
> Raul,
> thanks.
>
> However, the element that I create is a top level
> elemen, i.e. an apex node (as far as I understand the
> c14n specs). According to the WSS specs
>
>
> * Finally, employ the canonicalization method specified as a parameter to
> the transform to
> serialize N to produce the
nicalizeXPathNodeSet(nodeset, incNamespace) would this
work? A very confusing topic :-) (And hard to read specs too).
Regards,
Werner
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 27. Mai 2004 15:29
> An: [EMAIL PROTE
> 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
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 c
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
[EMAIL PROTECTED] wrote:
Other question when a xmlns attribute is selected with the xpath but the
parent isn´t(i.e you just output xmlns:X="") & a child needs to render the
same xmlns. It is taken at renderedi.e.
the output is:
xmlns:d="ddd"
or:
xmlns:d
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
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
Apr 27, 2004 3:40:53 PM org.apache.xml.security.
count(Can anyone comfirm this?). And as i unifiying the handling
of attributes in a (sub)tree c14n & xpath I found this problem.
Other question when a xmlns attribute is selected with the xpath but the
parent isn´t(i.e you just output xmlns:X="") & a child needs to render the
s
Hi Raul,
here's an attempt to help you further:
from the spec:
Namespace Nodes- A namespace node N is ignored if the nearest ancestor
element of the node's parent element that is in the node-set has a
namespace node in the node-set with the same local name and value as N.
Otherwise, process the n
I'm rewriting the inclusive canonicalization and i see same weirds thing
in the test vector:
/data/interop/c14n/Y4/c14n-1.txt:
http://example.org/bar"; xml:lang="en-ie">
http://example.org/foo";>
http://example.org/bar";>
http://example.org/foo";>
http://example.
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
Hi,
I'm refacotoring the c14n and i see that i can get some minor
speed-ups, but I have found something strange. It is this vector correct?
xml-security/data/interop/c14n/Y4/c14n-24.txt
It isn't a valid xml file, I'm missing something?
Perhaps i need to read better the recomendation. But any
> In this signature, the Reference element in the SignedInfo has the
> attribute URI="". I understand that this references the current
> document, which is correct. In this case, I think I need to ensure the
> Transform directives exclude the Signature element itself via nested
> XPath elements. Fo
Hello
First let me apologise for emailing the dev group with my user
questions, but it's the only group I could find for xml-security.
I'm new to this and have been looking at the examples that are shipped
with the Java library. I have been able to generate an enveloped
Signature element within a
Been trying to get an answer to my question very patiently.
I thought I would try it a third time and see if anyone is interested in
my question.
One thing to try is check out latest CVS and give that a shot. Let me know
if you need help. 1.05D2, even though it's the latest version is
Title: Message
Been trying to get
an answer to my question very patiently.
I thought I would
try it a third time and see if anyone is interested in my
question.
I am using Apache
Java library for XMLDsig. Version is 1.05D2.
I want to add a xslt
transform to the .
It all works fine as
long
> 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 -
> >>>>using the wrong cipher spec for the unwrap cipher.
> >>>>
> >>>>Unfortunately, the Sun JCE doesn't take AESWrap or DESEDEWrap, only AES
> >>>>or DESEDE, so I *think* what is happening is the JCE is doing a straight
> >>>&g
re 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
Baltimore interop tests all fail where a s
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
Baltimore interop tests all fail where a symmetric key wrap is used.
The BC JCE takes an algorithm of "AESWrap" or "DESEDEWrap"
>>Cheers,
> >>Berin
> >>
> >>Sean Mullan wrote:
> >>
> >>>Can you tell me which test vectors are failing?
> >>>
> >>>--Sean
> >>>
> >>>Berin Lautenbach wrote:
> >>>
> >>>
> >&g
checked sig).
One question - I am having issues with symmetric key wraps. The
Baltimore interop tests all fail where a symmetric key wrap is used.
The BC JCE takes an algorithm of "AESWrap" or "DESEDEWrap" for the
unwrap algorithms. The SunJCE , I think, uses "AES" a
arching, but all ideas welcome :>.
Cheers,
Berin
Sean Mullan wrote:
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
> Cheers,
> Berin
>
> Sean Mullan wrote:
> > 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
e document following the schema precisely ( the
organization sending the document is loose in the way it interprets the
schema.)
My Question is
"IS there any way of using the sig.addDocument("Xpointer(Xpath))"); type
syntax at all ? Or is there any planned?"
Does anyone know i
g).
One question - I am having issues with symmetric key wraps. The
Baltimore interop tests all fail where a symmetric key wrap is used.
The BC JCE takes an algorithm of "AESWrap" or "DESEDEWrap" for the
unwrap algorithms. The SunJCE , I think, uses "AES" and &qu
rganization sending the document is loose in the way it interprets the
schema.)
My Question is
"IS there any way of using the sig.addDocument("Xpointer(Xpath))"); type
syntax at all ? Or is there any planned?"
I would be quite willing to write a resolver or whatever to do th
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
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
Baltimore interop tests all fail where a symmetric key wrap is used.
The BC JCE takes
MAIL PROTECTED]
Subject: Re: [Java] Newb question concerning XML-Sec JCE requirements
Anderson Jonathan wrote:
> Many, many thanks Sean. You just settled quite a few discussions in my
> shop.
You're welcome.
>
> A follow up question:
>
> Slides presented at JavaOne referred t
Anderson Jonathan wrote:
Many, many thanks Sean. You just settled quite a few discussions in my
shop.
You're welcome.
A follow up question:
Slides presented at JavaOne referred to JSR 105 and 106 being included in
J2SE 1.5. What does this imply, exactly?
105/106 were originally targete
Many, many thanks Sean. You just settled quite a few discussions in my
shop.
A follow up question:
Slides presented at JavaOne referred to JSR 105 and 106 being included in
J2SE 1.5. What does this imply, exactly? Are JSR 105 and 106 built around
an SPI model like JCA/JCE are? Will there be
Anderson Jonathan wrote:
Hi everyone,
Apologies in advance for what is probably a rather naive question. Current
distributions of Apache XML-Security contain no third party JCE, but all of
the documentation points to using the latest versions of the Bouncy Castle
JCE as the provider for
Hi everyone,
Apologies in advance for what is probably a rather naive question. Current
distributions of Apache XML-Security contain no third party JCE, but all of
the documentation points to using the latest versions of the Bouncy Castle
JCE as the provider for XML-Security. I am
Hi,
Init.Class reads from config.xml and register KeyInfoHandler to
_contentHandlerHash. However, as I known, no class calls
getKeyInfoContentHandler so I think that this registeration process is not
necessary. If I were right, a developer should actually do for extends and
customize library
Hi all,
while doing some tests with Encryption and Signing a SOAP
message (in that order: encrypt, then sign) I use
a pre-release version of xmlsec XMLCipher class.
The XMLCipher produces the following output when
encrypting the SOAP Body child element:
http://schemas.xmlsoap.org/ws/2002/07/uti
92 matches
Mail list logo
