x/crypto/cryptobyte: cannot read all boolean true values

[hoeg]

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

$ go version
go version go1.17.5 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
GOHOSTARCH="amd64"
GOHOSTOS="darwin"

What did you do?

While parsing X.509 certificates we encountered an issue regarding basic constraints that failed to parse. Looking further into this it comes down to how ASN.1 boolean values are read. See https://go.dev/play/p/AOb8AkyOqR8 for an example.

Basically we expect all non zero octets in an ASN.1 boolean to result in a true value whereas the cryptostring.ReadASN1Boolean function seems to only read a true value if the octet is 0xFF. The current behaviour of cryptostring.ReadASN1Boolean is not aligned with the X.690 standard section 8.2.2 specifying the encoding of ASN.1 boolean values. I have looked into how OpenSSL and BouncyCastle handles this value and they seem to follow the X.690 standard with respect to this behaviour.

What did you expect to see?

Expected the cryptostring.ReadASN1Boolean to return true with a true value in the output parameter.

What did you see instead?

cryptostring.ReadASN1Boolean returned false.

[dmitshur]

Thanks for the report.

CC @FiloSottile, @katiehockman, @rolandshoemaker.

[FiloSottile]

x/crypto/cryptobyte targets ASN.1 DER, which requires values to be canonically encoded. See Section 11.1 of X.690.

[FiloSottile]

/cc @golang/security (@dmitshur, we are moving towards using the security group handle for issue cc's.)

[dmitshur]

@FiloSottile Sounds good. Please feel free to update the x/crypto entry (and/or nested ones) in https://dev.golang.org/owners accordingly, so other people who CC package owners will know as well.