Certificate subject X.509

According to the X.509, a certificate has an attribute subject.

C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft,
CN=www.freesoft.org/emailAddress=[email protected]

This is the typical subject value. The question is what are the types(or tags) of those attributes(C, ST, L, O, OU, CN) and what is their format?

IETF PKIX (latest version RFC 5280) is a well accepted profile for certificates. From section 4.1.2.4, the following fields must be supported (I've added between parenthesis is the OpenSSL long and optional short name):

• country (countryName, C),
• organization (organizationName, O),
• organizational unit (organizationalUnitName, OU),
• distinguished name qualifier (dnQualifier),
• state or province name (stateOrProvinceName, ST),
• common name (commonName, CN) and
• serial number (serialNumber).

There's also a list of element that should be supported:

• locality (locality, L),
• title (title),
• surname (surName, SN),
• given name (givenName, GN),
• initials (initials),
• pseudonym (pseudonym) and
• generation qualifier (generationQualifier).

Values should be encoded in UTF8String or PrintableString (some of them only in PrintableString, and some exceptions in IA5String). The standard also has a maximum length for all field types (Appendix A.1)

For reasons of compatibility, implementations must also support domain components (domainComponent, DC) encoded in IA5String. Attention is drawn to email (emailAddress) and its encoding (IA5String, but it's considered deprecated in DNs (it should be in Subject Alternative Name extension).

For those wanting the exact format of these attributes, which is not given in RFC5280:

The capitalized tags are detailed in RFC4519 which is the LDAP schema. This document also links to other RFCs describing the precise syntax and semantics for each specific attribute and datatype.

For example, the country code "C" follows RFC4517 and ISO3166 which gives the actual two-letter codes. And the domain component "DC" is a dns name in accordance with RFC1034.

In addition to the excellent answer referring to RFC 5280, also consult RFC 8399 Internationalization Updates to RFC 5280. RFC 8399 specifies how to handle internationalised domain names and email addresses, in accordance with the updated IDNA 2008. RFC 5280 is aligned with the outdated IDNA 2003, and is not clear about how to handle email addresses where the local part is not limited to ASCII.