But is your code available for others to use?
not yet, i mailed Jason the idea of launching
the whole project as a JDOM sister.
Or when you did this, did you find issues that might help the original
poster?every modification that is not "catched"
by c14n could affect the signature, so we
yes, i did quite a lot of R&D on that and
made a pure JDOM XML signing algorithm.
i prefer JDOM to DOM a lot!
i also made a JAXB based on JDOM instead too. I
found it much simpler and faster to
manage business objects that way, and sign them
directly from there.
the other diference of my
t know how to get the exact DOM out of JDOM for
validation.
Martin Labarthe Dubois
<[EMAIL PROTECTED]> wrote:
Yes. in this case i also saw both of them
identical from the c14n perspective.
You must have some other
difference.
Yes. in this case i also saw both of them
identical from the c14n perspective.
You must have some other
difference.
- Original Message -
From:
David Wall
- Yozons Inc.
To: security-dev@xml.apache.org
Sent: Friday, April 07, 2006 2:09
PM
Subject: Re: JDOM - S
The validation of DOM converted from JDOM fails.The reason is the
converted DOM from JDOM is different than the original DOM.
Can you specify where is the difference?
send some examples.
Hey,
i just tested the code with jdk 1.4
public static void main(String[] args) throws
Exception { InputStream inStream = new
FileInputStream("c:/temp/LatestCRL.crl"); CertificateFactory cf =
CertificateFactory.getInstance("X.509"); X509CRL crl = (X509CRL)
cf.generateCRL(inStream); inSt
there are a couple of very similar pkcs#7
formats,
with openssl you can transform from one to
another.
i remember that i had to use it to make some
certificates in that format readable from java.
that´s probably the problem.
- Original Message -
From:
Cláudio Engelsdorf
pasted that link here too. Thanks in advance
"Martin Labarthe Dubois"
<[EMAIL PROTECTED]>
06/04/2006 10:39
Please respond
tosecurity-dev@xml.apache.org
I only found the certificate chains
there,
but not the revocation lists.
- Original Message -
From:
Cláudio Engelsdorff Avila
To: security-dev@xml.apache.org
Sent: Thursday, April 06, 2006 10:17
AM
Subject: Re: Need lots of help -
Validating Signed XML fil
My goals are: - Assure that the certicate used was an end user
certificate and not from a certification authority; (Didn't find nothing
about this kind of validation)
use JCA
- Adopt rules defined by RFC 3280 for
RCL and chain of trust (certification chain); (Completely lost on this
one)
Title: xml encryption/decryption of binary data
why don´t you just use Java crypt primitives for
that?
- Original Message -
From:
Larchier
Christophe
To: security-dev@xml.apache.org
Sent: Friday, March 31, 2006 4:41
AM
Subject: RE: xml encryption/decryption of
Yap, the best thing you can do there is have a "cache" of the used keys.
- Original Message -
From: "Arshad Noor" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 23, 2006 2:45 PM
Subject: Re: Improve performance of XML Signing
> It appears that opening the keystore, authenticating to i
> > applies, by default, C14N transformation when signing xml data or if I
> > have to apply it everytime I want to sign xml content.
About this,
the texts says that only when
"the data object is a node-set and the next transform requires octets"
so in all the other cases c14n shouldn´t be appli
Hello,
Is c14n transformation applied by default to all
"referenced" areas?
according to http://www.w3.org/TR/xmldsig-core/ [s06-08] cannonization shouldn´t be applied to referenced areas
unless specified as a transformation.
ie:
but i think that you are maybe applying it by
default w
it will only hurt your performance.
- Original Message -
From: "Berin Lautenbach" <[EMAIL PROTECTED]>
To:
Sent: Thursday, June 09, 2005 7:04 AM
Subject: Re: Canonical Transformation
> Should do it by default. Having said that - it wouldn't hurt to add the
> C14n transformation explici
i have no vote here,
but RAUL helped more than a lot with the speed and memory problems i had
with the API.
when signing huge XMLs.
before it was imposible
- Original Message -
From: "Vishal Mahajan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 15, 2004 1:44 PM
Subje
it´s surprising...
the same key using two different algorithm, has generated the same
signature, with the same certificate but with different,
exponent+modulus pair.
i verified both, and both are correct! (with Apache and with IBM xml
security suit.)
someone here told once that the same certif
process of generating the tag:
1. inherit namespaces to signed info, like this:
http://www.w3.org/2000/09/xmldsig#";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
2. apply xml-c14n-20010315 to SignedInfo
3. apply rsa-sha1
4. apply base64
4. now you have
the namespaces inherited in 1.
and what about the sun.misc.BASE64Decoder
public static byte[] BASE64toByteArray(String pBASE64string) throws
Exception {
return new BASE64Decoder().decodeBuffer(pBASE64string);
}
public static String ByteArrayToBASE64(byte[] pByteArray) throws Exception
{
return new BASE64Enco
I tested the patch and I must say that memory usage
improvements are huge, therefore speed.
- Original Message -
From:
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, May 01, 2004 7:32
PM
Subject: Speed optimizations
Hello,
I have been work
Hola Raul,
te cuento que no hize tests muy exaustivos ni con mucho detalle, pero probe
con XMLs de 5megas y usa mucho menos memoria con el patch que sin.
Congrats,
Martin
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 03, 2004 6:29 PM
Subject: R
> The killer is the c14n. For our use we don't actually need full-c14n, we
just need to be sure that the hash we get when the > > document is sent will
be the same as that when it's received, despite having passed through one or
more XML processors. > We could have used compression (basically turn
I used the Apache VerifySignature.java
to verify two XMLs signatures.
One of them made with Apache, the other with another API.
the signatures values are identical, also the certificates, alse the
exponent, but the have different modulus.
So to test I cut the certificate tag to force Apache to ver
I have signed an XML, but when I try to verify it with VerifySignature.java
(API 1.1),
it hangs after a couple of hours with an OutOfMemory.
the XML is about 8.997KB, compresed 32KB.
If anyone is willing to try to verify it, please email me.
Thanks.
Martin
Hi All,
regarding this,
is it posible to generate the same PublicKey with two different modules and
the same exponent
module
ALTng/nEXt4jp8tatc1EHqteLwdovwRyueRuuB0Q7PisWn5uzdaCOKhnIkH9BgtlwJJEwd+sYEoU
7wIj3NcLlaIg/rypTQz+AlNKmiUIxAYHbCJ1LH3cEBct9HUY4YjleV1cK9Ip6j1INQ6PjzViNMng
52RweeSuPi/hm9
// This is done via the
standard java.security API MessageDigest md =
MessageDigest.getInstance("SHA"); md.update(result.getBytes()); byte[]
digest=md.digest();
// And finally print
a Base64 of the digest with // The help of the BouncyCastle
JCE l
I had memory problems signing big XMLs, so I decided to make my own specific
XML signature algorithm that works with an specific "home made JAXB", i
finished it today and i discoverd two things,
one is that it signs faster than 1.04, but identical to 1.1, but of course
much more less flexible,
a
> If you don't use xpath transformations everything is a lot faster(If you
> use it, you get a moderate speed-up). But the best thing is that know
> that the engineSign is significative, the Scott's native JCE
> implementation improves the think a lot(x4 times) (Thanks Scott).
> Right now in my te
Hi All,
is it possible that this version signs seven times faster that the 1.04 ???
because, I just replaced the old jars an obtained those times.
MLD
stance("SHA"); md.update(result.getBytes()); byte[]
digest=md.digest();
// And finally print a
Base64 of the digest with // The help of the BouncyCastle JCE
library System.out.println("IRmark: " + new
String(Base64.encode(digest)));
}}
-Original M
> Well.. is the XML you are outputting always the same or does the output
> conform to one or more C14N standards?
Actually I use just one C14N format, but it doesn´t limit interop with other
providers,
it just XML, the format is not important until signed,
when i send my XML to other provider he
> > I don´t need to, because, i don´t use dom neither jdom, i developed my
own
> > small JAXB, so I read the
> > XML into my generated Java structure,
> > when I need to sign some area y use, a method of the structure that
prints
> > the canonized XML.
>
> It doesn't matter you use for representi
> >>my own xml signature algorithm and i found that it consumes much less
> memory<<
>
> Really? Have you done the c14n bit? That's the step that gobbles up all
the
> memory.
>
I don´t need to, because, i don´t use dom neither jdom, i developed my own
small JAXB, so I read the
XML into my generate
> Well, as I said, I managed to sign a 20meg XML
document in around 20 seconds> using the Apache library... using the
options I gave you. Did you try them?
I am quite confused, what´s your hardware
configuration???
Using the Apache Library and
Pentium IV 2.4 GHz, 1 GB memory DDR
266
comm
y much
> every software-based signer, including Apache). The killer is actually the
> c14n transformation- not the hashing or signing.
>
> How did I solve it? By using a device that does XML transformations in
> hardware :-) Ask me off list if you want more information.
>
>
Hello,
I need to sign a bigXML (aprox. 8900 KB), but I receive an OutOfMemory
Exception,
i set the JVM -Xmx to
-Xmx1024m
but I still receive the error, is there a way to avoid this problem???
Thanks,
Martin
36 matches
Mail list logo
