diff options
author | Kurt Zenker <kz@openoffice.org> | 2009-10-14 16:21:13 +0000 |
---|---|---|
committer | Kurt Zenker <kz@openoffice.org> | 2009-10-14 16:21:13 +0000 |
commit | 618a4653360de8d1584d9ece2288b475054eac78 (patch) | |
tree | 9b64d362c97ab7b1bc4da9c5f5c418729158a23b /libxmlsec/readme.txt | |
parent | #i105697# Patch by pjanik: Use 'linux-generic64' to configure openssl. (diff) | |
download | core-618a4653360de8d1584d9ece2288b475054eac78.tar.gz core-618a4653360de8d1584d9ece2288b475054eac78.zip |
CWS-TOOLING: integrate CWS jl135_nss
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
Diffstat (limited to 'libxmlsec/readme.txt')
-rw-r--r-- | libxmlsec/readme.txt | 50 |
1 files changed, 29 insertions, 21 deletions
diff --git a/libxmlsec/readme.txt b/libxmlsec/readme.txt index 6217aef908a7..b518c6222687 100644 --- a/libxmlsec/readme.txt +++ b/libxmlsec/readme.txt @@ -1,24 +1,32 @@ -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 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). -This change requires that the XML Signature contains in -Signature/KeyInfo/X509Data only entries which represent the same -certificate. -The implementation creates certificates from all of the X509Data children -(X509IssuerSerial, X509Certificate) and used to iterate over all certificates, -verify them and return the first "good" certificate. Now the first one is -used. +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. -The X509IssuerSerial information is used by XML Security Library to find the -certificate in the certificate store on the machine. The X509Certificate entry -is used to create a certificate no matter if this is already contained in the -certificate store. -Do not forget: Suggest to XML Security Library to provide a way to carry out -signature operations without verification of certificates. There is 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 such a possibility but it does not work. |