------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=674 --- Comment #12 from Phil Pennock <[EMAIL PROTECTED]> 2008-08-14 21:31:18 --- Do you have a pointer to a standards document or policy statement from a major CA that they're going to start using sha256 publicly? Or Bruce Schneier saying "Exim folks, just do it!" ;) (The latter would be good enough for me). Exim really should not be getting into the digests business if we can avoid it; we're not cryptographers (AFAIK) and we're not qualified to make assertions of what people should or should not be using, especially if that becomes dated. Now, my personal understanding is that the weaknesses in the current standards means that sha256 is a favoured intermediate step pending the completion of that NIST competition to find a new digest algorithm (similarly to the AES competition). Our assumption is that it is true that sha256 will be actively used in mainstream PKI then OpenSSL will be updated to load sha256 by default. Before Exim's maintainers start going around second-guessing the maintainers of cryptographic libraries that we depend upon, we need something firmer to verify that, for instance, we're more pragmatic than the other maintainers; I've not seen that verified and have no reason to believe it's true. Until there's a major push to start actually using sha256 I believe that most users touching it will be specialists able to configure software themselves, knowing that they're doing, and able to set tls_require_ciphers. I understand that this does not mesh well with network protocols where you're talking to systems maintained by others, but what are the options here? Traditionally, if someone cares enough and writes a patch, then the support spreads and the personal interests of the specialists become supported because they care; as long as that's not to the detriment of others, no real problem here and we'd accept patches. However, this particular area is one of the Exim project making assertions to others about what is or isn't safe. Before we do *that*, we really have to set a higher bar, IMO. I'm sorry that you're being held to a higher standard than is normal because of this. Since Exim is not really an end-user application, providing knobs for specialists to play with is fair enough. And if there's an OpenSSL API for loading specific named algorithms which we can expose by just passing it a string-list, so we could have "openssl_add_algorithm sha256" in a config file, I personally would be happy to see that in the config. If nothing else, in the event of a(nother) major cryptographic breakthrough acting as a forcing event to get people using stronger hashes in x509 PKI, it's good to have the ability to point to a configuration workaround before we bite the bullet and add the override code as a default. Note that here, we'd still be reacting to a policy statement from a major CA and the only reason for adding the explicit load would be that it lets us react faster than the lifecycle for getting a library rolled out by all our users. On mail-systems, I suspect that Exim updates are tracked more closely than OpenSSL ones. It's an ugly situation. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
