Stop supporting SHA-1 for signing CSRs

[omorsi]

This PR solves issue #143 and also removes insecure MD2 and MD5 hashing algorithms.

Copying the issue description here to save readers' time.

Since SHA-1 is insecure (attacks), this issue is to propose to stop supporting clients using it to sign CSRs.

SHA-1 can be used to sign CSRs using micromdm/scep in the following cases:

• The scepclient default behavior is to sign CSRs using SHA1WithRSA. (This can be changed to SHA256WithRSA)

  scep/cmd/scepclient/csr.go

  Line 46 in 1078401

  SignatureAlgorithm: x509.SHA1WithRSA,

• Also signers can use SHA-1 if a challenge need to be added (This can be changed by removing SHA-1 support from x509util)

  scep/cryptoutil/x509util/x509util.go

  Line 308 in 1078401

  {x509.SHA1WithRSA, oidSignatureSHA1WithRSA, x509.RSA, crypto.SHA1},

• Also if the underlying crypto/x509 library supports SHA-1, CSRs with no challenge added can be created using signatures with SHA-1 (this case can't be controlled from micromdm/scep, maybe stopping the process and showing a warning)

[omorsi]

@pavolmarko FYI!

[jessepeterson]

Just curious why aren't MD5 and all other known hashes with insecurities not also removed here?

[omorsi]

Thanks @jessepeterson for pointing that out. I have also removed MD2 and MD5. Are there any other insecure algorithms in the list?

[omorsi]

@jessepeterson friendly ping on this one :-) What are your opinions about this change?

[jessepeterson]

In principal I don't have a problem with this. However per my comments in #143 about SCEP being, essentially, a legacy protocol used — in some cases at least — to support legacy CAs and/or legacy devices I have some worry about dropping legacy code in general. As long as we're willing to revisit this again if necessary and maybe guard behind Options (if it's found to be necessary) or warnings or whatever. For example I know of a commercial SCEP server that signs the PKCS#7 encrypted data using SHA1-RSA. However in that particular case the P7 library handles that for us and this is just for our CSR generation.

All that said this seems fine for now. :) Unless @groob has any input I think we can merge this.