RE: Java canonicalizer unrendered namespaces

Title: RE: Java canonicalizer unrendered namespaces Ok, this is the test case that fails for me (this is after i signed the document, but i deleted the signaturevalue and keyinfo) - the digest for the reference is wrong. Funny enough when i save this document to disk the usual way with the XML

RE: Problem with WinCAPICryptoProvider

Hi, the code sample is in xsecplatformutils.cpp, XSECPlatformUtils::Initialise the line XSECnew(g_cryptoProvider, XSEC_DEFAULT_PROVIDER); creates a new WinCAPICryptoProvider, which throws the mentioned error message in its constructor when the following call fails: // Try to create if (!CryptAc

RE: Problem with WinCAPICryptoProvider

> // Try to create > if (!CryptAcquireContext(&m_provApacheKeyStore, > s_xsecKeyStoreName, > provRSAName, > m_provRSAType, > dwFlags | CRYPT_NEWKEYSET)) { > throw XSECException(XSECException::InternalError, > "WinCAPICryptoProvider() - Error obtaining generating > in

RE: Problem with WinCAPICryptoProvider

In the constructor of WinCAPICryptoProvider, the first call to CryptAcquiryContext fails with NTE_BAD_KEYSET. After that, the constructor tries to create one with NEW_KEYSET, which fails with NTE_EXISTS. (?) > -Original Message- > From: Milan Tomic [mailto:[EMAIL PROTECTED] > Sen

RE: Problem with WinCAPICryptoProvider

> In the constructor of WinCAPICryptoProvider, the first call > to CryptAcquiryContext fails with NTE_BAD_KEYSET. After that, > the constructor tries to create one with NEW_KEYSET, which > fails with NTE_EXISTS. (?) Keys are corrupted. After you receive NTE_BAD_KEYSET for the first call t

RE: Problem with WinCAPICryptoProvider

Thanks for your help, that works. Wouldn't it be a good idea to change the constructor of the lib to adapt this behaviour? At my customers site we had two users experiencing this problem (indeed, it is a user problem, not a computer problem). Two out of 180 makes me believing that this problem is n

RE: Problem with WinCAPICryptoProvider

I have already commited this today into XSEC C++ lib. :) Keys might become corrupted because someone with admin rights run your app, and after that someone with lesser rights run it again on the same PC (two users). Or something like that. In the WinCAPICryptoProvider ctor there is another call

xml-sec 1.3C1

Hi again, I have taged and upload to apache the 1.3RC1. This version has several bugs fixeds. (The changelog will be update at the end). There is only one open bug in bugzilla (thanks a lot Sean!!!) and it really seams a WONTFIX one. There is only one suspecting issue reporting in the mailling l

DO NOT REPLY [Bug 35960] - Enveloped Signature Transform failed after a transform producing an octet stream output

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: xml-sec 1.3C1

Hehehe...you compiled using JDK1.5...please compile with JDK1.3? (or at least 1.4?) thanks, dims On 8/18/05, Raul Benito <[EMAIL PROTECTED]> wrote: > Hi again, > > I have taged and upload to apache the 1.3RC1. This version has > several bugs fixeds. > (The changelog will be update at the end).

Re: xml-sec 1.3C1

Quick test suggests it works fine with my app :-) (not exaustive testing but it should have exercised the changes I suggested in XMLCipher: reference parsing & exposing encryptData ) C Raul Benito wrote: Hi again, I have taged and upload to apache the 1.3RC1. This version has several bugs f