proposal: crypto/x509: expose hash algorithm for SignatureAlgorithm

[bodgit]

What version of Go are you using (go version)?

$ go version
go version go1.12.7 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/matt/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/matt/Documents/work"
GOPROXY=""
GORACE=""
GOROOT="/opt/local/lib/go"
GOTMPDIR=""
GOTOOLDIR="/opt/local/lib/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="/usr/bin/clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_k/xdj1vdy51gb4pbncgvq0p03w0000gn/T/go-build134256866=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

As part of generating TLS channel bindings (RFC 5929) it is necessary to generate a hash of a given certificate using the hashing algorithm used in its SignatureAlgorithm, (with some exceptions documented in the RFC). So for example a SignatureAlgorithm of x509.SHA256WithRSA should use crypto.SHA256 to generate its tls-server-end-point channel binding type, etc.

What did you expect to see?

I was hoping to have a method on SignatureAlgorithm to return its associated crypto.Hash. This information is available in the unexported signatureAlgorithmDetails struct.

What did you see instead?

For now, I have made my own map[x509.SignatureAlgorithm]crypto.Hash but as new algorithms are added this needs to be kept in sync, (x509.PureEd25519 for example has been added to the source since 1.12.7).

I propose adding a simple method along the lines of:

func (algo SignatureAlgorithm) Hash() crypto.Hash {                                 
        for _, details := range signatureAlgorithmDetails {                         
                if details.algo == algo {                                           
                        return details.hash                                         
                }                                                                   
        }                                                                           
        return crypto.Hash(0)                                                       
}                                                                                   

[gopherbot]

Change https://golang.org/cl/187778 mentions this issue: crypto/x509: add SignatureAlgorithm.Hash()

[julieqiu]

/cc @FiloSottile

[odeke-em]

Thank you for this request @bodgit and welcome to the Go project!
Thank you @julieqiu for the triage and tag.

While this request and its corresponding CL are simple and straight forward, and it follows pretty much what we did for (SignatureAlgorithm).String() https://golang.org/pkg/crypto/x509/#SignatureAlgorithm.String, I have tagged it as a proposal because it increases the API surface.

[FiloSottile]

What are we supposed to return for Ed25519? What does channel binding end up using with it?

[bodgit]

This is what the RFC says:

if the certificate's signatureAlgorithm uses no hash functions or
uses multiple hash functions, then this channel binding type's
channel bindings are undefined at this time (updates to is channel
binding type may occur to address this issue if it ever arises).

So as you would be returning crypto.Hash(0) for Ed25519 that would seem to be perfectly valid.

[FiloSottile]

IIRC tls-unique was mostly dropped following the SLOTH attacks, and is not even supported in TLS 1.3.

Would this API have any other use case than RFC 5929 channel bindings?

[bodgit]

IIRC tls-unique was mostly dropped following the SLOTH attacks, and is not even supported in TLS 1.3.

I wasn't using tls-unique, only tls-server-end-point that I was required to use, which IIRC is used to guard against MITM attacks.

Would this API have any other use case than RFC 5929 channel bindings?

No idea TBH. As it stands the implementation literally just returns the associated struct member; the logic documented in the RFC for using SHA256 in place of MD5 or SHA1 remains the responsibility of the calling code, it's not part of this PR.

[snqk]

It'd be nice to see this merged.

This would be useful in environments that implement custom TLS verification based on a Hash block list. At the moment we're just using a rudimentary strings.Contains(..., "SHA-1")