hash algorithms used for signatures

[hannesm]

fixes #123

for @psafont I added val signature_algorithm : t -> ([ `RSA | `ECDSA ] * Nocrypto.Hash.hash) option to the Certificate, Signing_request, and CRL modules. Does this suite you well?

The (chain) validation functions now receive an optional hash_whitelist argument, which the signature algorithm must match. The default is any SHA-2 algorithm (SHA256/SHA384/SHA512, not SHA224 - seems to be rarely used, I could not see a reason to include it). The default for valid_ca{,s} is any hash algorithm (following what others are doing).

/cc @emillon @paurkedal for a quick round of review -- this certainly changes the behaviour of x509 & tls -- in a good way forward (rejecting weak algorithms by default).

[emillon]

I'm not sure how in what order the checks are done, but it seems that if the hash is not trusted, you don't even need to walk the validation chain (or to do any kind of crypto). Not sure that easier to implement this way, though.

[hannesm]

let me briefly describe the implementation: the external entry points into validation are verify_chain and verify_chain_of_trust, where the latter is used by Authenticator.chain_of_trust.

Either verify_ function calls verify_single_chain as workhorse (with the chain in order server_certificate :: intermediate1 :: intermediate2 :: last_intermediate, the server certificate is already validated (in respect to is_server_cert_valid)).
Now, verify_single_chain is recursive, if only a single certificate is left, this is checked against the trust anchors. If multiple certificates are in the chain (cert :: issuer :: certs), the issuer is checked to be valid (validity period, CA extensions -- is_cert_valid), and signs is called subsequently with the path length (increasing on each recursive call), and the issuer and cert as arguments.

signs does four checks:

• does the issuer of the cert match the subject of the issuer cert?
• if the Authority_key_id and Subject_key_id are present in the certificates, do they match?
• validate signature (this does the actual work)
• is the path length sufficient (if the BasicConstraints extension is present in the issuer)

The validate_signature function purpose is as follows (with the following pieces: a certificate consists of three things: the to-be-signed-certificate data (public key, name, signature_algorithm, ..), the signature_algorithm (unsigned), and the signature itself)

• (a) extracts the RSA public key from the issuing certificate
• (b) decrypts the signature (Rsa PKCS1) -- this is the computationally intensive work, asymmetric crypto operation
• (c) decodes the output from above as PKCS1 digest info, resulting in a pair of sig_alg and hash value
• (d) compares sig_alg with signature_algorithm
• (e) computes the hash of raw tbs-cert -- as well computationally intensive work (hashing)
• (f) and compares the computed hash against the hash decoded from the signature value

now, this PR added "check against whitelist" between (c) and (d); I revised in 9375e07 to do the check between (a) and (b).

EDIT: fundamentally we have two signature_algo (one signed within the TBS, one part of the signature) that must be equal, and now in addition this signature_algo must be in the provided whitelist. The order of checks does not matter, as long as both equality and membership is ensured.

it seems that if the hash is not trusted, you don't even need to walk the validation chain

the implemented functionality walks the chain once, and does pairwise validation. I'm not keen on any preprocessing (as "check for the hash algorithms used in the signatures"), since that'd make the code less readable IMHO (it is complex since some properties need to be checked, as well as potentially existing extensions, the absence of other extensions, etc.). RFC 5280 contains a detailed description of path validation, implemented here (apart from missing things such as name constraints #65).

I'm not sure how in what order the checks are done

I hope the above explains it better to you. For me the above is rather clear from the code, do you have any suggestions on how to improve the structure (or naming?) to make the code easier to follow?

[emillon]

that all makes sense, thanks for the writeup!

[psafont]

This will work wonders, thank you!