crypto/x509: certificate with empty Authority Key Identifier extension considered invalid

[dulanshuangqiao]

Go version

go version go1.18.1 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/liu/.cache/go-build"
GOENV="/home/liu/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/liu/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/liu/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.18/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3649475886=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I used crypto/x509 of golang to convert the der certificate to a pem certificate. For my test case, there was an Authority Key Identifier extension with an empty value.

What did you see happen?

Golang considered it an invalid Authority Key Identifier extension, but openssl and gnutls did not.

What did you expect to see?

According to rfc5280, the keyIdentifier, authorityCertIssuer, and authorityCertSerialNumber of the Authority Key Identifier extension are all OPTIONAL

[gabyhelp]

Related Issues

• crypto/x509: ParseCertificate should error on invalid tag for PolicyMappings #70074 (closed)
• repeated extension #70039 (closed)
• crypto/x509: parser should error on Subject Information Access and Policy Constraints being makred as critical #70278
• crypto/x509: wrong value of RevocationList.AuthorityKeyId #67571 (closed)
• crypto does not recognize the extension "authority key identifier" #43868 (closed)
• crypto/x509: AuthorityKeyId on self-signed certificates #15194 (closed)
• crypto/x509: the ParseRevocationList() doesn't seem to populate the AuthorityKeyId correctly #57461 (closed)

Related Code Changes

• crypto/x509: don't fail on optional auth key id fields

Related Discussions

• x509 marshaling extra-extensions

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

please show a reproducer. also 1.18 is not a supported version.
Note that the RFC says:

The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction. There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted.

and it should be allowed from #15194

[dulanshuangqiao]

请提供重现程序。另外 1.18 不是受支持的版本。 请注意，RFC 指出：

authorityKeyIdentifier 扩展的 keyIdentifier 字段必须
包含在符合要求的 CA 生成的所有证书中，以
方便构建证书路径。有一个例外；
当 CA 以“自签名”证书的形式分发其公钥时
，可以省略授权密钥标识符。

从#15194开始应该允许

I implemented this problem again in go version go1.23.2 linux/amd64
My report is that the extension appears but the value is empty, not the omitted Authority Key Identifier extension mentioned in rfc5280. Since the keyIdentifier, authorityCertIssuer and authorityCertSerialNumber of the Authority Key Identifier extension are all optional, openssl and gnutls do not consider this case as an invalid Authority Key Identifier extension, but golang's crypto/x509 judges it as invalid
I attached the test case and the golang program I used (the program corresponds to the certificate format conversion command of openssl)
appendix.zip

[seankhliao]

cc @golang/security

[dulanshuangqiao]

cc @golang/security

There is no staff to handle this report for a long time.I hope a developer can review my report，This is very important for my work.

[rolandshoemaker]

Just because these fields are OPTIONAL (in the ASN.1 terminology) does not mean they can generally be empty. RFC 5280 specifically says that the keyIdentifier must be present (except for in the self-signed case) and the CABF Baseline Requirements also says it must be present. I'm confused as to what the extension being present, but the value being empty, would mean. How would that aid in path building?

We specifically target the web PKI, for which AKI is generally necessary for happy path building. While OpenSSL and GnuTLS support many things, which exponentially increase their complexity, we do not, and without a strong rationale for adding support for this, I cannot imagine we would be particularly interested in doing it.