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)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич

Если идентификатор «id-ad-caIssuers» представлен как способ доступа (субпоследовательность «accessMethod»), то субпоследовательность «accessLocation» указывает на сервер, в котором храниться описание со справочными данными, и протокол доступа с целью получения этого описания. Субпоследовательность «accessLocation» представляет собой обобщённое наименование («GeneralName»), которое может иметь несколько форматов.

Если субпоследовательность «accessLocation» является наименованием в формате «directoryName», то прикладная система должна получать необходимую информацию из любого СЕК-сервера, который настраивается исходя из локальных условий. Запись в формате «directoryName» содержит сертификаты УЦ в атрибутах «crossCertificatePair» и/или «cACertificate», как это определено в стандарте RFC-4523. Протокол, используемый прикладной системой (прикладным процессом) для доступа к СЕК-сегменту (например, DAP- или LDAP-протокол), выбирается исходя из локальных условий.

Когда доступ к информации обеспечивается с помощью LDAP-протокола, тогда целесообразно, чтобы субпоследовательность «accessLocation» представляла собой URI-идентификатор («uniformResourceIdentifier»). URI-идентификатор LDAP-сервера (RFC-4516) должен, в обязательном порядке, включать поле «<dn>», содержащее уникальное имя владельца сертификатов, он должен, в обязательном порядке, включать субпоследовательность «<attributes>», содержащая список описаний атрибутов, которые содержат сертификаты или пары кросс-сертификатов в DER-коде (RFC-4523), и целесообразно, чтобы он включал поле «<host>» (например, <ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary>). Пропуск поля «<host>» (например, <ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary>) может быть эффективным тогда, когда клиент обладает какими-нибудь априорными знаниями для соединения с соответствующим сервером.

Когда доступ к информации обеспечивается с помощью HTTP- или FTP-протокола, тогда субпоследовательность «accessLocation» должна быть, в обязательном порядке, URI-идентификатором («uniformResourceIdentifier»). В этом случае, сам URI-идентификатор должен быть, в обязательном порядке, указателем на одиночный сертификат, закодированный по DER-правилам (RFC-2585), или на совокупность сертификатов, расположенных в CMS-сообщении (Cryptographic Message Syntax, «certs-only») и закодированных по BER- или DER-правилам (RFC-2797).

Прикладные системы, придерживающиеся данного стандарта и использующие HTTP- или FTP-протокол для обеспечения доступа к сертификатам, обязаны предоставлять доступ к индивидуальным сертификатам, закодированным по DER-правилам, а также целесообразно, чтобы такие прикладные системы обеспечивали обмен CMS-сообщениями («certs-only»).

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