proposal: crypto/x509: Add support for OtherName SAN

[kindermoumoute]

Proposal Details

Reopening #55897 with more context.

We use otherName (RFC 5280 4.2.1.6) as an alternative to dNSName since underscores are forbidden from being used in dNSName entries (Ballot SC12: Sunset of Underscores in dNSNames).

Why we use underscores? We use an internal PKI to sign certificates on protobuf namespaces, which allow underscores.

This SAN is generally adopted by PKI tools (e.g. vault API other_sans) and major proxies (e.g. envoy API OTHER_NAME).

we generally treat crypto/x509 as supporting what we need for the web, not for all of X.509

@rsc not sure to understand what is the scope of "web" here. FWIW we use gRPC APIs from web browser.

[gabyhelp]

Related Issues and Documentation

• proposal: crypto/x509: Add support for OtherName SAN #55897 (closed)

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

[ianlancetaylor]

CC @golang/security

[seankhliao]

The current scope of Web PKI is decided by the CA/B (in practice, browsers and the open web).
In CA/B Baseline Requirements Section 7.1.2.7.12 Subscriber Certificate Subject Alternative Name
otherName is not a permitted name type.

[rolandshoemaker]

When we say crypto/x509 targets the "web" this is what we mean (from the crypto/x509 package documentation).

The package targets the X.509 technical profile defined by the IETF (RFC 2459/3280/5280), and as further restricted by the CA/Browser Forum Baseline Requirements. There is minimal support for features outside of these profiles, as the primary goal of the package is to provide compatibility with the publicly trusted TLS certificate ecosystem and its policies and constraints.

Typically this excludes features used by non-public PKIs. In this case OtherName is explicitly not allowed in publicly trusted certificates (as defined by those covered by the CABF profile), so adding support for it is counter to the defined purpose of the package. While I understand there is desire for this, given the additional complexity it is likely to introduce, I am not convinced that the benefits outweigh the downsides.

[kindermoumoute]

IIUC Section 7.1.2.7.12 Subscriber Certificate Subject Alternative Name correctly, rfc822Name (tag 1) and uniformResourceIdentifier (tag 6) are not to be permitted but still they are supported in the Go x509 library. Does it mean they should be removed?

[rolandshoemaker]

Support for rfc822Name and uniformResourceIdentifier are historical artifacts from when this package was initially conceived. Due to the backwards compatibility promise, we are unable to remove support for these features. If we were to be designing this package from scratch today, I would not implement them.

(Slightly annoyingly the CABF profile also does allow, although it is not recommended, inclusion of rfc822Names in name constraints, despite them not being allowed in end-entity subscriber certificates, for complicated historical reasons.)

[kindermoumoute]

Thank you for the insights.

Should I assume that the support of otherName is going to be dropped in the main RFCs in the next 10 years? It seems everyone is not on the same page about this as it got recently supported in envoy.

[rolandshoemaker]

The X.509 RFCs are rarely updated, and it's extremely unlikely they would remove these features, since they are used in various non-web PKI contexts (SMIME, service-to-service authentication, etc).

Other libraries, services, and languages are likely to make different determinations about the value and use of these features than us, since we've taken an extremely conservative view of what the crypto/x509 package should support.

[kindermoumoute]

Thank you @rolandshoemaker and @seankhliao for all the additional information. I'm closing the issue but feel free to reopen it if the crypto/x509 policy change on these matters one day.