Replace sha1 fingerprints with sha256

[tkrizek]

• we probably want to keep SHA1 for DNS SSHFP (along with SHA256)
• removing SHA1 from RSA-OAEP probably doesn't have any benefits http://security.stackexchange.com/questions/112029/should-sha-1-be-used-with-rsa-oaep
• SHA1 for otp will be handled in a separate PR

[tiran]

Let's step on the breaks first and do a proper threat analysis. Is it really necessary to drop SHA-1 like a hot potato and go for SHA-256 right now? It still takes a lot of effort to create a SHA-1 collision. It hasn't been shown for certificates yet.

• SHA-1 in OTP is fine. OTP uses HMAC and truncated hashes. The attack doesn't apply to HMAC-SHA1. There are also severe compatibility issues. Some commonly used OTP generators only support SHA-1. Before we change OTP, we must make sure that our own OTP generator, Google's OTP generator, and Yubico's OTP generator in all Yubikey's work. (I'm using Yubico Authenticator over NFC).

• Is SHA-256 the correct answer? What about SHA-224 or SHA-384 or a totally different approach like SHA3-256? MD5, SHA-1 and SHA-2 have a similar design (Merkle-Damgard construct but different compression function).

• Should we replace SHA-1 with SHA-2 in a hard cut or can we safely offer both hashes for a while to go through a proper deprecation cycle? Do users or customers depend on SHA-1 hash values?

update ENOCOFFEE, I meant to say that some OTP generators only support SHA-1 properly.

[MartinBasti]

https://www.redhat.com/archives/freeipa-devel/2017-February/msg01083.html

This was discussed in that thread and resolution is to not remove sha1

@tiran sha256 is already used in some IPA parts so we are closing the circle to have it everywhere, if you want additional fingerprints feel free to open discussion on freeipa-devel