RFC: 5280
Оригинал: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Предыдущие версии: RFC 2459, RFC 3280, RFC 4325, RFC 4630
Категория: Предложенный стандарт
Дата публикации: (с дополнениями из RFC 6818, Январь 2013)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич

Несмотря на то, что локальная часть адреса электронной почтовой службы зависит от регистра написания символов (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» в поле «Расширения» сертификата, обязаны быть готовыми к возникновению ситуации, которая может привести к бесконечной рекурсии.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.