Когда доступ к информации обеспечивается с помощью 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, crossCertificatePair;binary>). Пропуск поля «<host>» (например, <ldap://cn=exampleCA,dc=example,dc=com?cACertificate;binary>) может быть эффективным тогда, когда клиент обладает какими-нибудь априорными знаниями для соединения с соответствующим сервером.
Когда доступ к информации обеспечивается с помощью HTTP- или FTP-протокола, тогда субпоследовательность «accessLocation» должна быть, в обязательном порядке, URI-идентификатором («uniformResourceIdentifier»). В этом случае, сам URI-идентификатор должен быть, в обязательном порядке, указателем, либо на одиночный сертификат, закодированный по DER-правилам (RFC-2585), либо на совокупность сертификатов, расположенных в CMS-сообщении («certs-only») и закодированных по BER- или DER-правилам (RFC-2797).
Прикладные системы, придерживающиеся данного стандарта и использующие HTTP- или FTP-протокол для обеспечения доступа к сертификатам, обязаны предоставлять доступ к индивидуальным сертификатам, закодированным по DER-правилам, а также целесообразно, чтобы такие прикладные системы обеспечивали обмен CMS-сообщениями («certs-only»).
Целесообразно, чтобы прикладные системы, функционирующие с использованием 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») как указатель на содержание, но, в то же время, не целесообразно, что-бы оно зависело только от наличия корректного расширения «тип доставки» или «файл» в ответе сервера.