office-gobmx/libxmlsec
Caolán McNamara efca6f1560 fix patch path
Change-Id: I3da11f199cdb6b9394e99fc549cff2388a04d6b2
2012-12-06 09:09:38 +00:00
..
include
prj
src
ExternalPackage_xmlsec.mk fix libxmlsec delivering with mingw 2012-12-01 13:56:17 +01:00
ExternalProject_xmlsec.mk fix(?) libxmlsec build with mingw 2012-12-01 11:31:20 +01:00
Makefile
Module_libxmlsec.mk
README
UnpackedTarball_xmlsec.mk fix xmlsec build under RHEL-5 (again) 2012-12-06 08:53:35 +00:00
xmlsec1-1.2.14-ansi.patch
xmlsec1-1.2.14_fix_extern_c.patch
xmlsec1-1.2.14_old_automake.patch
xmlsec1-android.patch
xmlsec1-configure-libxml-libxslt.patch
xmlsec1-configure.patch our xmlsec setup calls autoreconf, so patch Makefile.am too 2012-12-01 13:46:15 +01:00
xmlsec1-customkeymanage.patch
xmlsec1-mingw-keymgr-mscrypto.patch
xmlsec1-mingw32.patch fix patch to apply after gbuild changes 2012-12-01 10:17:48 +01:00
xmlsec1-noverify.patch
xmlsec1-nssdisablecallbacks.patch
xmlsec1-nssmangleciphers.patch
xmlsec1-olderlibxml2.patch
xmlsec1-oldlibtool.patch fix patch path 2012-12-06 09:09:38 +00:00
xmlsec1-vc.patch

XML signing, etc. From [http://www.aleksey.com/xmlsec/]. Heavily patched.

The XML Security library has been modified, so that there is NO verification of
the certificate during sign or verification operation. On Windows this was done
in the function xmlSecMSCryptoX509StoreVerify (file src/mscrypto/x509vfy.c) and
on UNIX in xmlSecNssX509StoreVerify (file src/nss/x509vfy.c).

The implementation creates certificates from all of the X509Data children, such
as X509IssuerSerial and X509Certificate and stores them in a certificate store
(see xmlsec/src/mscrypto/x509.c:xmlSecMSCryptoX509DataNodeRead). It must then
find the certificate containing the public key which is used for validation
within that store. This is done in xmlSecMSCryptoX509StoreVerify. This function
however only takes those certificates into account which can be validated. This
was changed by the patch xmlsec1-noverify.patch, which prevents this certificate
validation.

xmlSecMSCryptoX509StoreVerify iterates over all certificates contained or
referenced in the X509Data elements and selects one which is no issuer of any of
the other certificates. This certificate is not necessarily the one which was
used for signing but it must contain the proper validation key, which is
sufficient to validate the signature. See 
http://www.w3.org/TR/xmldsig-core/#sec-X509Data 
for details.

There is a flag XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS that can be set
in a xmlSecKeyInfoCtx (see function xmlSecNssKeyDataX509XmlRead, in file
src/nss/x509.c), which indicates that one can turn off the validation. However,
setting it will cause that the validation key is not found. If the flag is set,
then the key is not extracted from the certificate store which contains all the
certificates of the X509Data elements. In other words, the certificates which
are delivered within the XML signature are not used when looking for suitable
validation key.