XSTJ-36: xmlsectool has been ported from the old OpenSAML 2 software stack to OpenSAML 3. This means that xmlsectool relies only on supported software.
XSTJ-25: xmlsectool now requires at least Java 7 to run.
XSTJ-52: Now that the Java runtime's XML processing API implementations are sufficiently reliable, xmlsectool no longer depends on, or bundles, "endorsed" versions of them. One benefit of this change is that some cases in which xmlsectool previously inserted redundant namespace prefix definitions have been addressed (see XSTJ-4).
XSTJ-11: the Java package name has been changed to correspond to the Maven artifact ID. The main class name has also changed to correspond to Shibboleth project conventions. These changes have no effect on command-line operation, but means that environments in which the Java code is called directly must use a new entry point of net.shibboleth.tool.xmlsectool.XMLSecTool.
XSTJ-45: xmlsectool no longer creates log files in its home directory by default. This means that write access to the installation directory is no longer required to run xmlsectool. If the previous behaviour is desired, use the --logConfig command line option to supply a custom logging configuration.
XSTJ-54: errors are now still logged if --quiet logging is selected. If the previous behaviour is desired, use the --logConfig command line option to supply a custom logging configuration.
XSTJ-55: the --signatureRequired command line option has been removed. Its effect was always present by default and there was no way to negate it, rendering it entirely redundant.
XSTJ-35: it is now possible to sign using an elliptic curve credential taken from a file.
XSTJ-34: in line with current recommendations for digital signatures, the default signing digest algorithm has been changed from SHA-1 to SHA-256. Use the --digest command line option if you are sure that you need to override this.
XSTJ-39: in line with current recommendations for digital signatures, the SHA-1 digest algorithm has been added to the default blacklist, which now consists of MD5 and SHA-1. This means that some signatures accepted by xmlsectool V1.2.0 will not be accepted by default by xmlsectool V2.0.0. If you are sure that you need to override this, you can do so by using the new --whitelistDigest option to remove a specific digest algorithm from the blacklist, as an alternative to the combination of --clearBlacklist and --blacklistDigest options already available from V1.2.0.
XSTJ-51: ECDSA signatures are now schema-valid. The empty KeyValue elements produced by previous versions of xmlsectool are no longer included in the output.
XSTJ-44: (post beta 1) ECDSA signatures may now be made and validated on a wider variety of platforms.