crypto/x509: add ExtKeyUsage.OID

[AGWA]

(updated 2025-09-15)

x509.Certificate currently uses these fields to convey a parsed certificate's Extended Key Usage (EKU) values:

ExtKeyUsage        []ExtKeyUsage           // Sequence of extended key usages
UnknownExtKeyUsage []asn1.ObjectIdentifier // Encountered extended key usages unknown to this package.

There is currently no way to write future-proof code that checks for an unsupported EKU in a certificate. Checking UnknownExtKeyUsage alone is not sufficient because if the EKU becomes supported in the future, it will no longer appear in UnknownExtKeyUsage. And there's no way to check ExtKeyUsage because it's an int, not an OID, and there's no way to know what value the EKU will be assigned in the future.

TesseraCT for example is resorting to parsing the EKU extension itself to avoid this gotcha.

To make it possible for code to check for an OID in both UnknownExtKeyUsage and ExtKeyUsage, we propose adding:

// OID returns the ASN.1 object identifier of the EKU.
func (eku ExtKeyUsage) OID() OID

[gabyhelp]

Related Issues

• crypto/x509: support OIDs for tcg-kp (2.23.133.8) #47620
• crypto/x509: redundant UnknownExtKeyUsage check in verify.go #73289 (closed)
• crypto/tls: create certs w/o KeyEncipherment KU for non-RSA keys in generate_cert.go #36500 (closed)

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

[FiloSottile]

I can think of two other alternative solutions, with no immediate preference among them:

1. Add a pair of []OID fields called ExtendedKeyUsages and ExtraExtendedKeyUsages which work like Extensions/ExtraExtensions: the former has all of them and is populated by parsing, the latter is looked at by marshaling. I am not a fan of the Extensions/ExtraExtensions mechanism, but there's precedent, and this also lets us use the new OID type.
2. Add an (ExtKeyUsage) OID() OID method. Applications would then be able to get the full list of EKUs by iterating over both ExtKeyUsage and UnknownExtKeyUsage.

[AGWA]

I like your option 2 more than my proposal.

Regarding option 1, I think adding more fields would make x509.Certificate harder to understand, which would be nice to avoid if possible. My gut feeling is that EKU OIDs are less likely to have pathologically large components compared to policy OIDs (policies seem to bring out the worst PKI excesses), so there is less of a need to use the new OID type.

[FiloSottile]

Ok, retitled the proposal to add

// OID returns the ASN.1 object identifier of the EKU.
func (eku ExtKeyUsage) OID() OID

By the way, should we also have a OIDFromASN1OID(asn1.ObjectIdentifier) (OID, error)? Otherwise there is no way to get the UnknownExtKeyUsage asn1.ObjectIdentifier values into a uniform list with the ExtKeyUsage OIDs.

/cc @rolandshoemaker

[rolandshoemaker]

By the way, should we also have a OIDFromASN1OID(asn1.ObjectIdentifier) (OID, error)? Otherwise there is no way to get the UnknownExtKeyUsage asn1.ObjectIdentifier values into a uniform list with the ExtKeyUsage OIDs.

Probably, yeah.

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group

[aclements]

@FiloSottile or @rolandshoemaker , could one of you write a self-contained summary of the whole proposal?