Целесообразно, чтобы прикладные системы, функционирующие с использованием URI-идентификаторов при обеспечении доступа к HTTP-серверу, указывали тип доставки «application/pkix-cert» (RFC-2585) в поле заголовка «content-type» ответного сообщения на запрос одиночного сертификата, закодированного по DER-правилам. Кроме того, целесообразно, чтобы такие прикладные системы указывали тип доставки «application/pkcs7-mime» (RFC-2797) в поле заголовка «content-type» ответного сообщения при обмене CMS-сообщениями («certs-only»). При использовании FTP-протокола, целесообразно, чтобы имя файла, содержащего одиночный сертификат, закодированный по DER-правилам, включало суффикс «.cer» (RFC-2585), а имя файла, содержащего CMS-сообщение («certs-only»), — «.p7c» (RFC-2797). Касаясь клиентов, то они могут использовать расширение «тип доставки» («media type») или «файл» («file») как указатель на содержание, но, в то же время, не целесообразно, что-бы оно зависело только от наличия корректного расширения «тип доставки» или «файл» в ответе сервера.
Если запись «accessLocation» является наименованием в формате «directoryName», то прикладная система должна получать необходимую информацию из любого СЕК-сервера, который настраивается, исходя из локальных условий. Когда для подтверждения подлинности сертификатов и СОС используется открытый ключ одного УЦ, тогда необходимый сертификат УЦ размещается в атрибуте «crossCertificatePair» и/или «cACertificate», как это определено в стандарте RFC-4523. Когда для подтверждения подлинности сертификатов и СОС используется различные открытые ключи, тогда необходимый сертификат УЦ размещается в атрибуте «userCertificate», как это определено в стандарте RFC-4523. Таким образом, прикладные системы, обрабатывающие формат имени «directoryName», включённого в запись «accessLocation», обязаны находить необходимый сертификат в одном из этих трёх атрибутов. Протокол, используемый прикладной системой (прикладным процессом) для доступа к СЕК-сегменту (например, 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?cA-Certificate;binary,crossCertificatePair;binary>). Пропуск поля «<host>» (например, <ldap://cn=exampleCA,dc=example,dc=com?cACertificate;binary>) может быть эффективным тогда, когда клиент обладает какими-нибудь априорными знаниями для соединения с соответствующим сервером.