Несмотря на то, что локальная часть адреса электронной почтовой службы зависит от регистра написания символов (RFC-2821), значения атрибута «emailAddress» не зависят от такого регистра (RFC-2985). В этой связи, существует риск того, что два различных почтовых адреса будут считаться как один и тот же адрес, когда используется правило сравнения, предназначенное для атрибута «emailAddress», если почтовый сервер учитывает в процедуре сравнения локальных частей адресов почтового ящика регистр написания символов. Целесообразно, чтобы прикладные системы и ИТС не включали почтовые адреса в атрибут «emailAddress», если почтовый сервер, который обрабатывает почтовый адрес, рассматривает локальную часть почтовых адресов, как зависимую от регистра написания символов.
Целесообразно, чтобы прикладные системы и ИТС были осведомлены относительно рисков, возникающих с том случае, когда субполя «cRLDistributionPoints» и «authorityInfoAccess» поля «Расширения» фальсифицированных сертификатов или последовательности «authorityInformationAccess» и «issuingDistributionPoint» субполя «crlExtensions» фальсифицированных СОС содержат указатели на вредоносный код. Целесообразно, чтобы прикладные системы и ИТС всегда предпринимали шаги по проверке подлинности полученных данных с целью обеспечения подтверждения того, что данные сформированы должным образом.
Когда сертификаты включают субполе «cRLDistributionPoints», содержащее URI-идентификатор HTTPS-схемы адресации или аналогичной схемы, тогда может возникнуть циклическая взаимозависимость («зацикливание»). Взаимодействующая сторона будет вынуждена проводить дополнительную ПрПП МС с целью получения необходимого СОС для завершения первичной ПрПП МС! Условия цикличности могут также возникнуть, если и субполя «authorityInfoAccess» и «subjectInfoAccess» в поле «Расширения» сертификата содержат URI-идентификатор HTTPS-схемы адресации или аналогичной схемы. В худшем случае, такая ситуация может спровоцировать неразрешимую взаимосвязь (т.е. «нельзя будет разорвать порочный круг»).
Целесообразно, чтобы УЦ не включали URI-идентификаторы в расширения сертификатов и СОС, если такие идентификаторы указывают на LDAPS- и HTTPS-схемы адресации или аналогичные схемы. УЦ, которые включают URI-идентификаторы HTTPS-схемы адресации в указанные выше расширения, обязаны гарантировать, что сертификат сервера может провести ПрПП без использования информации, на которую указывает URI-идентификатор. Взаимодействующие стороны, реализующие ПрПП сертификата сервера, когда они получают информацию с помощью URI-идентификатора HTTPS-схемы адресации, содержащегося в субполях «cRLDistributionPoints», «authorityInfoAccess» и «subjectInfoAccess» в поле «Расширения» сертификата, обязаны быть готовыми к возникновению ситуации, которая может привести к бесконечной рекурсии.