Re: [C++] Encryption

Milan, It's actually an artifact of XSECCipher (or XMLCipher in security/J). Have you had a look at the programming examples URL? http://xml.apache.org/security/c/prog_enc.html#Create+an+%3CEncryptedKey%3E If that doesn't help - come back to me :>. Cheeers, Berin Milan Tomic wrote: Be

Re: [c++] WinCAPICryptoProvider::WinCAPICryptoProvider - error==0.

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 wrong

Re: input node set contains no nodes

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]' Su

Re: Any PKCS#11 support in xml-security Java lib?

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

Re: Encryption

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 indica

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest

Hi, My patch don't handle well this test case. It seems that it take on account that the signed info is going to be c14n, reparsed & reimported. But this is not alway the case. The SignedInfo is not c14n and reimported if the c14n method is "safe". As stated in the second paragraph of this

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest

Looks like merlin-xmldsig-sixteen has been deprecratedand we are WAY behind the times, we need to update to latest interop tests - http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0016/01-merlin-xmldsig-twenty-three.tar.gz - http://lists.w3.org/Archives/Public/w3c-ietf-xml

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest

[EMAIL PROTECTED] wrote: Hi, My patch don't handle well this test case. It seems that it take on account that the signed info is going to be c14n, reparsed & reimported. But this is not alway the case. The SignedInfo is not c14n and reimported if the c14n method is "safe". As stated in the

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28752] - Some patches for c14 and various other improvment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu