New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: crypto/x509: Add support for OtherName SAN #55897
Comments
I've found a workaround, removing the SAN OID from For justification for adding support, there is an example of OtherName being used for smart card certificates. |
cc @golang/security |
This proposal has been added to the active column of the proposals project |
Talked to @rolandshoemaker. OtherName isn't allowed for web PKI (nor are the other name types), and we generally treat crypto/x509 as supporting what we need for the web, not for all of X.509. What is the reason we should add OtherName? And what constraints should it imply? |
OtherName is primarily used for smart card certificates, though I've found it useful for encoding non-email subjects for code-signing certificates. Agreed that it's not used within web PKI though, so if it's that bar, then I assume it'll need to remain outside the standard library. |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
Context: I want to create a code-signing certificate whose SAN is set to an OtherName. I'm also happy to propose adding support for all GeneralName fields, although I recognize some are more esoteric.
It is currently possible to construct a certificate with a GeneralName that is not a DNS/email/IP address/URI by constructing the SAN extension and including it in
ExtraExtensions
before callingx509.CertificateCertificate
. This is doable, but not ideal, as it requires some knowledge of ASN.1 encoding.However, it is possible to construct a certificate that is not verifiable after parsing, if the SAN extension is set to critical and a GeneralName is set that is not a DNS/email/IP address/URI. When parsing the SAN, if no supported GeneralName is found, then the verifier will fail due to an unhandled critical extension.
RFC5280 states that "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." If I want to issue a certificate with an unsupported GeneralName, then I must mark the SAN extension as non-critical and not conform to RFC5280.
I propose adding support for OtherName, and if desired, for all GeneralName fields. I would prefer that we add support for both creating and parsing certificates with OtherName. If it's preferred to not support creating certificates with OtherName (since you could still by adding the SAN to
ExtraExtensions
), I would propose to add support for parsing only then, adding a field to theCertificate
struct that's only written to when parsing.The text was updated successfully, but these errors were encountered: