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-4210, которые позволяют УЦ защитить свой новый открытый ключ, используя свой предшествующий закрытый ключ, и наоборот, используя два само-изданных сертификата. Прикладные системы и ИТС, обслуживающие клиентов и придерживающиеся данного стандарта, будут обрабатывать само-изданные сертификаты и устанавливать, могут ли быть доверенными (надёжными) сертификаты, которые были изданы с использованием нового ключа. Само-изданные сертификаты могут применяться для указания и других изменений в функциональных характеристиках УЦ, например, дополнения к совокупности политик УЦ, с использованием аналогичных процедур.

Некоторые «старые» прикладные системы и ИТС обрабатывают имена, которые закодированы с помощью набора символов, установленного стандартом ISO 8859-1 («Latin1String», латинский алфавит), но помечают эти имена, как если бы они имели TeletexString-кодировку. Алфавит TeletexString-кодировки имеет большее число символов по сравнению с алфавитом, установленным стандартом ISO 8859-1. Более того, в алфавите TeletexString-кодировки некоторые символы кодируются по другому, по сравнению со стандартом ISO 8859-1. Правила сравнения имён, представленные в 7.1, предусматривают, что алфавит TeletexString-кодировки соответствует правилам кодирования ASN.1-стандарта. При сравнении имён, закодированных с помощью Latin1String-алфавита, возможны ошибочные, и положительные, и отрицательные решения.

Если последовательности символов отображаются из внутреннего кода в код визуального отображения, то иногда две различные последовательности могут иметь одинаковое или подобное визуальное отображение. Такое может произойти по многим причинам, включая представление символа с помощью побитового способа отображения (например, «e + '», эквивалентное U+00E9-символу (0000 0000 1110 1001), Корейские составные символы и гласные над группами согласных в некоторых языках). В результате возникновения такой ситуации пользователи, осуществляющие визуальное сравнение двух различных наименований могут подумать, что они одинаковые, а самом деле — нет. Кроме того, пользователи могут ошибаться принимая одну последовательность символов за другую. Издатели сертификатов и взаимодействующие стороны должны быть осведомлены о такой проблеме.

Однонаправленные хэш-функции, как правило, используются при формировании значение идентификаторов ключей (Authority Key Identifier и Subject Key Identifier), например, как определено в 4.1.1 и 4.1.2. Тем не менее, в данном стандарте не требуется указывать ни одно из свойств таких функций.

Страница 95 из 108

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