------- 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 <exim-dev@???> 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
