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