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 calling x509.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 the Certificate struct that's only written to when parsing.
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
ExtraExtensionsbefore 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 theCertificatestruct that's only written to when parsing.