メインコンテンツまでスキップ

5. クライアント証明書 URL

この拡張がない場合、TLS は、クライアント認証が実行されるときに、TLS ハンドシェイク中にクライアント証明書がクライアントからサーバーに送信されることを規定しています。制約のあるクライアントの一部のクラスでは、この送信を回避することが望ましい場合があります。

クライアント証明書 URL の送信をネゴシエートするために、クライアントは（拡張された）クライアント hello にタイプ「client_certificate_url」の拡張を含めることができます (MAY)。この拡張の「extension_data」フィールドは空である必要があります (SHALL)。

「client_certificate_url」拡張を含む拡張クライアント hello を受信するサーバーは、（拡張された）サーバー hello にタイプ「client_certificate_url」の拡張を含めることによって、証明書 URL を受け入れる意思があることを示すことができます (MAY)。この拡張の「extension_data」フィールドは空である必要があります (SHALL)。

クライアント証明書 URL の使用のネゴシエーションが正常に完了した後（「client_certificate_url」拡張を含む hello を交換することによって）、クライアントは「Certificate」メッセージの代わりに「CertificateURL」メッセージを送信できます (MAY)：

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;

enum {
    false(0), true(1)
} Boolean;

struct {
    CertChainType type;
    URLAndHash 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;
} URLAndHash;

opaque SHA1Hash[20];

ここで「url_and_hash_list」には、URL とハッシュのシーケンスが含まれています。

X.509 証明書が使用される場合、2 つの可能性があります：

  • CertificateURL.type が「individual_certs」の場合、各 URL は単一の DER エンコードされた X.509v3 証明書を参照し、クライアントの証明書の URL が最初に来ます。

  • CertificateURL.type が「pkipath」の場合、リストには、セクション 10.1 で定義されているタイプ PkiPath を使用した DER エンコードされた証明書チェーンを参照する単一の URL が含まれます。

他の証明書形式が使用される場合、TLS でそのフォーマットの使用を説明する仕様は、証明書または証明書チェーンのエンコーディング形式、およびその順序に関する制約を定義する必要があります。

クライアントの裁量により、各 URL に対応するハッシュは存在しないか、証明書または証明書チェーンの SHA-1 ハッシュです（X.509 証明書の場合、DER エンコードされた証明書または DER エンコードされた PkiPath）。ハッシュの目的は、単一の URL で利用可能な複数の証明書の中からサーバーが選択できるようにすることです。ハッシュが存在する場合、サーバーは、提供されたハッシュが URL にある証明書またはチェーンのハッシュと一致することを確認すべきです (SHOULD)。サーバーが URL で単一の証明書を見つけることを期待しているのに証明書チェーンを受信した場合（またはその逆）、サーバーはタイプ「bad_certificate」の致命的エラーを生成すべきです (SHOULD)。

クライアントはハッシュを送信しないことを選択できますが、サーバーは（拡張された）サーバー hello にタイプ「client_certificate_url」の拡張を送信することによって、ハッシュが存在することを要求できることに注意してください。この場合、「extension_data」フィールドには次のものを含める必要があります (MUST)：

struct {
    Boolean mandatory;
} ClientCertificateURLExtensionData;

ここで「mandatory」は、サーバーがクライアントにハッシュを提供することを要求する場合、true に設定されます。これがネゴシエートされた場合、クライアントは各 URL のハッシュを提供する必要があります (MUST)。そうしない場合、サーバーはタイプ「handshake_failure」の致命的エラーを生成すべきです (SHOULD)。

「CertificateURL」を受信するサーバーは、URL からクライアントの証明書チェーンを取得し、通常どおり証明書チェーンを処理する必要があります (SHALL)。チェーン内の URL の内容のキャッシュされたコピーを使用できます (MAY)。ただし、その URL に SHA-1 ハッシュが存在し、キャッシュされたコピーのハッシュと一致する場合に限ります。

この拡張をサポートするサーバーは、証明書 URL の http: URI スキームをサポートする必要があり (MUST)、https: URI スキームをサポートすべきです (SHOULD)。クライアントは https URL のハッシュを含めるべきですが (SHOULD)、他のメカニズムが取得した証明書が正しいものであることを保証する環境（例：セキュアなイントラネット）では、他の URL のハッシュを省略してもかまいません (MAY)。

サーバーは他の URI スキームもサポートできます。サーバーが特定の URL の URI スキームをサポートしていない場合、またはサーバーが何らかの理由で特定の URL から証明書または証明書チェーンを取得できない場合、サーバーはタイプ「certificate_unobtainable」の致命的エラーを生成すべきです (SHOULD)。

この拡張をサポートするサーバーが、取得できるはずの証明書チェーンを（妥当な時間内に）取得できない場合、サーバーはタイプ「certificate_unobtainable」の致命的エラーを生成すべきです (SHOULD)。

もちろん、TLS ハンドシェイク中に、特定の URL のコンテンツが変更されたり、存在しなくなったりする可能性があります。たとえば、チェーン内の証明書の一部またはすべてが失効した場合、それらの証明書はリポジトリから削除される可能性がありますが、他の証明書は利用可能なままです。競合状態を回避するために、サーバーは、すべての URL が処理されるまで、クライアント認証が受け入れられないと判断してはなりません (MUST NOT)。クライアントは、少なくとも現在の TLS ハンドシェイクの期間中安定していると信じる URL のみを送信する必要があります (MUST)。

「CertificateURL」メッセージは、「Finished」メッセージの計算に含まれることに注意してください。

に最終更新