Stop supporting SHA-1 for signing CSRs

[omorsi]

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)

[jessepeterson]

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

👍

Also signers can use SHA-1 if a challenge need to be added (This can be changed by removing SHA-1 support from x509util)
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)

I'm 100% onboard with limiting the built-in SCEP client's default SHA-1 support.

However, I'd like to be careful about limiting the SCEP server's support for submitted CSRs — instead leaving those types of decisions up to the issuing CA. I think its implied that SCEP is used to support legacy clients given that SCEP is, well, SCEP. I don't think anything you've mentioned affects the server in my quick look, but I mention it none-the-less.

My $0.02.