> 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

Reply via email to