Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
obsoleted by
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
updates
- rfc-3280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (15)
PrintableString is retained as a preferred encoding (alongside UTF8String) specifically to preserve support for the large installed base of deployed certificates. UTF8String is preferred for international character set support.
The December 31, 2003 deadline for exclusive use of UTF8String was removed because implementation and deployment experience showed that many existing certificates use PrintableString, and forcing UTF8String-only would break interoperability with the vast bulk of already-deployed certificates.
For the directoryName form in subjectAltName, the encoding preference follows Section 4.1.2.4 (i.e., prefer PrintableString or UTF8String), aligning subjectAltName handling with the issuer/subject field rules.
Many legacy implementations encode names in ISO 8859-1 (Latin1String) but tag them as TeletexString. Since TeletexString encodes a larger character set and some characters differently, implementations SHOULD be prepared to handle both encodings.
Name comparison in X.509 assumes that attribute values encoded in different string types (e.g., PrintableString vs. UTF8String) represent different strings, making mixed encoding across a certification path a source of comparison failures.
TeletexString and UniversalString are included for backward compatibility and SHOULD NOT be used for new subjects, but MAY be used where the name was previously established. Certificate users SHOULD be prepared to receive certificates with these types.
A CA MAY issue more than one certificate with the same DN to the same subject entity when the subjectAltName extension contains a directoryName.
CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString in subject fields, with the same backward-compatibility exception as for issuer fields.
Name components that appear in both the subject field and the issuer field SHOULD use the same encoding throughout the certification path, since name comparison treats values encoded in different types as different strings.
When CAs have previously issued certificates with issuer field attributes encoded using TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings to preserve backward compatibility.
When CAs have previously issued certificates with subject fields encoded using TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings in new certificates for the same subject to preserve backward compatibility.
When the subjectAltName extension contains a DN in directoryName, the DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field.
The DirectoryString type is defined as a CHOICE of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. UTF8String and PrintableString are the preferred encodings; TeletexString, BMPString, and UniversalString are retained for backward compatibility only.
Consistent encoding for name components is required to ensure that name constraints specified in RFC 3280 work as expected; inconsistent encoding can cause name constraints to be incorrectly evaluated.
Different strings can have the same or visually similar representations due to similar glyphs, composed characters (e.g., e + combining acute = U+00E9), or language-specific composition rules. Issuers and relying parties must be aware that visual comparison of certificate names may mislead, enabling name confusion or substitution attacks.