Popular x509 libraries, such as openssl, produce human-readable subject strings in an RFC2253 format. When they do, they may use the attribute type name "GN". For example:
openssl req -new -key "test.key" -out "test.csr" -subj "/2.5.4.4=my_sn/2.5.4.42=my_name"
openssl req -in test.csr -subject -noout -nameopt RFC2253
> subject=GN=my_name,SN=my_sn
x509_cert::name::Name::from_str() fails to parse this representation:
use x509_cert::name::Name;
use std::str::FromStr;
fn main() {
println!("{:?}", Name::from_str("GN=my_name,SN=my_sn"));
// Err(Error { kind: OidMalformed, position: None })
}
It does recognize givenName, though I haven't found yet a library that renders givenName as part of a human-readable distinguished name.
println!("{:?}", Name::from_str("givenName=my_name,SN=my_sn"));
//Ok(RdnSequence([RelativeDistinguishedName(SetOfVec { inner: [AttributeTypeAndValue { oid: ObjectIdentifier(2.5.4.4), value: Any { tag: Tag(0x0c: UTF8String), value: BytesOwned { length: Length(5), inner: [109, 121, 95, 115, 110] } } }] }), RelativeDistinguishedName(SetOfVec { inner: [AttributeTypeAndValue { oid: ObjectIdentifier(2.5.4.42), value: Any { tag: Tag(0x0c: UTF8String), value: BytesOwned { length: Length(7), inner: [109, 121, 95, 110, 97, 109, 101] } } }] })]))
This is frustrating, as for my use case, AWS's implementation of mutual TLS verification forwards subject names in RFC 2253 format, i.e., they render OID 2.5.4.42 as GN. [https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html#mtls-http-headers]
It looks like the root cause of the failure to parse is
- ldap-parameters-3.csv has an entry of "GN RESERVED" [https://github.com/RustCrypto/formats/blob/babd62954d0d751b3b2813af4efd9699f9ffb882/const-oid/oiddbgen/ldap-parameters-3.csv#L204]. This matches the table in RFC 4519, and RFC 4519 notes "gn" as being "added for consideration"
- "RESERVED" is not a valid OID, and thus it's not added to the generated DB [https://github.com/RustCrypto/formats/blob/babd62954d0d751b3b2813af4efd9699f9ffb882/const-oid/oiddbgen/src/ldap.rs#L15]
- When parsing, "GN" isn't in the OID database, nor is it a dot-delimited decimal identifier. [https://github.com/RustCrypto/formats/blob/master/x509-cert/src/attr.rs#L235]
I'd like to advocate for supporting "GN" - while RFC 4514 only requires a very small table be supported (CN, L, ST, O, OU, C, STREET, DC, UID), it allows for supporting other name strings. And indeed, x509_cert::name::Name supports every other name mentioned in 4519.
Popular x509 libraries, such as openssl, produce human-readable subject strings in an RFC2253 format. When they do, they may use the attribute type name "GN". For example:
x509_cert::name::Name::from_str()fails to parse this representation:It does recognize
givenName, though I haven't found yet a library that rendersgivenNameas part of a human-readable distinguished name.This is frustrating, as for my use case, AWS's implementation of mutual TLS verification forwards subject names in RFC 2253 format, i.e., they render OID 2.5.4.42 as
GN. [https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html#mtls-http-headers]It looks like the root cause of the failure to parse is
I'd like to advocate for supporting "GN" - while RFC 4514 only requires a very small table be supported (CN, L, ST, O, OU, C, STREET, DC, UID), it allows for supporting other name strings. And indeed, x509_cert::name::Name supports every other name mentioned in 4519.