Re: [xmlsec] Mscrypto IS patch
Attached is the implementation of the scheme outlined bellow. I have placed code in xmlsec-core so other xmlsec-crypto libraries can re-use it. Also I am going to remove src/mscrypto/bignum.c and include/xmlsec/mscrypto/bignum.h soon because there is nothing left in these files :) What happened with xmlSecMSCryptoNodeGetBigNumValue and xmlSecMSCryptoNodeSetBigNumValue ? Wouter ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] xmlsec-mscrypto code review (patch #3)
xmlSecMSCryptoX509StoreVerify() : ... The certificate chain is a list of certificates cert_0, cert_1, cert_2, , cert_N where Subject(cert_k) = Issuer(cert_k+1) where k = 0, ..., N - 1 The chain is valid if and only if 1) each cert in the chain is good (i.e. it has valid signature on itself, valid time restrictions not before/not after, it is not revoked by some CRL, ...); 2) the root of the chain (cert_0) is trusted by application You are right and xmlsec wants to use crypto engines to create certs chain. In typical case xmlsec has a certificate it is interested in and it just asks crypto engine if there is a valid chain for this certificate (using trusted certs in crypto engine and untrusted certs from the xmlsec and crypto engine). Unfortunately, MSCrypto does not provide such a function (to be precise, as I wrote in the email, this function is not available on Windows 9x). Instead it has a function CertVerifySubjectCertificateContext(cert, issuerCert) that (as far as I can understand) simply does a check that - cert is good (see above what does this mean) - Subject(issuerCert) == Issuer(cert) This check validates that issuerCert + cert can be a part of certificates chain but it does not validate the cert! Your code did not construct the certs chain longer than 2 certs and it did not verify that chain's root is trusted. Which is a big security hole from my point of view :) Yes, that is (of course) a security hole, and the code was not meant to behave like that. However the function CertVerifySubjectCertificateContext can also validate against CRL and current (local system) time. The CRL however must reside in the same certs store as the certificate, and it is not exactly clear to me how the MS verification proceeds internally. What I did is make seperate routines that check the certificate against given time, and against any given CRL. But what to do when no CRL is available? Just mark the cert as invalid, and disable it for usage in the lib? It may well be that another protocol is used for revocation checking. MS Crypto API does not have any CRL available for you, that must be handled by the application itself. The whole question about trust in the X509 PKI model is based on which certs you (your application) are marked as trusted. xmlsec library does not involved in these descsision. It's just something your have to do yourself as a system architect. However, xmlsec command line utility provides a way to say: I trust this certificate (--trusted option). The exact meaning of this is the cert specified with --trusted option can be root cert cert_0 for a valid certificates chain. If you have no trusted certs then you have no valid certificates chain. Current xmlsec-mscrypto implementation maintains its own list of trusted certs in the keys manager. As I wrote before, certs marked as trusted in the MS Crypto certs store are not considered as such by xmlsec due to the MSCyrpto API restrictions. I think it's a good idea to enable this functionality but it's a separate big task from the code review I did. My change was to just plug in a security hole in the certificates processing. You're right, and as far as I know, in MS Certs store certificates are even without revocation checking trusted there, not to mention other 'features' bugs MS has in the certificate validation scheme their using (who knows the scheme in the first place?) But thanks for you explanation, it sheds some light in my darkness :) I agree that the real validation of the certificates, if you want to do it full, can better be seperated from the lib, since it involves quite some complex processing. Wouter ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] xmlsec-mscrypto code review (patch #3)
But what to do when no CRL is available? Just mark the cert as invalid, and disable it for usage in the lib? If there is no CRL then it might not exist :) I think that the current code does right thing: - if CRL exists, check against it; - otherwise pretend you know nothing about it and continue Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
FW: [xmlsec] xmlsec-mscrypto code review
I have a document with different local documents that each shall be signed by a different certificate (Localdata). Can there be any problem then that I want just to sign the ALLDATA? It always seems to sign the first signature it finds, into the LOCALDATA... Best regards Jan-Olof Andersson !DOCTYPE test [ !ATTLIST ALLDATA ID ID #IMPLIED !ATTLIST LOCALDATA ID ID #IMPLIED ] DOC ALLDATA ID=ALL DATA LOCALDATA ID=LOCAL1 .. LOCALDATA Signature Signedinfo . Reference URI=#LOCAL1 . /Reference /Signedinfo . /Signature DATA DATA LOCALDATA ID=LOCAL2 .. LOCALDATA Signature Signedinfo . Reference URI=#LOCAL2 . /Reference /Signedinfo . /Signature DATA /ALLDATA Signature Signedinfo . Reference URI=#ALL . /Reference /Signedinfo . /Signature /DOC ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: FW: [xmlsec] xmlsec-mscrypto code review
First of all, I guess you are asking about xmlsec command line utility :) By default, xmlsec processes the first dsig:Signature/ or enc:EncryptedData/ node it finds in the input document. But you can override this by using following options: ./xmlsec1 help-sign | less ... --node-id id set the operation start point to the node with given id --node-name [namespace-uri:]name set the operation start point to the first node with given name and namespace URI --node-xpath expr set the operation start point to the first node selected by the specified XPath expression ... Aleksey It always seems to sign the first signature it finds, into the LOCALDATA... ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
RE: FW: [xmlsec] xmlsec-mscrypto code review
Thanks a lot!!! I assumed this but I wanted to confirm... Yes I using the command line utility! ;- Best regards -Original Message- From: Aleksey Sanin [mailto:[EMAIL PROTECTED] Sent: den 23 september 2003 11:26 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FW: [xmlsec] xmlsec-mscrypto code review First of all, I guess you are asking about xmlsec command line utility :) By default, xmlsec processes the first dsig:Signature/ or enc:EncryptedData/ node it finds in the input document. But you can override this by using following options: ./xmlsec1 help-sign | less ... --node-id id set the operation start point to the node with given id --node-name [namespace-uri:]name set the operation start point to the first node with given name and namespace URI --node-xpath expr set the operation start point to the first node selected by the specified XPath expression ... Aleksey It always seems to sign the first signature it finds, into the LOCALDATA... ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
RE: [xmlsec] xmlsec-mscrypto code review (patch #5) and todo list
B) Failing tests: - merlin-xmldsig-twenty-three/signature-keyname Something about loading some dll, looks like a problem with my cursed box and don't worry about it too much. This test has never worked for me. MS Crypto API cannot handle the certificate tests/merlin-xmldsig-twenty-three/certs/lugh.der. When loading the following error occurs: ASN1 bad tag value met. (Aleksey: beautiful error msg btw :) The test has never worked, and I don't think this error can be fixed easily. I'll check the ASN.1 structure to see if I can find anything wrong here. - merlin-xmlenc-five/encrypt-data-aes128-cbc Very strange error with decrypting the file encrypted a minute ago. This test works fine for me. - 01-phaos-xmlenc-3/enc-element-3des-kt-rsa1_5 01-phaos-xmlenc-3/enc-content-aes256-kt-rsa1_5 01-phaos-xmlenc-3/enc-element-aes128-kt-rsa1_5 01-phaos-xmlenc-3/enc-text-aes192-kt-rsa1_5 Problems loading private key? Yes, still the same problem. I tried to generate a new file with openssl, since the xmlsec openssl code is able to load the private key. However that still resulted in the same errors I got before, trying to create a certificate with the openssl command line tool (bad ASN.1, and missing data etc.). So the next idea I have is create the private key from the data with another library (SSH), create a private key there and the cert request. However it's been a while since I used that lib, and diving into that just for getting these tests to work is not very appealing... Possibly another appraoch is to create a 'better' rsa key with openssl, then is done. So instead of just the modulus, exponent, and private exponent, also generate the other values of the private key (forgive me for not remembering the exact names of the other values)? If I can, I'll spend some time to try something out getting the tests to work. My nearest plans are: 0) Look into failing tests from section B) above; 1) Make a minor code cleanup in src/mscrypto/x509.c and src/mscrypto/certkeys.c to improve maintanability. 2) Do one more code review pass (weekend?) 3) Think about running xmlsec-mscrypto with a memory leak checker. 4) Test xmlsec-mscrypto on Windows 9x (?) After that I would be ready to merge the mscrypto branch to the trunk, do documentation, file bugs for non-implemented things and release version 1.2 :) Wouter, would do you think about that? What are your plans? I'm not working or planning onto big changes at this moment. I'd rather see the lib stabelize more and getting ready for a release :) One thing I would like to see happening is exposing the memory key loading functions from OpenSSL and mscrypto to the main interface (like we discussed before) This would mean in also adjusting the NSS port, though it's not sure what the possibilities are with NSS. Aleksey: I'm happy to make the functions available, though if you can do it in 5 minutes, and are willing to do so, it is probably more efficient. In the meantime I'll try to help in getting the tests to work properly (see comments above). Wouter ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] xmlsec-mscrypto code review (patch #5) and todo list
Aleksey: I'm happy to make the functions available, though if you can do it in 5 minutes, and are willing to do so, it is probably more efficient. I think it's the same for both of us :) Just copy/paste in 10 places :) I doubt that there would be an interface in NSS but I'll take a look :) So change of plans for me: 0) Generalized api for loading keys from memory 1) Look into failing tests from section B) above (if I do not hear from you before); 2) Make a minor code cleanup in src/mscrypto/x509.c and src/mscrypto/certkeys.c to improve maintanability. 3) Do one more code review pass (weekend?) 4) Think about running xmlsec-mscrypto with a memory leak checker. 5) Test xmlsec-mscrypto on Windows 9x (?) Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
RE: [xmlsec] xmlsec-mscrypto code review (patch #5) and todo list
B) Failing tests: - merlin-xmldsig-twenty-three/signature-keyname Something about loading some dll, looks like a problem with my cursed box and don't worry about it too much. I've converted the lugh.pem file into lugh.der, and replaced the original lugh.der. Now the test is working. The original lugh.der I couldn't recognize as anything (der encoded) valid. I've attached the new lugh.der cert, so if no objections exist, it can replace the wrong original lugh.der. Wouter lugh.der Description: application/x509-ca-cert
Re: [xmlsec] xmlsec-mscrypto code review (patch #5) and todo list
This would cause problems for NSS because it does not understand PEM format. Can you try to convert this PEM file back to DER and try the result, please? Aleksey Wouter wrote: B) Failing tests: - merlin-xmldsig-twenty-three/signature-keyname Something about loading some dll, looks like a problem with my cursed box and don't worry about it too much. I've converted the lugh.pem file into lugh.der, and replaced the original lugh.der. Now the test is working. The original lugh.der I couldn't recognize as anything (der encoded) valid. I've attached the new lugh.der cert, so if no objections exist, it can replace the wrong original lugh.der. Wouter ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
[xmlsec] Emailing: EdTestFormNoMSO.zip
Aleksey, This attached is a signature which resulted from successive signings over the same XML from within Microsoft's InfoPath Release Candidate (i.e. coming soon). It is confusing in its use of copy and copy-of. Both signatures have enveloped-signature tranforms followed by XSLT tranasforms. The first signature uses 2 templates the 1st of which is a copy whereas the second signature uses a single template within a copy-of and matches on the @Id of the 1st signature. The second signature seems to cover only the first ? Is this a valid countersignature ? Secondly but related, how would one create parallel signatures over the same data using XMLSec ? Using 2 successive sign operations ? Assuming one is using a template, what would it look like for the 2nd sign operation ? For this 2nd pass, does the enveloped-signature transform only exclude the signature being applied (i.e. the 2nd) ? If so, what is the best way to exclude the 1st ? Thanks, Ed EdTestFormNoMSO.zip Description: Zip compressed data
Re: [xmlsec] Emailing: EdTestFormNoMSO.zip
Secondly but related, how would one create parallel signatures over the same data using XMLSec ? Using 2 successive sign operations ? Yes. Assuming one is using a template, what would it look like for the 2nd sign operation ? Template is just an XML file, remember :) For this 2nd pass, does the enveloped-signature transform only exclude the signature being applied (i.e. the 2nd) ? Enveloped transform by definition excludes only the current signature (see XMLDSig spec for details). It does not matter is it first or second signature. If so, what is the best way to exclude the 1st ? XInclude, XPath, XPath2 or XSLT transofrms are probably the simplest ways (you might have interop problems with XPath2). But probably I wouldn't use XSLT just for that task. Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
[xmlsec] RE: Emailing: EdTestFormNoMSO.zip
As it pertains to the example below, can you see any reason why Microsoft did not use xmldsig-filter2 ? Ed -Original Message- From: Edward Shallow [mailto:[EMAIL PROTECTED] Sent: September 23, 2003 11:35 PM To: '[EMAIL PROTECTED]' Subject: Emailing: EdTestFormNoMSO.zip Aleksey, This attached is a signature which resulted from successive signings over the same XML from within Microsoft's InfoPath Release Candidate (i.e. coming soon). It is confusing in its use of copy and copy-of. Both signatures have enveloped-signature tranforms followed by XSLT tranasforms. The first signature uses 2 templates the 1st of which is a copy whereas the second signature uses a single template within a copy-of and matches on the @Id of the 1st signature. The second signature seems to cover only the first ? Is this a valid countersignature ? Secondly but related, how would one create parallel signatures over the same data using XMLSec ? Using 2 successive sign operations ? Assuming one is using a template, what would it look like for the 2nd sign operation ? For this 2nd pass, does the enveloped-signature transform only exclude the signature being applied (i.e. the 2nd) ? If so, what is the best way to exclude the 1st ? Thanks, Ed ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] RE: Emailing: EdTestFormNoMSO.zip
I don't know but the reasons might be very different from what you think: 1) the don't have it implemented; 2) they have it implemented only in recent version and they need a backward compatible example; 3) they have it implemented but it's too buggy or slow to use it; 4) the guy who wrote this example never heard of it; 5) the guy who wrote this example likes xslt; 6) Bill Gates does not like xmldsig-filter2 and he ordered not to use it :) ... Aleksey Edward Shallow wrote: As it pertains to the example below, can you see any reason why Microsoft did not use xmldsig-filter2 ? Ed ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] xmlsec-mscrypto code review (patch #5) and todo list
Never mind. Sorry, I did not read your message carefully :( I have tried your file and it did not work for openssl (returned error) and crashed nss which is worse than the file we had before :) Anyway, I did the same conversion myself. The new file seems to be working fine on Linux (openssl/nss). And I could not test it on Windows because I start getting Keyset does not exist error for every CryptoAquireContext call. No idea why did this happen at all or when it'll be back to normal. I have attached the file (gzipped). Can you try it with xmlsec-mscrypto, please? Thanks, Aleksey! Aleksey Sanin wrote: This would cause problems for NSS because it does not understand PEM format. Can you try to convert this PEM file back to DER and try the result, please? Aleksey Wouter wrote: B) Failing tests: - merlin-xmldsig-twenty-three/signature-keyname Something about loading some dll, looks like a problem with my cursed box and don't worry about it too much. I've converted the lugh.pem file into lugh.der, and replaced the original lugh.der. Now the test is working. The original lugh.der I couldn't recognize as anything (der encoded) valid. I've attached the new lugh.der cert, so if no objections exist, it can replace the wrong original lugh.der. Wouter ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec lugh.der.gz Description: application/gzip
