618a465336
2009-10-01 15:20:03 +0200 jl r276605 : #1004856# moved to xmlsec1-mingw32.patch 2009-10-01 10:51:24 +0200 jl r276580 : #1004856# build keymgr with mingw 2009-10-01 10:50:52 +0200 jl r276579 : #1004856# build keymgr with mingw 2009-10-01 10:37:28 +0200 jl r276578 : #1004856# do not build xmlsec1 app 2009-09-29 16:01:31 +0200 jl r276532 : #1004856# Using libxml2 from solver if available 2009-09-26 16:31:32 +0200 jl r276477 : #i104856# xmlsec1-mscrypto-1 is now xmlsec1-mscrypto 2009-09-25 17:05:26 +0200 jl r276470 : CWS-TOOLING: rebase CWS jl135_nss to trunk@276429 (milestone: DEV300:m60) 2009-09-24 12:57:10 +0200 jl r276419 : #i104856# libxmlsec update 2009-09-24 12:46:58 +0200 jl r276418 : #i104856# fixing mac configure problem in configure.in and regenerating configure 2009-09-23 16:49:54 +0200 jl r276405 : i#104856# configure failed on mac 2009-09-23 10:21:35 +0200 jl r276369 : #i104856# adapting patches to apply cleanly and readme change 2009-09-21 13:45:47 +0200 jl r276326 : #i104856 updating to 1.2.12, using changes patches from cmc made on xmlsec1_2_12 2009-09-21 11:27:46 +0200 jl r276319 : #i105183# forget to uncomment PATCH_FILES 2009-09-18 17:41:20 +0200 jl r276296 : #i105183# update of nss libs |
||
---|---|---|
.. | ||
prj | ||
makefile.mk | ||
readme.txt | ||
xmlsec1-configure.patch | ||
xmlsec1-customkeymanage.patch | ||
xmlsec1-mingw-keymgr-mscrypto.patch | ||
xmlsec1-mingw32.patch | ||
xmlsec1-noverify.patch | ||
xmlsec1-nssdisablecallbacks.patch | ||
xmlsec1-nssmangleciphers.patch |
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 of 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.