BoringSSL's SSL_CREDENTIAL API

[davidben]

Title: BoringSSL's SSL_CREDENTIAL API

Description: This is a heaps up that BoringSSL just landed a new API that might be useful for Envoy. Not a request to change anything, just a heads up, and also a request for thoughts if you all would prefer it work differently. I wasn't sure where to send this to feel free to redirect this elsewhere.

For a while, BoringSSL did not have a built-in way to select between RSA and ECDSA certificates. We left that to the caller. However, RSA vs ECDSA selection is quite complex, particularly at TLS 1.2 (TLS 1.3 dramatically cleans this up). Even within ECDSA, one may also have different curves. (Really ECDSA-P-256 and ECDSA-P-384 should be thought of as completely different key types. Though we continue to recommend sticking with P-256.) And, in the future, there will be post-quantum key types to juggle.

There are also other certificate negotiation decisions to make such as:

• Different kinds of credentials altogether (delegate credentials, raw public keys, external PSKs, perhaps even more future exciting things)
• We're very eager to have some kind of negotiation for trust anchors to help with PQ transitions and PKI agility

With all those moving parts, we thought it was better to have that in BoringSSL. SSL_CREDENTIAL is meant to be the place to configure that. The idea is that we combine everything related to a single "credential" into an object. Credentials may have different types, like X.509 certificate or otherwise. Each credential also has some criteria, based on TLS protocol rules, that determine whether it can be used on a connection. Callers configure an ordered preference list of credentials with BoringSSL, and we'll pick the first one that matches.

This can still be used in tandem with application-specific selection logic like SNI dispatch. The idea is that Envoy would use its criteria to select a list of candidates, such as an ECDSA and RSA certificate for that vhost. It would then configure the candidates, in preference order, with BoringSSL, and BoringSSL will evaluate those according to protocol rules.

Relevant Links: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#Credentials

[nezdolik]

cc @lizan @ggreenway

[ggreenway]

Yes, that sounds interesting and useful. Envoy currently has logic to determine if the client supports ecdsa. I'd love to have BoringSSL handle that type of thing.

One issue we'd run into is supporting both the old and the new version until there is a FIPS version of BoringSSL with the new Credentials API. We'd have to decide if we want to delay adopting the new API, or #ifdef it and have code for both versions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.