URLs сертификата клиента
TLS требует, чтобы при выполнении аутентификации клиента сертификаты клиента посылались серверу в течение Рукопожатия. Для клиентов, имеющих различные ограничения, может потребоваться посылать URLs сертификата вместо самих сертификатов, чтобы они могли не хранить свои сертификаты и тем самым не занимать память.
Для ведения переговоров о посылке серверу URLs сертификата клиенты могут включать расширение типа client_certificate_url в Client Hello. Поле extension_data данного расширения должно быть пустым.
Заметим, что необходимо вести переговоры об использовании URLs сертификатов клиента, чтобы существующие серверы TLS 1.0 могли функционировать.
Сервер, получивший расширенный Client Hello, содержащий расширение client_certificate_url, может указать, что имеет возможность принимать URLs сертификата, указывая расширение типа client_certificate_url в Server Hello. Поле extension_data данного расширения должно быть пустым.
После успешного завершения переговоров об использовании URLs сертификата клиента клиент может посылать сообщение CertificateURL вместо сообщения Certificate:
enum { individual_certs(0), pkipath(1), (255) } CertChainType; enum { false(0), true(1) } Boolean; struct { CertChainType type; URLAndOptionalHash url_and_hash_list<1..2^16-1>; } CertificateURL; struct { opaque url<1..2^16-1>; Boolean hash_present; select (hash_present) { case false: struct {}; case true: SHA1Hash; } hash; } URLAndOptionalHash; opaque SHA1Hash[20];
Здесь url_and_hash_list содержит последовательность URLs и хэши (необязательно).
При использовании сертификатов Х.509 существует две возможности:
- Если Certificate.type есть individual_certs, то каждый URL ссылается на единственный сертификат Х.509v3 в DER-представлении; при этом первым указывается сертификат клиента.
- Если Certificate.type есть PkiPath, то список содержит единственный URL, ссылающийся на цепочку сертификатов в представлении DER, при этом используется тип PkiPath, описанный ниже.
При использовании любого другого формата спецификация, описывающая применение этого формата, должна определять формат представления сертификатов или цепочки сертификатов и различные ограничения их последовательности.
Хэш, соответствующий каждому URL, либо не присутствует, либо является SHA-1 хэшем сертификата или цепочки сертификатов (в случае сертификатов Х.509 DER-представлением сертификата или DER-представлением PkiPath).
Заметим, что когда используется список URLs для сертификатов Х.509, упорядоченность URLs является той же самой, что и в сообщении Certificate, в противоположность упорядоченности, в которой сертификаты представлены в PkiPath. В любом случае самоподписанный корневой сертификат в цепочке может быть опущен, в предположении, что сервер уже проверил его действительность.
При получении CertificateURL сервер должен пытаться получить цепочку сертификатов клиента из URLs и затем обработать ее обычным образом. Может использоваться кэшированная копия содержимого любого URL из цепочки, проверяя, что SHA-1 хэш присутствует и соответствует хэшу кэшированной копии.
Серверы, которые поддерживают данное расширение, должны поддерживать http:URL схему для URLs сертификатов и могут поддерживать другие схемы.
Если протокол, используемый для получения сертификатов или цепочки сертификатов, возвращает MIME форматированный ответ (как делает НТТР), то должен применяться следующий MIME Content-Type: при возврате единственного сертификата Х.509v3 Content-Type есть application/pkix-cert, при возврате цепочки сертификатов Х.509v3 Content-Type есть application/pkix-pkipath.
Если для URL присутствует SHA-1 хэш, то сервер должен убедиться, что SHA-1 хэш содержимого объекта, полученного из URL (после декодирования произвольного MIME Content-Transfer-Encoding), соответствует данному хэшу. Если полученный объект не имеет корректного SHA-1 хэша, сервер должен прервать Рукопожатие с Alert bad_certificate_hash_value.
Заметим, что клиент может выбрать либо посылку Certificate, либо посылку CertificateURL после успешных переговоров о посылке URLs сертификатов. Опция посылки сертификата обеспечивает клиенту гибкость при обработке нескольких сертификатов.
Если сервер столкнулся с непредвиденной задержкой при получении сертификатов по указанному CertificateURL, он должен при истечении таймаута создать Alert ошибки certificate_unobtainable.