Reject a privateKey or publicCert that holds several keys with no single reading

[cjbarth]

Summary

Follow-up to #606, which documents the 6.x behavior. Node's crypto loads one key from a privateKey or publicCert holding several, and which one it picks depends on their order and on what kind of message each one is. Nothing tells the caller that the others were ignored. #606 has the measurements and a reproduction.

The failure is closed, so 6.x only documents it. For 7.0, a value with no single reading should be an error.

Expected

• computeSignature() throws when privateKey holds more than one private key. A private key stored together with its certificate stays valid.
• checkSignature() throws when the publicCert it verifies with holds a public key together with any other key or certificate.
• Several certificates with no public key stay valid, and verification keeps using the first, as Document that privateKey and publicCert use only one of several keys #606 documents. That is also what a certificate chain given leaf first looks like. Do not make verification try each key: a chain holds its issuer's certificate, so that would accept documents signed with the issuer's key.

If #545 changes the forms a key can be supplied in, apply these rules to the string and Buffer forms that remain.

Release notes

This is a breaking change: the PR needs the breaking-change and semver-major labels and an entry in the README's Upgrading section. #606 adds a 6.4 warning for exactly these cases, so the Upgrading entry should use the same wording, letting callers who saw the warning find it.

[cjbarth]

Closing as not planned.

privateKey and publicCert are typed crypto.KeyLike, so what counts as a valid key value is whatever Node's crypto reads. RFC 7468 section 2 says "Files MAY contain multiple textual encoding instances". Node reads these values and uses one key. A signature made with an ignored key is rejected, so the failure is already closed.

Rejecting these values here would mean re-parsing, on every sign and verify call, key material that Node parses anyway, and deciding for Node which messages it would load. That work is outside this library's scope and adds nothing to security.

#611 documents the behavior instead. It says each value holds one key, verification uses the first of several certificates, and trusting several keys means verifying with each in turn.