x509-cert: Make it easier to work with the contents of a Name

[str4d]

As part of migrating age-plugin-yubikey to yubikey 0.8, I am required to migrate from the x590-parser crate to x509-cert.

The certificates that I generate with age-plugin-yubikey have the subject set to O=age-plugin-yubikey,OU={plugin_version},CN={identity_name}. When parsing the certificates from an arbitrary YubiKey's slots, I filter them on that Organization to determine intention, and then extract the Common Name field to display to the user.

x509_parser::x509::X509Name has several nice methods for extracting information from within a name. Particularly for my use case, these are useful:

• X509Name::iter_organization
• X509Name::iter_common_name

What I currently have manually implemented for my use of x509-cert is:

cert
    .tbs_certificate
    .subject
    .as_ref()
    .iter()
    .flat_map(|n| n.as_ref().iter().find(|a| a.oid == rfc4519::ORGANIZATION))
    .next()

(and similar for rfc4519::COMMON_NAME).

I think I got the OIDs right, but a user who is just trying to use the yubikey crate and is not familiar with X.509 would have a very hard time here.

It would be great to be able to request data out of a Name that the user expects. Better yet, if the user constructed the Name themselves earlier, it would be great to have the ability to precisely match on what they want to be present. Maybe if a Name builder is added for constructing Names (#1489), there could be either cross-documentation, or shared Rust types for attribute types that can be used for both construction and parsing? And maybe there is benefit to gating some kinds of getters on the certificate's Profile?

[baloo]

I would rather make get_organization/get_common_name/ ... instead of an iterator.
CABF (https://cabforum.org/working-groups/server/baseline-requirements/requirements/#7141-name-encoding) says the name should have more than one of each.

That leaves the option to the consumer of the API to implement an iterator if they need, but I think the CABF recommendations would make sense (and it's easier to use).

Any opinion?

[tarcieri]

Per C-GETTER I'd suggest omitting the get_* prefix but that otherwise sounds good to me

[carl-wallace]

Will access to the full set still be available with this as a convenience mechanism? Closely adhering to CABF limits use if not. Multiple OUs is fairly common in some environments and, for some CA products, multi valued RDNs are common. On Sep 4, 2024, at 7:34 PM, Arthur Gautier ***@***.***> wrote: I would rather make get_organization/get_common_name/ ... instead of an iterator. CABF (https://cabforum.org/working-groups/server/baseline-requirements/requirements/#7141-name-encoding) says the name should have more than one of each. That leaves the option to the consumer of the API to implement an iterator if they need, but I think the CABF recommendations would make sense (and it's easier to use). Any opinion? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[baloo]

Yeah, that would be the idea. Just making it easier to do the "right" thing,