crypto/x509 does not apply IPv4 constraints to IPv4-mapped IPv6 addresses, nor does it apply IPv4-mapped IPv6 constraints to IPv4 addresses.
We consider this to be the correct behavior. The specifications make it clear that IPv4 constraints apply to IPv4 iPAddress SANs, and IPv6 constraints apply to IPv6 iPAddress SANs. IPv4-mapped addresses, may be interpreted as IPv4 addresses, but are, technically, IPv6 addresses.
Above all else, fundamentally the IPv4-mapped IPv6 address space is intended to exist solely as a kernel networking layer helper for systems with IPv6 stacks, and they should never appear in certificates. CAs which are allowing these addresses in certificates are already doing things extremely wrong.
Our behaviors matches at least BoringSSL in this regard.
We should probably just refuse to parse certificates with these addresses in the first place (and prevent them from being created).
I'm opening (and immediately closing) this issue, because we have gotten multiple security reports about this, and there is no canonical public documentation about this.
crypto/x509 does not apply IPv4 constraints to IPv4-mapped IPv6 addresses, nor does it apply IPv4-mapped IPv6 constraints to IPv4 addresses.
We consider this to be the correct behavior. The specifications make it clear that IPv4 constraints apply to IPv4 iPAddress SANs, and IPv6 constraints apply to IPv6 iPAddress SANs. IPv4-mapped addresses, may be interpreted as IPv4 addresses, but are, technically, IPv6 addresses.
Above all else, fundamentally the IPv4-mapped IPv6 address space is intended to exist solely as a kernel networking layer helper for systems with IPv6 stacks, and they should never appear in certificates. CAs which are allowing these addresses in certificates are already doing things extremely wrong.
Our behaviors matches at least BoringSSL in this regard.
We should probably just refuse to parse certificates with these addresses in the first place (and prevent them from being created).
I'm opening (and immediately closing) this issue, because we have gotten multiple security reports about this, and there is no canonical public documentation about this.