CertFP broken on macOS

[ljrk0]

Hi there,

thank you for the most awesome IRC client :-)

Problem Statement

I've run into an issue when trying to setup SASL External on macOS. The code in question is part of the internal IRC implementation:

halloy/irc/src/connection.rs

Line 60 in b4dfd13

let pkcs12_archive = Identity::from_pkcs8(&bytes, &bytes)?;

The function from_pkcs8 receives two arguments, a PEM-encoded pem certificate-chain and the PKCS#8 (also basically PEM encoding) key. The former should contain the full certificate chain from the CA down to the user/leaf certificate, the latter the key for the leaf certificate. Using the instructions from Libera linked in the Wiki yields one PEM file combining private key and self-signed cert.

The macOS implementation is rather strict:

https://github.com/sfackler/rust-native-tls/blob/5db1b7772604d255381d847db5dd3a5b501c30a6/src/imp/security_framework.rs#L91

1. It requires -----BEGIN PRIVATE KEY to be the first bytes in key the file, otherwise it'll return errSecParam or "One or more parameters passed to a function were not valid."
2. It doesn't accept duplicate items, you'll get "The specified item already exists in the keychain."

Rust Native TLS API

Especially the latter completely breaks this implementation, due to the same values being passed to key and pem. Additionally, however, since from_pkcs8 is used on files which do not only contain key material, this may break in other ways as well.

Before c6d7e66 instead of from_pkcs8 the function from_pkcs12 was called. The PKCS#12 standard indeed allows for "everything" to be combined in one file, as it embeds not only the certificate chain but also can embed a PKCS#8 key file.

In result, an "Identity" in native-tls terms can be either constructed from a

1. PKCS#12 file containing both the certificate chain and the key for the leaf, or a
2. PKCS#8 file for the key only plus a PEM file with the certificate chain.

Unfortunately, this API doesn't easily allow for the format described in the Libera API which a PEM file (thus not PKCS#12) containing all required data.

Going Forward

I suppose the ideal solution is to:

1. Add another entry sasl.external.key which contains the PKCS#8 key and have sasl.external.cert only contain the user certificate + chain.
   • In order to stay backwards-compatible, perhaps set key = cert if key is lacking? But this'd be permanently broken on macOS
2. Perhaps add an entry sasl.external.combined which can contain a PKCS#12 combined file and would conflict with .cert or .key being set.

Note that it's virtually impossible to load the format described by Libera using Native TLS portably since especially the macOS version has many sanity checkers that e.g., reject certificates which also contains keys: https://github.com/sfackler/rust-native-tls/blob/5db1b7772604d255381d847db5dd3a5b501c30a6/src/imp/security_framework.rs#L213

Ideally, Native TLS would be consistent across platforms here, either always discarding unused data (as done with the OpenSSL backend) or complaining if a certificate contains a key, a key contains a certificate or certs are duplicated.