Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I have a service and I want to authenticate my clients using SSL client certificates. Now I want the key exchange process to be as simple as possible, kind of like SSH: You generate a keypair and upload the public key to the server (which you already trust).
Now I want to verify the certs I get from the clients… not by their trust chain, but solely based on the certificates I have stored on the server.
Should I compare the whole certificate or only the SHA256-Hash?
Your problem boils down to the following:
So can an attacker show up with a value $v'$, distinct from $v$, such that $h(v') = h(v)$ ? If the attacker can, he wins. If he cannot, then storing $h(v)$ is sufficient.
If the hash function is second preimage resistant, then, by definition, the attacker cannot. SHA-256 is believed to be second preimage resistant.
I must also insist that the certificate is only the public part; the server must still extract the public key from the certificate sent by the client, and use it to verify the signature sent by the client as part of the ClientKeyExchange handshake message. Normally, the SSL implementation takes care of that point.
An edge case happens with DSA public keys. A DSA public key contains some parameters (modulus $p$, subgroup order $q$, generator $g$) and the actual user-specific public value ($y$). It is allowed, as per X.509, to omit the parameters from the certificate, keeping only $y$, if the certificate is signed by a CA which also uses DSA with the same parameters. This is parameter's inheritance. This is not compatible with your idea, because the client's public key cannot then be extracted from the user's public key alone; you still need X.509 path validation. But, in practice, this won't happen: nobody really uses DSA certificates, let alone DSA with parameter inheritance.
