Re: Negotiating the SCRAM channel binding type

On 11/07/18 12:27, Heikki Linnakangas wrote:
> Based on recent discussions, it looks like there's going to be
> differences in this area [1]. OpenSSL can support both tls-unique and
> tls-server-end-point. Java only supports tls-server-end-point, while
> GnuTLS only supports tls-unique. And Mac OS Secure Transports supports
> neither one. Furthermore, it's not clear how TLS v1.3 affects this.
> tls-unique might no longer be available in TLS v1.3, but we might get
> new channel binding types to replace it. So this is about to get really
> messy, if there is no way to negotiate. (Yes, it's going to be messy
> even with negotiation.)

I've been reading up on the discussions on GnuTLS and Secure Transport,
as well as the specs for tls-server-end-point.

In a nutshell, to get the token for tls-server-end-point, you need to
get the peer's certificate from the TLS library, in raw DER format, and
calculate a hash over it. The hash algorithm depends on the
signatureAlgorithm in the certificate, so you need to parse the
certificate to extract that. We don't want to re-implement X509 parsing,
so realistically we need the TLS library to have support functions for that.

Looking at the GnuTLS docs, I believe it has everything we need.
gnutls_certificate_get_peers() and gnutls_certificate_get_ours() can be
used to get the certificate, and
gnutls_x509_crt_get_signature_algorithm() gets the signatureAlgorithm.

The macOS Secure Transport documentation is a bit harder to understand,
but I think it has everything we need as well.
SSLCopyPeerTrust()+SecTrustGetCertificateAtIndex()+SecCertificateCopyData()
functions get you the certificate in DER format. You can get the
signature algorithm with SecCertificateCopyValues(), with the right
constants.

Am I missing something? I think we can support tls-server-end-point with
all TLS implementations we might care about.

- Heikki