...
...
The API has been slightly updated and a variety of deprecated methods have been removed, along with many public references to an older set of enumeration constants for algorithms of various sorts. The public APIs are now primarily URI-based such that future algorithm additions should not require public changes. So most code will be slightly broken but should require minimal modification to be updated.
There are significant changes to the support status of parts of the library that lack maintainers. The following features are deprecated at present and at risk of future removal:
All those features can be left out of the build to ensure no usage of them by downstream projects wishing to limit their security exposure and this is advisable.
Finally, the set of platforms formally supported by the maintainer of the library is limited, and no longer includes Solaris. Most releases of the library will likely build on most platforms, including Solaris, but likely with patches required that will be happily accepted by the project. The formal set of platforms supported is exactly the set supported by the Shibboleth Project, whose resources are the sum total actively maintaining this code.
While
The main development work for the library is done using OpenSSL, so this is the recommended option. However, Windows Crypto API and NSS interfaces are also now providedprovided, they are moribund, lack modern algorithm support, and are deprecated at present.
It is also possible to implement interfaces for other cryptographic libraries and pass them into the xml-security-c library during initialisation (via the XSECPlatformUtils::Initialise() call).
...
TL;DR, yes, OpenSSL is required.
No. The C++ crypto interface layer provided for the library provides only the smallest subset of cryptographic functions necessary for the library to make calls to the provided library. Applications will need to work directly with OpenSSL (or other libraries) to read and manipulate encryption keys that should then be wrapped in XSECCrypto* objects and passed into the library.
WinCAPI is the developmental interface being built to give users of the library access to the Windows Cryptographic library.
It is not a C API wrapper for the overall library.
...
There have been additions to the API over time to make the primitives in this library more usable as mechanisms for general operations, but they are not complete.
Yes, and the library now requires V3.2.0 or above. No older versions of Xerces are supported so any such use is highly ill-advised in any event.
The library can be compiled without linking to Xalan-c. However doing so will disable support for XPath and XSLT transformations.
To disable Xalan-c support either use --without-xalan when running configure on UNIX, or use the VC++ "without Xalan" settings.
No. Whilst the functionality required is available in prior versions, the location of include files changed in 1.6. A decision was made in version 1.0.0 of Apache XML Security for C++ to update the source to support these new locations.
...
If used, only the very latest Xalan release, 1.0.11, will successfully build with Xerces 3.2 and this library.
After you have created the XMLSignature object, before you sign the document, you must embed the signature element in the owning document (which is returned by the call to DSIGSignature::createBlankSignature(...)) before calling the DSIGSignature::sign() method,
...
If you have not embedded the signature node in the document, it will not have any parent or ancestor nodes, so it will not inherit their namespaces. If you then embed it in the document and call verify(), the namespaces will be found and the canonical form of SignedInfo will be different to that generated during sign().
...
During a signing operation, finding the correct Id attribute is vital. Should the wrong Id Attribute be used, the wrong part of the document will be identified, and what the user signs will not be what they expect to sign.
...
Warning In version 1.1 and above, the library defaults to searching for Id attributes by name if a search by Id fails. As this is a potential security risk, this behaviour may be changed in a future version of the library.
...
The library currently supports X-KISS (XML Key Information Service Specification) message generation and processing. Support for X-KRSS (XML Key Registration Service Specification) will be provided in version 1.3 of the library.
...
. XKMS support is optional with V2.0.0 and can be omitted from the build.
The XKMS support is deprecated.
Not yet. A command line tool xklient is provided for generating and processing messages. This can be used as an example for processing XKMS messages.A programmatic client will be provided in version 1.3 of the Apache XML Security for C++library.
