> Or do you have some requirements, e.g. PCI compliance? > > [First Data] Yes there are PCI requirements that must be met. As pointed out > by Peter Bowen, those requirements have not yet prohibited SHA-1 > certificates.
I think that's a miscategorization of what Peter said. He was simply stating what is included in documents on a specific company's website. [[ Please note that I am not a QSA, and you should consult your own QSA for PCI related things... however, I believe the following is logical. ]] PCI has not specifically allowed or rejected the use of SHA-1 hashes. But, PCI does require "strong cryptography", of which hashes are a subset. Specifically, in the DSS v3.2, it says "Use strong cryptography and security protocols" and to ensure "Only trusted keys and certificates are accepted" Strong cryptography is defined as "Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength)" It then points to NIST SP 800-57 part 1 for clarification. NIST SP 800-57 part 1 (rev 4) says in Table 3 that SHA-1 has less than or equal to 80-bits of security and points to NIST 800-107 for the security implications of the hash algorithms. 800-107 says, "SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security" NIST SP 800-175B backs that up saying, "Note that attacks on SHA-1 have indicated that SHA-1 provides less security than originally thought when generating digital signatures [...] consequently, SHA-1 is now disallowed for that purpose" Therefore, an argument can be made that a new SHA-1 signature for a certificate is prohibited by PCI. _______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public