On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin <s...@cs.columbia.edu> wrote:
> I've mentioned it before, but I'll point to the paper Eric Rescorla > wrote a few years ago: > http://www.cs.columbia.edu/~smb/papers/new-hash.ps or > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: > if you're running a public-facing web server, you *can't* offer a SHA-2 > certificate because you have no way of knowing if the client supports > SHA-2. Fixing that requires a TLS fix; see the above timeline for that. The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) Bodo --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com