УЦ обязаны кодировать уникальное имя, расположенное в поле «Subject» сертификата УЦ, аналогично кодированию уникального имени, расположенного в поле «Subject» сертификата, выпущенного эти УЦ. Если УЦ используют различные кодировки, то прикладные системы и ИТС могут не распознать имени в последовательности имён МС, в который включён данный сертификат. И как следствие, приемлемые МС могут быть удалены.
Кроме того, ограничения (субполе «nameConstraints» в поле «Расширения» сертификата) для уникальных имён должны быть закодированы, в обязательном порядке, точно так же, как закодированы поле «Subject» и субполе «subjectAltName» в поле «Расширения» сертификата. Если же нет, то субполя «nameConstraints», определяемые как последовательности «excludedSubtrees», не будут совпадать, а недопустимые МС станут приемлемыми, и субполя «nameConstraints», определяемые как последовательности «permittedSubtrees», не будут совпадать, а допустимые МС будут исключены. Чтобы избежать применения неприемлемых маршрутов, целесообразно, чтобы УЦ, там где это возможно, устанавливали ограничения для уникальных имён как последовательности «permittedSubtrees».
В общем, использование субполе «nameConstraints» в поле «Расширения» сертификата для ограничения одного формата наименования (например, DNS-имена) не предполагает ограничение применения других форматов имён (например, адреса электронной почтовой службы).
Несмотря на то, что сертификаты в соответствие с Рекомендацией ITU-T X.509 включают точно выраженные однозначные имена, существует риск того, что не связанные друг с другом УЦ будут издавать сертификаты и/или СОС с одним и тем же именем издателя. В качестве средств снижения остроты проблемы и обеспечения безопасности, связанных с дублированием имён издателей, целесообразно, чтобы имена УЦ и издателя СОС формировались бы таким образом, чтобы снижалась вероятность дублирования имён. Целесообразно, чтобы прикладные системы и ИТС обращали внимание на возможные расширения нескольких не связанных между собой УЦ и издателей СОС, содержащих одно и то же имя. Как минимум, прикладные системы и ИТС, реализующие ПрПП СОС, обязаны гарантировать, что МС сертификата и МС издателя СОС, используемые для подтверждения подлинности сертификата, завершаются в одном и том же ДЗУЦ.