Когда кодирование атрибутов соответствует правилам кодирования данных типа «DirectoryString», УЦ, основывающиеся на данном стандарте, обязаны использовать, либо кодировку «PrintableString», либо кодировку «UTF8String», со следующими ограничениями:
Когда владельцем сертификата является УЦ, тогда поле «Subject» обязано иметь точно такую же кодировку, которая используется для поля «Issuer» во всех сертификатах, изданных этим УЦ (владельцем сертификата). Таким образом, если УЦ, владелец сертификата, кодирует атрибуты в полях «Issuer» выпускаемых им сертификатов с помощью TeletexString-, BMPString- или UniversalString-кодировок, то поле «Subject» в выпускаемых им сертификатах должно обязательно иметь точно такую же кодировку.
Когда владельцем сертификата является издатель СОС, тогда поле «Subject» обязано иметь точно такую же кодировку, которая используется для поля «Issuer» во всех СОС, выпускаемых этим владельцем сертификата.
TeletexString-, BMPString- и UniversalString-кодировки, включённые для обеспечения обратной совместимости, не должны использоваться в сертификатах, выпущенных для новых владельцев. Тем не менее, эти типы могут использоваться в сертификатах в тех случаях, когда имя владельца сертификата было сформировано достаточно давно. К этим случаям относятся также и те, когда издавался новый сертификат для существующего владельца или когда сертификат издавался для нового владельца, но при этом атрибуты кодировались так, как они были сформированы ранее в рамках тех сертификатов, которые были изданы для других владельцев. Пользователи сертификатов должны быть готовы для приёма сертификатов с такими типами кодировок.
Существуют устаревшие прикладные системы, в которых адрес электронной почты выполняет роль уникального имени владельца сертификата в форме атрибута «emailAddress» (RFC-2985). Значение атрибута «emailAddress» представляет собой тип кодирования «IA5String», допускающий использование символа «@», но который не входит в алфавит PrintableString-кодировки. Значения атрибута «emailAddress» не «чувствительны» к написанию символов в верхнем или нижнем регистре (например, адрес «[email protected] » эквивалентен адресу «[email protected] »).
Прикладные системы, следующие данному стандарту и формирующие новые сертификаты с адресами электронной почты, с целью установления владельца сертификата обязаны использовать кодирование имени в субполе «subjectAltName» (альтернативное имя владельца) в соответствие с правилами стандарта RFC-822. Совместное использование атрибута «emailAddress» в составе уникального имени владельца сертификата с целью обеспечения функциональной совместимости устаревших прикладных систем «опротестовано», но тем не менее разрешено.