RE: Canonicalization Validation

validation. How can I validate the canocalization of this document? Eduardo Mourão SEFIN/CRE/GEINF Fone: (69) 3211-6100 ramal 1054 0800647-4700 On Fri, Jul 24, 2009 at 12:00 PM, Jesse Pelton wrote: This sounds a lot like an issue that made me nuts a couple of weeks ag

RE: Canonicalization Validation

This sounds a lot like an issue that made me nuts a couple of weeks ago. By default, the .NET framework's XmlDocument.LoadXml() discards whitespace. Your partner will need to set XmlDocument.PreserveWhitespace = true before loading the document. If they're already doing that, I haven't a clue.

RE: Invalid Signature problem through Empty elements are converted to start-end tag pairs

In case it isn't obvious (it wasn't to me at first), the fact that an element appears as "" in the signed document does not mean those are the bytes that were used in generating the signature. The point of canonicalization is that a canonical form of the document is used to calculate the hash, but

RE: Attribute normalization !!

According to section 3.3.1 , "XML attribute types are of three kinds: a string type, a set of tokenized types, and enumerated types," and string types are CDATA. In addition, section 3.3.3 says, "All attributes for which no declara

RE: encrypt with pkcs12 private key

, March 21, 2008 3:02 PM To: security-dev@xml.apache.org Subject: Re: encrypt with pkcs12 private key Also, you said "encryption", but the exceptions below seem to indicate that you are trying to sign, not encrypt. Jesse Pelton wrote: Why would you want to encrypt with a private

RE: encrypt with pkcs12 private key

