There is no way to construct the optimum certificate chain

[briansmith]

Consider a server that has one or more end-entity certificates for a given hostname (e.g. ClientHello SNI value). Each end-entity certificate might have multiple valid certificate chains due to cross-signing and/or due to overlapping validity periods when CAs renew their CA certificates. The server can only return one certificate chain in the TLS handshake. Which one should it return?

Right now, webpki uses some simple heuristics to construct a valid certificate chain. It doesn't really put significant effort into building the "best" chain. So far, this seems to have generally sufficed for the purposes of web browsers (see the record of mozilla::pkix in Firefox, for example) but it isn't ideal for some server use cases.

Unfortunately it isn't clear that there is agreement on how to determine which certificate chain is best. If there is some agreement then it definitely makes sense to just implement the rules for selecting the best cert in webpki. If there's disagreement, then we might need to make the selection mechanism more flexible. Regardless, I think there's a lot of value in centralizing as much of the "best certificate chain" logic in webpki as we can.

See Cloudflare's CFSSL, which has implemented similar logic, to some extent.

Here are some of the criteria I'm most familiar with, which are relevant to certificate chain selection:

All else being equal, a certificate chain that is smaller in terms of bytes on the wire is better than a certificate chain that is larger.

All else being equal, a certificate chain that is shorter in terms of number of intermediate certificates is better than a certificate chain that is longer.

All else being equal, a certificate chain that isn't just about to become invalid due to certificate expiration is better than one that's just about to expire.

All else being equal, the server would prefer to use a certificate with a public key associated with a private key that uses an algorithm that is faster to sign with, vs. one that is slower to sign with.

All else being equal, the server would prefer to use a certificate with a public key associated with a private key that is highly protected (e.g. in a HSM) vs one that isn't as highly protected.

All else being equal, the server would prefer to use a certificate for which it has valid SCT proofs, stapled OCSP responses, etc. vs one for which it is missing those things.

All else being equal, the server would prefer to use a certificate chain that has a trust anchor that is most likely to be trusted by the client.