Milan Tomic wrote:
Speaking of multiple signatures... How can I verify multiple
signatures in my document? Can I use findDSIGNode() to do the job? I
belive this function finds only first signature element and can't be
used for finding next one.
You are correct. At the moment you have to
Milan,
First a question - is iSignatureCount a global? If so, this approach
may not be thread safe. An alternative (if threading is an issue) might
be to pass in the previous found node to findNext.
strEquals should be able to handle a mixture of XMLCh and char strings,
but it will assume
That almost smells like a mismatch between run-time libraries. The
Debug version of xsec uses the Debug DLL runtime and the release the
normal DLL runtime.
For various reasons, the debug also uses the MFC in a shared DLL.
BTW - You should be able to debug through the DLL if it is compiled
Had a quick check on the bug report. Before making a decision as to the
correct way forward, do we know if the Xerces-J people are going to
incorporate this fix in the next release?
Cheers,
Berin
Werner Dittmann wrote:
Hi,
to test the content encryption of XMLCipher I modified the
, comments, PI, ...) and encrypt
- if some C14N is specified - use this serialization, then
encrypt.
To support this we have to enhance the XMLCipher API to
support the specification of a serialization method
Any thoughts, ideas?
Regards,
Werner
- Original Message -
From: Berin Lautenbach
Samuel,
The base64 decode looks strange indeed!
How do you transform the cert to DER format?
Can you send me a copy of the cert?
Cheers,
Berin
GRU Samuel wrote:
Hi,
To complete my first message, i generate my key and my certificate with
OpenSSL (0.9.7c) with default options.
Milan,
Have you called sig-load();?
Cheers,
Berin
Milan Tomic wrote:
This code:
DOMNode *sigNode = findDSIGNode(doc, Signature);
DSIGSignature * sig = prov.newSignatureFromDOM(theDOM, sigNode);
bool useHMAC = (sig-getSignatureMethod() == SIGNATURE_HMAC);
Allways says
Yup. Just had a look at the code - looks very strange.
My reading is that it would be trying to convert DataReference to a
URI, which would throw an exception which is then being discarded.
Do you have a short piece of XML I could play with? I could dummy one
up, although I am lazy.
Milan,
Do you have an example I could look at? (Not 100% clear on the question
:).
Cheers,
Berin
Milan Tomic wrote:
Apache libraries let me sign root XML document node using detached
signature. Is this legal? I can't verify such asignature using Apache
libraries.
Best regards,
Milan,
Will have a look-see!
Cheers,
Berin
Milan Tomic wrote:
When I set XSECURIResolverGenericWin32 I got an error when
verifying detached signature in separate file, if signed file have space
( ) in its folder or file name. Example:
XSECURIResolverGenericWin32 theResolver;
Milan,
Good question. Now that we have sent the required notification to BIS, I
think we should be fine on that front.
I was thinking about this on the weekend. I'd like to get a beta
distribution (xml-security 1.10-beta or some such) up in the next few
weeks.
I've got a large part of the
Erwin,
I get a permission denied on the web server :.
Out of interest - I thought we had decided to keep Forrest for the web
site part, at least for the moment? The overall XML Project is moving
that way, so we would be moving in a different path. Not necessarily
wrong, but I'd be hesitant
implementation everything worked fine. The document was
signed by using the above mentioned canonicalization method and the
signature
can be validated sucessfully.
Regardless of the .NET implementation, do I know something wrong?
- Original Message -
From: Berin Lautenbach [EMAIL PROTECTED
Dims,
One of our dirty little secrets :.
Unfortunately the DOM API (regardless of level) has no way of
registering that an attribute is of Type ID (except during parse with a
DTD or schema). Level 2 and above have ways of finding (getElementById)
and checking (isId), but no way of setting,
Berin Lautenbach wrote:
Vishal,
I ran accross this when I was doing the checks for the Merlin Interop
examples - which have white space prior to the EncryptedData
node, even
when that node is of type element content. According to
the spec (from
section 4.2
John,
I think you've hit a bug. The Spec requires that the input to the XPath
transform be a node set - which implies that what you are doing is legal.
The C++ library assumes that the input is a document. Which means that
what you are doing will fail.
I just had a look at the Java library.
Vishal Mahajan wrote:
It could be useful to have an API that you mention. But the question is
what does element content mean in the spec, and we definitely should
have an API to support encryption (and of course decryption) of that
element content.
At the moment, the API exists - but it
There's a 2.0 jar sitting right on the download site, and we're using
it because of various issues with the ancient code in the 1.0.5
release. It's been many moons since a refresh was put out, so I took
what we could get.
I know.. it's terrible at this point.. because I am too unfamiliar
John,
Yup. This one is already fixed in CVS (exactly your fix below :). One
of the reasons we need to get a new version out.
With thanks!
Cheers,
Berin
John Moore wrote:
While testing, my program started failing. I traced it to the following code
snippet from
Vincent Finn wrote:
Is it possible to sign and verify a document without using the DOM?
Not at the moment - in either library.
The core library loads its structures from DOM, and relies on DOM for
most of the transforms.
The reason I ask is because I have a document that is about 13Mb with
Vincent Finn wrote:
That is sort of what I was looking to do but I could see a function in the library
that took a byte stream
since I can stream the Xml for my document easily so that would do me
Can you tell me what function I need to use?
Not so much a function. If you create a Reference
Vincent,
Try removing the line :
ref-appendEnvelopedSignatureTransform();
That's telling the library to sign everything in the *current* document
other than the signature, so it expects a local reference URI (URI=#ptr).
Cheers,
Berin
Vincent Finn wrote:
From: Berin Lautenbach
Peoples,
I propose that we aim for a release of the Java and C++ libraries on 7th
March (a Sunday). That's roughly 2 and a half weeks from now. (Very
ambitious, but why not aim for something!)
The version will be 1.1 for both libraries. The documentation will
indicate that the signature
;
}
// The last \\ must prefix the filename
baseURI[lastSlash + 1] = '\0';
XMLUri uri(MAKE_UNICODE_STRING(baseURI));
theResolver.setBaseURI(uri.getUriText());
sig-setURIResolver(theResolver);
Vincent Finn wrote:
From: Berin Lautenbach
Scott/Erwin,
For now I've fixed the bug in CVS - probably best to not introduce
anything majorly new until after 1.1.
Cheers,
Berin
Erwin van der Koogh wrote:
With the talk of a release, I'd note that the Java Base64 encoder in the
utility class is still adding an extra linefeed when
Jozef Aerts - Comp.Chem.Cons. - XML4Pharma wrote:
Dear Berin,
Many thanks.
Does the cascading down HAVE to happen ? Or can it be avoided ?
As I understand it (and maybe someone else can comment here!) - yes it does.
The C++ library bypasses this by keeping a record of the cascaded
namespace
down the Y tree.
5) Use Y for all future operations.
This can be implemented without making too many major changes to the
code (I can volunteer for this). The only drawback that I see with this
approach is the expense of the clone operation.
Any comments on this?
Regards,
Vishal
Berin
Guys,
Could someone else have a look at the full output? At:
http://lsd.student.utwente.nl/gump/xml-security/work/build_xml-security_xml-security.html
It looks to me like we have a wrong jar being included for Xerces or
Xalan, but any thoughts welcome.
Cheers,
Berin
Sam Ruby wrote:
Andrew,
DSIGREference::createBlankReference executes
ret-setAttribute(MAKE_UNICODE_STRING(type),with a lower case 't' on
type.
Ouch. You are absolutely correct - this should be an upper case 'T'. I
will check a fix into CVS tonight.
Being a newbie, is this the proper way to report bugs? If
Andrew,
Fix is in CVS.
With thanks!
Cheers,
Berin
Berin Lautenbach wrote:
Andrew,
DSIGREference::createBlankReference executes
ret-setAttribute(MAKE_UNICODE_STRING(type),with a lower case 't' on
type.
Ouch. You are absolutely correct - this should be an upper case 'T'. I
Sachin,
How are you loading the private key? The InvalidKeyException might
indicate that the wrong key is being used - which would explain the
unknown block type, as it would do the decrypt and go to strip the
PKCS1.5 padding and find it didn't match expectations.
Cheers,
Berin
Hi,
I
Andrew,
Could you provide a full XML file together with the piece of code you are
using to produce the signature? There could be something in the
transforms within the references. There might also be something being
added during the signature build that is not getting properly reflected in
the
Peoples,
Just to let you know (as it has now been found out :), there is a
[EMAIL PROTECTED] list for user questions on the library.
That's not a hint :. People are more than welcome to put questions on
the security-dev list still - we just wanted to provide a list that
didn't necessarily
Scott,
That is really cool!
You mentioned in your previous e-mail that you have seen significant
performance improvements. Is this when interfaced with xml-security?
It would be interesting to turn this (or something like it) into a fully
fledged library. I wonder if one could apply for a
to allow for global configurations. Half the work was done for 1.1 in
that there is now an environment object that holds all this
information and gets passed around the various signature objects.
Interested in thoughts on the last part.
Cheers,
Berin
Berin Lautenbach wrote:
Scott/Sean
Johan,
I had a long think about this one. I can't think of a better way to
achieve what you are trying to do, other than potentially using a
manifest embedded in the body of your document.
However a manifest is hashed and checked during signature verification,
so if the file name changed,
Hyejung,
Oops. I missed this - apologies!
Did you get this working? My first thought would be that you are trying
to create a key using
SecretKeySpec ks = new
SecretKeySpec(encryptionKeyCipherValue.getValue().getBytes(),
ek.getEncryptionMethod().getAlgorithm());
Which
Vishal,
I just went to apply this, and it looks like it might have already been
done by Axl, a few days before this e-mail??
Could you just confirm for me?
Cheers,
Berin
Vishal Mahajan wrote:
Hi All,
Please find attached a patch for build-ant1.5.xml file in the
xml-security
2. Allowable names for Id attributes are now stored in a list. This
list can be added to by the calling program using new methods on
DSIGSignature.
I like this. It lets you work around situations where you don't have
DOM3 support, in Java especially.
Which is a good point. I have only
Given the Java library is unlikely to happen this weekend (unless
people help - hint hint :), do people think we should try to get this
ID handling functionality into it prior to a release?
I'm agnostic, since I don't generally rely on unreleased functionality.
I'm already using DOM3 calls
Samuel,
15 seconds is a long time! It would be interesting to know where the
time is being spent. Are you able to trace the process?
I am assuming you are calling sign() multiple times from the same process?
Cheers,
Berin
GRU Samuel wrote:
Hi,
First, i work on Windows 2000 and i
Dims,
Actually, because of all the problems with Gump (which is/was ignoring
bouncy castle) I've been doing exactly that.
The problem I'm running into is that the Sun JCE does not support the
relaxed version of PKCS5 padding that the Baltimore encryption interop
examples use.
Either way, am
Note that ISO10126PADDING is not supported in the 1.4 JCE. It might be in
1.5, and I will check.
Cheers,
Berin
Here's the list of things that needs to be added eventually to
NativeJCE (needed by xmlenc/xmldsig specs). The name/id's are from
BouncyCastle provider. PLEASE check if the list
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
, 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 sig).
One
,
Sachin.
*/Berin Lautenbach [EMAIL PROTECTED]/* wrote:
Sachin,
How are you loading the private key? The InvalidKeyException might
indicate that the wrong key is being used - which would explain the
unknown block type, as it would do the decrypt and go to strip the
PKCS1.5
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
PROTECTED]
--- Berin Lautenbach [EMAIL PROTECTED] wrote:
(BTW - We are still working through a name, but it's
looking like
Juice - as in stop on the)
I don't get it, but regardless, I think it will be
more difficult for people to take a cryptography-based
product with that name seriously
http://lsd.student.utwente.nl/gump/xml-security/xml-security.html
It finally worked. It's been quite a saga, but we are again succeeding
in Gump. (We haven't been since October/November last year as far as I
can see.)
Cheers,
Berin
Done.
Cheers,
Berin
Davanum Srinivas wrote:
Erwin, Berin,
Latest CVS does not have the fix the JDK1.3 build failure :( see attached diff.
thanks,
dims
--- [EMAIL PROTECTED] wrote:
vdkoogh 2004/03/07 10:16:02
Modified:src_unitTests/org/apache/xml/security/test
We should probably have something somewhere indicating minimum
requirements for the library to build and run.
I don't think that's on the site at the moment? Thoughts?
Cheers,
Berin
vdkoogh 2004/03/08 07:04:20
Removed: ant Md5Task.class HexDump.class
Log:
no longer
Andrew,
I think both this and your previous e-mail are bugs in xsec. Are you able
to try latest CVS? Someone else was having problems recently and I did
some patches, but it would be good to have someone else confirm it is all
working OK.
Cheers,
Berin
Hi,
The problem is very simple:
Oops. I missed this one last night :. Glad you got it fixed.
Andrew wrote:
Divide and conquer solved this one for me.
The copy of Xalan that I downloaded included the release DLL which was built
with Xerces 2.3
I had forgotten to rebuild Xalan in release with Xerces 2.4
All good now.
Milan,
Are you able to provide a small piece of code that reproduces the
problem? Happy to have a look-see!
Cheers,
Berin
Milan Tomic wrote:
Berin,
Seen that one too :.
From memory it's something to do with MFC - if you define
something as
being MFC (and it creates stdafx.??) but
Milan,
THey should not be throwing an exception - that's really basic stuff!
What version of Xerces are you using? I know there were some problems
with 2.4?
Cheers,
Berin
Milan Tomic wrote:
Berin,
I belive I've found it. :-)
I've copied those three lines of code:
DOMNode
Peoples,
I have just placed what I think is a ready for release set of binaries
for Version 1.1 of the C++ libraries on the web site. They are not yet
linked into the mirror system or the download pages, so if anyone finds
anything really bad, let me know.
http://xml.apache.org/security/1.1/
message:
---
Microsoft Visual C++
---
Unhandled exception in checksig.exe (KERNEL32.DLL): 0xE06D7363:
Microsoft C++ Exception.
---
OK
---
Best regards,
Milan
-Original Message-
From: Berin
Erwin,
From the previous correspondance it's actually increasing in time over
multiple signs. Which almost sounds like a /dev/random blocking until
it has enough entropy to provide some bits?
Of course there are other things it could be as well, so I'm just
putting theories at the moment :.
Walter,
Does apache have a standard for due diligence to avoid name collisions
or does everybody just have to like the name? There are other
Good question.
I'll put this to the incubator group tomorrow to see if there is any
guideance there.
Cheers,
Berin
Erwin van der Koogh wrote:
Last e-mail for tonight - I promise :.
What think people for a security top level project but existing within
the xml federation?
Of course I am all for it :)
:.
But I have been wondering.. do we want to split the stuff into seperate
projects under the TLP?
Erwin van der Koogh wrote:
So maybe the best thing is to just drop this out of the code?
And possibly lose support on a couple versions of 1.4?
That's what I'm not sure about. If we are telling people to use the
endorsed mechanism to override the broken version of Xalan, then I
*think* we
Scott,
Make install works on the Solaris 2.8 system that we have access to, but
I suspect that's because we have the GNU install (fileutils) on our system.
I will install on a system with no native install tomorrow and see if
that breaks things, because I suspect that's where the problem is.
Stephen Chell (DSL AK) wrote:
What is the development status of WSS4J? Where abouts can I download it?
There don't seem to be any download links for it on the Apache site:
http://ws.apache.org/ws-fx/wss4j/
Should be in CVS. I *think* it hasn't yet had a release.
The mailing list for the ws-fx
Stephen,
When you say non-namespaced does that mean you have added via a DOM
level 1 call, or simply that the XML looks something like :
myns:elt1 attributewithoutns=a test/
The latter should work. I haven't tried it myself, but my understanding
is the former is likely to fail (use L2 calls
Scott,
First the good news. I can reproduce your problem by removing install
on a system here.
The bad news is that I have absolutely no idea why autoconf requires
install-sh be in the src directory - it seem worse to use it rather than
nothing! The standard X11 install-sh script is fairly
The Object element is simply an artifact for including information to be
signed or to be used in the signature inside the Signature element. It
is not directly included in any signture operation.
How is the signature breaking?
Cheers,
Berin
GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
Abraham,
We are in the process of setting up a project to implement a JCE provider
using OpenSSL.
In discussions, the team came up with the name JuiCE as an option, which
ended up being the preferred name for the project.
Before making this decision final, we are seeking feedback from other
)
(SquirrelMail authenticated user berin)
by webmail.wingsofhermes.org with HTTP;
Fri, 2 Apr 2004 12:20:42 +1000 (EST)
Message-ID:
[EMAIL PROTECTED] Date:
Fri, 2 Apr 2004 12:20:42 +1000 (EST)
Subject: Use of the name Juice
From: Berin Lautenbach [EMAIL PROTECTED]
To: [EMAIL PROTECTED
Abraham,
We are in the process of setting up a project to implement a JCE provider
using OpenSSL.
In discussions, the team came up with the name JuiCE as an option, which
ended up being the preferred name for the project.
Before making this decision final, we are seeking feedback from other
Jeremy,
Thanks for the report. Would be fantastic if you could put in bugzilla :
http://nagoya.apache.org/bugzilla/index.html
That way it won't get lost.
Cheers,
Berin
Hi
I've been compiling a comprehensive test suite for my class which is
wrapping XMLSignature.sign and
Milan,
XMLMutex is a wrapper class defined in Xerces. It provides a very basic
mutex using whatever is available on the platform in question. We used
it in threadtest as the theory is it should allow the mutex code to move
from platform without having to worry about whether you are in a
FYI - I'd say we are a go!
Original Message
Subject: Re: Juice
Date: Fri, 02 Apr 2004 23:29:14 -0500
From: Greg Scott [EMAIL PROTECTED]
To: Berin Lautenbach [EMAIL PROTECTED]
Hi Berin,
That's perfectly fine with me, go right ahead and use that name.
-Greg Scott
Kokopelli
Erwin,
What do we want to do about this? Should we contact the Xalan crew, or
drop support for the original Java 1.4 if the user does not add Xalan to
the endorsed libs directory?
Cheers,
Berin
Sam Ruby wrote:
To whom it may engage...
This is an automated request, but not an
Vishal Mahajan wrote:
Berin, like I said in my previous message, what if the cononicalization
is not required to be performed? eg, consider the following example
ds:Reference
Reference URI=#Body
DigestMethod
Guys,
Have just checked in some code updates to overcome bug 28162. Do do it,
I made Reference.getDigestValue() throw an XMLSecurityException, which
it didn't do before. I could have had it throw a Base64 exception
(which would not break the API), but that seemed artificial.
Let me know if
: Mon, 29 Mar 2004 22:59:29 +1000
From: Berin Lautenbach [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Peoples,
I'd like to nominate Vishal for committer status. He has been active on
the list, supplied and proposed a number of patches, and recently
supplied a set of sample
Peoples,
I've just tried to move all the functionality from build.xml into
build-ant1.5.xml. In particular
- samples exist and run
- tests now run
- header at startup (version etc.)
- build src and distribution archives
- external call to forrest to build docs
Could people have a look? I've
- tests now run
They didn't before? I changed it to not rely on a junit.jar in the lib
directory, but instead on a junit included in the ant lib directory.
But I noticed that you put the junit jar back into the classpath.
Didn't it work for you? Or did you not have junit in your ant lib
Erwin van der Koogh wrote:
The cvs commits looked good. I'll check out the builds tonight to see if
I can break anything :-)
I'm pretty sure you'll be able to :.
I've tagged all the Java files as J_1_1_0, so it'd be great if you could
retag anything that you decide needs to be fixed for the
Milan,
checksig allows the user to select between WinCAPI and OpenSSL when both
are present. (BTW - The second usage is really redundant, it's a
hangover from old code.)
Threadtest cheats :. By default, if the library has both OpenSSL and
WinCAPI available, it will use OpenSSL. So
Guys,
Don't know if you have been keeping accross it, but XKMS 2.0 is now in
candidate recommendation status. The plan is to run interop tests
between now and (from memory) October.
I thought it might be interesting to try to get an XKMS service and/or
client up and running to have involved
2.0 fake release: 840 ms avg
1.1 RC Berin put out: 915 ms avg
Build of CVS Head:540 ms avg
Seriously. Maybe I'm just a special case and the patches target my use
case, but, wow.
Wow!
It's interesting in other respects too. The library makes extensive use
of XPath calls all over
Erwin van der Koogh wrote:
But these results are quite a bit better so I think Berin won't mind
including them in 1.1 ;-)
GRIN. Nope.
There is a new 1.1 in xml.apache.org/security/1.1
I have moved the first one into the superceded directory.
Some stuff came up tonight that meant I couldn't
Scott,
If you have the time - have a look in
xml.apache.org/security/1.1
If you confirm it's OK, I'll do the final publish and release.
Cheers,
Berin
Scott Cantor wrote:
It hasn't made a big difference to ant test - but there is a difference,
so I'll do a re-package and distribute
One of the really cool things about c14n is it doesn't necessarily
result in valid XML GRIN.
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
Cool!
Davanum Srinivas wrote:
FYI.
Note: forwarded message attached.
=
Davanum Srinivas - http://webservices.apache.org/~dims/
Subject:
JSR 105: Proposed Final Draft
From:
Harold Ogle [EMAIL PROTECTED]
Date:
Fri, 16
Scott Cantor wrote:
Sadly we share similar hours, but I'm not in OZ.
LOL.
My test ran in 360 ms, down from 910 in the original 1.1 release.
Now that is really really cool. I'm going to print now!
Cheers,
Berin
Peoples,
I have just made 1.1 official. It's on the web, with updated docs.
I'll also try to get an announcement out (for both Java and C++) in the
next few days.
Cheers,
Berin
-ant1.5.xml straight from latest cvs...Am getting
test
failures. see enclosed out.txt.
-- dims
--- Berin Lautenbach [EMAIL PROTECTED] wrote:
Peoples,
I have just made 1.1 official. It's on the web, with updated docs.
I'll also try to get an announcement out (for both Java and C++) in the
next few
No - there is no validity check between the two. And in fact, because
of the potential uses of KeyInfo, it *might* be that incompatible key
values are valid.
XKMS is a particular example - I can do a LocateRequest for Berin
Lautenbach as a KeyName. The response could include a RSA key, known
Milan,
Not happy. I must have missed testing Windows without Windows CAPI.
With thanks!
Cheers,
Berin
Milan Tomic wrote:
It seems that WinCAPICryptoProvider.hpp is missing:
#if defined (HAVE_WINCAPI)
...
#endif /* HAVE_WINCAPI */
I've added those precompiler directives
Cool, I will add tomorrow night.
Thanks!
Cheers,
Berin
Davanum Srinivas wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=28872
-- dims
On Mon, 10 May 2004 19:52:19 +1000, Berin Lautenbach
[EMAIL PROTECTED] wrote:
Yah. I wanted to have another look tonight (just got to my
Sean Mullan wrote:
I agree with your opinion. However, I think that this is actually
fixable in
the test case by making sure that reference-1 is inserted in the document
before the manifest is generated.
GRIN. I did my normal trick of not saying everything. Yes - that's
correct, and it's what
Andrzej,
Nope - I don't understand this one. According to everything I've seen,
error should not be 0. However - looking at what you've done, I can't
see a problem. Basically - if Windows reports an error, but there is no
error code, disable AES. If there is something more fundamental
Soo-Leng,
Can you provide a document and/or code snippet that makes this happen?
Cheers,
Berin
Lau, Soo-Leng wrote:
No I am not using XPath.
-Original Message-
From: Kenworthy, Edward (EDS) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 12:59 AM
To: '[EMAIL PROTECTED]'
Peter,
I don't *think* so. But my expertise in this space is not as high as
others on the list :.
The library uses pure JCE, so if you don't have a JCE interface for the
HW module then I don't think so. (Although I haven't checked to see
PKCS11 support in JDK 1.5.)
(I am sure someone will
Milan,
Have you had a look inside xtest.cpp?
There is some code in there that *might* help. (It also might not :.)
In particular, have a look at unitTestEncrypt(). This sets up a
WinCAPI RSA key and calls unitTestKeyEncrypt() to wrap an encryption key.
That particular error would indicate
GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
I have been using xml sec for signature verification in my application. As
long as Axis clients are used for sigining the XML, the signature
verification is succeeded. But it has interoperability issue when .NET is
used for generating signed XML. I learnt
Yup - use URI=aaa.doc and then use a XSECURIResolverGenericWin32 (or
XSECURIResolverGenericUnix) with a base path set to the current directory.
Have a look-see at checksig.cpp. The code is fairly ugly, but it should
work.
Cheers,
Berin
Andrzej Matejko wrote:
Hi,
Is it possible to
Regards,
Ayyappan Gandhirajan
-
Office: 91.80.2225.1554 Extn 1472
Mobile: 91.94483.14969
E-Mail: [EMAIL PROTECTED]
---
-Original Message-
From: Berin Lautenbach [mailto:[EMAIL PROTECTED]
Sent: Tuesday
1 - 100 of 310 matches
Mail list logo