Why would you want to encrypt with a private key? Anyone with the corresponding public key (which is, after all, public) can decrypt the message, rendering the encryption useless. From: huang zhimin [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 12:37 PM

RE: What is XMLUtils::addReturnToElement for?

By my reading of the Apache License, Version 2.0 (which is the XML Security license), you are under no obligation to distribute source code. Of course, if you plan to distribute the code for your project, that pretty much has to include your modifications to XML Security code. If that's the situa

RE: Found several bugs in XML-Security 1.4.0 (Java)

I think Sean was asking you to do so. This will ensure that you'll be properly recorded as the reporter of the bugs, which can facilitate their management. I'd recommend two bug reports, one for each issue. From: Lijun Liao [mailto:[EMAIL PROTECTED] Sent: Wednesd

Copy-on-write for C++ XML Security's safeBuffer class

Has anyone considered whether copy-on-write semantics would be useful for safeBuffers? Under a profiler, it looks like my application spends an astonishing amount of time in the memcpy() in safeBuffer::operator= (const safeBuffer &). If safeBuffer strings are typically written after being copied,

RE: TLP Resolution

ntuario(Spanish), Santuarium(Latin) or a synonym Tabernaculum... Just wild guessing.. On 5/3/06, Jesse Pelton <[EMAIL PROTECTED]> wrote: > Good catch. It's a registered trademark, no less, and in a related > field, so I doubt SecureWave would be pleased to have Apache use it for > a

RE: TLP Resolution

Good catch. It's a registered trademark, no less, and in a related field, so I doubt SecureWave would be pleased to have Apache use it for a project name. Too bad. -jesse- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 10:26 AM To:

RE: Using XERCES with XPath support

Why not keep your current code, serialize your resulting document, and hand the output to xml-security for signing? It means including two DOM implementations in your project, but avoids modifying either your existing code or xml-security.   Another option might be to use the Pathan XPath lib

RE: JDOM - Sign validation

hbiBHZXVlci1Qb2xsbWFubjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAiMyPaBtjyD45i3iNi/ijObw+XrmiMgADOSUAo62MjBK6A1qZb4uwhrF+vSkWfrdpmW1yfH0H UTOAT4pgNc8UWn8WH61LRlj5MBnVF5f32DBqxgXs7K3i42W3xWeMr7cPwuD00qOeisbiLuTSKg8a xsmf+ATnZWBMTpH7O5NtxFsCAwEAATANBgkqhkiG9w0BAQQFAAOBgQB0ZO7ZSvIbtWLKtUrypyEp P+Q5Ly1Fd2++/K+Fr8d6

RE: JDOM - Sign validation

So, if you serialize the original DOM (canonicalized), convert to JDOM, convert back to DOM, and serialize the resulting DOM (canonicalized), how do the two serializations differ? It sounds like the content of the document is being changed in some non-trivial way somewhere in the JDOM <-> DO

RE: Document removes xml header

other kind of serialization or want to write it himself in output stream it can write it, and the signature will be completely valid as there is nothing in the spec against it. On 3/23/06, Jesse Pelton <[EMAIL PROTECTED]> wrote: > The signature has to be calculated on the canonical form

RE: Document removes xml header

The signature has to be calculated on the canonical form of a document, but I don't think there's any requirement that the signed document has to be serialized in canonical form. The point of requiring canonicalization is that the document may be altered in insignificant ways (such as attribute re

RE: TLP Resolution

Some random ideas to get the name game going, based on your indicated vision for the project: "SecureSoft," "Security Software," "Vault," "Shield," "Armor," "Guard," "Sanctuary," ,"Citadel," "Surety," "Security Blanket" (or "Linus," with a nod to Charles Schulz' "Peanuts," but you'd want to get per

RE: Xmlsec vs. ApacheSecurity project

I can't really answer any of your questions, but having used both libraries, I have some additional points to offer. First, Aleksey's project is, well, Aleksey's. He's incredibly competent, responsive, and helpful, and he's happy to have patches. That said, he was (last I checked) the only commit

RE: why would this code fragment cause XSec1.2.0 to leak memory?

Name(config.idAttributeName);    sig->registerIdAttributeNameNS(config.idAttributeNS, config.idAttributeName);    sig->load();      sig->setSigningKey(X509->clonePublicKey());    sig->verify();     prov->releaseSignature(sig);    

RE: why would this code fragment cause XSec1.2.0 to leak memory?

Have you tried running a debug build of your code under the debugger? After the program terminates, you may find memory leaks listed in the output window. Sometimes there's enough information to make it obvious where the leak is, sometimes not. (It's a good idea to do this in the course of d

RE: (OT) How to uniquely identify a X509 Certificate ?

;t avoid > doing signature verification just because you have cached a > copy of the > certificate. > > Matt > > -Original Message- > From: Jesse Pelton [mailto:[EMAIL PROTECTED] > Sent: Monday, August 29, 2005 3:24 PM > To: security-dev@xml.apache.org >

RE: How to uniquely identify a X509 Certificate ?

This assumes, of course, that issuer names are unique. This is obviously a desireable property of such names, and I've always assumed that it's the case, but I don't know if there's any mechanism that guarantees it. Is there a global registry of CAs or something similar? > -Original Message-

RE: SVN

I may just be an old dog incapable of learning new tricks, but I've had a hard time trying to figure out some things since Xerces moved to Subversion. (I don't remember what specific problems I've had, unfortunately, just that I had a hard time with something that would have been trivial for me wi

RE: How do I avoid creating buffers just to pass data to MemBufInputSource()

elevant to this list because > of the last > param of "XSecMem" in MemBufInputSource(). > > Thanks again > > > -Original Message- > From: Jesse Pelton [mailto:[EMAIL PROTECTED] > Sent: 19 August 2005 14:47 > To: security-dev@xml.apache.org >

RE: How do I avoid creating buffers just to pass data to MemBufInputSource()

You can prevent MemBufInputSource from cloning the buffer with MemBufInputSource::setCopyBufToStream(false). I think you can avoid the need for any buffers by implementing your own InputSource and BinInputStream. It looks to me like you only need to implement InputSource::makeStream(), BinInputSt

RE: Use of URIs rather than enums in C++ library

> -Original Message- > From: Berin Lautenbach [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 05, 2005 5:42 AM > To: security-dev@xml.apache.org > Subject: Re: Use of URIs rather than enums in C++ library > > I was thinking something similar, but maybe wait until a 2.0 release > before r

RE: Enveloped suggestions

Canonicalization leaves whitespace in document content alone (though any whitespace in element tags - that is, between the '<' and '>' that start and end a tag - is normalized). See http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-WhitespaceInCont ent. What behavior are you seeing that see

RE: C++ - 1.2 Release Candidate 1

Works here! > -Original Message- > From: Berin Lautenbach [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 12, 2005 7:45 AM > To: security-dev@xml.apache.org > Subject: C++ - 1.2 Release Candidate 1 > > Peoples, > > I have put archives of the 1.2 code at : > > http://people.apache.org/~

RE: Whitespace in SignedInfo element invalidating signature?

Title: Whitespace in SignedInfo element invalidating signature? I don't think there's quite enough information to make a definitive diagnosis (for instance, you don't specify what your "custom transform" is), but it sounds like you're making changes to the SignedInfo element that are not remo

RE: XML-Security-C memory leak

> From: Berin Lautenbach [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 08, 2005 5:43 AM > To: security-dev@xml.apache.org > Subject: Re: XML-Security-C memory leak > > Jesse Pelton wrote: > > OpenSSLCryptoBase64::b642BN() leaks memory in the following line: > > &

RE: building c++ xsec1.1

r1, str2XMLCh) == 0); delete [] str2XMLCh; }..   -Harish Jesse Pelton <[EMAIL PROTECTED]> wrote: Assuming you're successfully linking against the Xalan library, the only other thing I can see is that there might be a namespace issue. XSec appears

XML-Security-C null pointer dereference

If a document has a signature without a element, DSIGReference::verifyReferenceList() gets passed a NULL DSIGReferenceList. It does not check the pointer before dereferencing it. The problem can be reproduced by running checksig on the attached document. Fall down, go boom! Changing:

RE: XML-Security-C with OpenSSL overly strict about base64 line lengths

> Sent: Saturday, March 19, 2005 9:28 PM > To: security-dev@xml.apache.org > Subject: Re: XML-Security-C with OpenSSL overly strict about > base64 line lengths > > Jesse Pelton wrote: > > > OpenSSLCryptoKeyRSA::verifySHA1PKCS1Base64Signature() uses OpenSSL's > &g

RE: building c++ xsec1.1

I did build xalan1.7 but of no use. I keep getting the link errors. I removed the comment for #define XSEC_NO_XALAN . Then it could buid fine. -Harish Jesse Pelton <[EMAIL PROTECTED]> wrote: Sorry, I shouldn't have said you need to build Xalan, just that you

XML-Security-C with OpenSSL overly strict about base64 line lengths

OpenSSLCryptoKeyRSA::verifySHA1PKCS1Base64Signature() uses OpenSSL's EVP_Decode...() routines to decode the base64 contents of SignatureValue. This fails if line breaks don't occur where OpenSSL thinks they should. I think this is contrary to the specification (see rationale below), and that this

RE: building c++ xsec1.1

lding xalan1.7.   -Harish   Jesse Pelton <[EMAIL PROTECTED]> wrote: Did you build and link Xalan or define XSEC_NO_XALAN in XSEC32Config.hpp? You'll need to build Xalan if you require XPath support, otherwise you can tell XSec to build without it.

RE: building c++ xsec1.1

Did you build and link Xalan or define XSEC_NO_XALAN in XSEC32Config.hpp? You'll need to build Xalan if you require XPath support, otherwise you can tell XSec to build without it. From: harish suvarna [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 7:32 PMTo: security-d

RE: Bug in XSCryptCryptoBase64.cpp

Interesting question! I dug around in my parchment scrolls, and it turns out that the ambiguous order of execution goes way back. My ancient K & R says, "expressions involving one of the associative and commutative operators (*, +, &, ^, |) can be rearranged even when parenthesized. In most case

1.2 C++ release

About 10 days ago Berin mentioned that he was preparing for a 1.2 release. I'm curious how that's progressing. (What I really want to know, of course, is when it might be out.)

RE: XML-Security-C memory leak

ere's any harm in calling them: RAND_cleanup() X509_TRUST_cleanup() ERR_remove_state(0) -Original Message- From: Berin Lautenbach [mailto:[EMAIL PROTECTED] Sent: Tue 3/8/2005 5:42 AM To: security-dev@xml.apache.org Subject: Re: XML-Security-C memory leak Jesse Pe

XML-Security-C memory leak

OpenSSLCryptoBase64::b642BN() leaks memory in the following line: return BN_dup(BN_bin2bn(buf, bufLen, NULL)); BN_bin2bn() allocates a BIGNUM, so there's no need to dup it, and doing so causes the first one to leak. This is not the only leak I'm seeing in my app, but it's the only one I'

RE: OpenSSLCryptoKeyRSA::m_keyType not used?

Would a bug report be a help or a nuisance? > Berin Lautenbach wrote: > > Looks obsolete to me :>.

OpenSSLCryptoKeyRSA::m_keyType not used?

Is OpenSSLCryptoKeyRSA::m_keyType obsolete? It looks to me like the only place it is used is in OpenSSLCryptoKeyRSA::clone(), and even there it is just copied. Furthermore, it is private, and OpenSSLCryptoKeyRSA::getKeyType() provides a public (and probably more robust) way to get the key type ba

Dynamic_cast in XML-Security-C

None of my company's code currently relies on real-time type information (RTTI), so we disable it to avoid the overhead. This is possible in part because Xerces-C explicitly does not use RTTI (to ensure portability). XML-Security-C, on the other hand, uses dynamic_cast<> and thus relies on RTTI.

RE: C++ lib support for SHA-256, etc.?

> I also think it's a mistake for XMLSig and similar specs to > require only one > or two algorithms be supported. It's a recipe for a big mess > later, seems to > me. Interesting point. If one of the required algorithms is really broken, it may be difficult to reach consensus on what to use in

RE: Verify signature: bad for enveloped, ok for enveloping and detached.

ilto:[EMAIL PROTECTED] > Sent: Wednesday, February 02, 2005 10:25 AM > To: security-dev@xml.apache.org > Subject: RE: Verify signature: bad for enveloped, ok for > enveloping and detached. > > --- Jesse Pelton <[EMAIL PROTECTED]> a écrit : > > You need to include the

RE: Verify signature: bad for enveloped, ok for enveloping and detached.

You need to include the enveloped signature transformation specifically. This serves to remove the signature element from the document before signing and verification. This is required because the signature element changes during signing; if the original signature element were part of the sign

Minor issue in C++ library

utils/winutils/XSECBinHTTPURIInputStream.cpp borrows heavily from xercesc/util/NetAccessors/WinSock/BinHTTPURLInputStream.cpp, including a doubtful practice that leads to linker warnings under some circumstances. The fix is trivial. The problem is that both files in question declare the same set

Xerces-C 2.6

The March 2004 news item at http://xml.apache.org/security/c/index.html indicates that version 1.1 of the C++ library supports Xerces-C 2.3 - 2.5. Is it known whether Xerces-C 2.6 is supported?