<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 3 Aug 2015 at 20:27 Thomas Voegtlin <<a href="mailto:thomasv@electrum.org">thomasv@electrum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/03/2015 10:41 AM, Tristan Seligmann wrote:<br>
> In addition,<br>
> quite a bit of the certificate handling code does things incorrectly<br>
> (see eg. the certificate chain verification code[1] that does not<br>
> check the certificate purpose, allowing anyone with a valid cert to<br>
> sign a fraudulent cert as if they were a CA).<br>
><br>
<br>
Instead of suggesting that there are "quite a bit" of incorrect things,<br>
and then citing one example, can you provide the full list of problems<br>
that you see?<br></blockquote><div><br></div><div>Sorry, I believe I owe you an apology for my carelessly written email. Firstly, I took a look at the code again, and I think the single issue I described does not actually exist, I probably misread the code before. (To be precise, while the code does not check the key usage, it *does* check the "Basic Constraints" extension which I believe is the correct check to prevent the flaw I mistakenly identified).<br><br>While it is quite possible for newly written certificate-handling / X509 code to be buggy simply due to the complex nature of what this entails, I don't have any specific issues to highlight at this time, and I can hardly claim to be an expert in this area myself, so I retract my previous claim.<br><br></div><div>However, the primary issue is still dealing with tlslite somehow: I do not think the FTP masters / security team will be happy with me distributing an embedded copy of tlslite in the electrum package, and I don't feel comfortable maintaining tlslite in Debian either way given the circumstances.<br><br></div><div>Note that python-cryptography is the "cryptography" library upon which python-openssl ("PyOpenSSL") is based, not "pycrypto" which is a different library; but cryptography does use cffi to bind to OpenSSL etc., so is also not pure python. Unfortunately most of the existing mature TLS / X.509 / etc. handling code exists in C libraries...<br></div></div></div>