tls module serial numbers should have at least 20 bits of entropy

[dstufft]

Looking at the salt/modules/tls.py code I see that the _new_serial function creates a serial number based off a md5sum of ca_name, CN, and the time. This should be modified to have atleast 20 bits of entropy, but really the whole thing (or most of it) should probably just be random. This could be as simple as doing binascii.hexlify(os.urandom(20)).

The rationale is that one of the ways to defeat preimage attacks on certificate signing is by introducing entropy into the certificate payload. While an md5(ca_name + stuff + time) is unlikely to be exploited it would be considered best practice to provide as much entropy as possible in the serial. For those who are mega paranoid about fantastically improbable collisions you can do a smaller chunk from os.urandom and then add microtime to it and hexlify that payload.

In the guidelines for public CA's (https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_9.pdf section 9.6) it says:

CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy

[cachedout]

Wow, amazing catch! Thank you very much for reviewing the code so well. We will sure and get this cleaned up.

[dstufft]

If you tell me which branch to make the PR against and whether saltstack is "mega paranoid about fantastically improbable collisions" I can make a PR for this.

[cachedout]

We'll happily accept a PR against the develop branch for whatever level of paranoia you deem appropriate. :]

[cachedout]

@dstufft Did you still want to write a PR for this? Just checking in. :]