Delegated Credentials for TLS について

BoringSSLが「Delegated Credentials for TLS 」に対応したので、簡単に仕様を眺める。

「Delegated Credentials for TLS 」の仕様は、もともとはTLS1.3の仕様の著者でもあるEric Rescorlaによって書かれていたようだが、すでに WG DraftとなっておりMozilla、Facebook、Cloudflareらの人が共著となっている。

Delegated Credentials for TLS

他社の提供するリバースプロキシやCDNでTLSを終端する際、自身のドメインの証明書と秘密鍵を渡す必要があります。その際に、本来のドメイン所持者から委譲する形でクレデンシャルを発行し、終端者はそのクレデンシャルを持ってしてTLSハンドシェイクを行えるようにしようというのが「Delegated Credentials for TLS 」です。

こうすることで、本来の証明書所持者が委譲するクレデンシャルをより適切な形でコントロールできるようになります。CAとのオペレーションなく、自由な有効期限と自由な署名アルゴリズムでクレデンシャルを発行することが出来ます。

おおまかな流れは以下のとおりです

• 委譲する側が、最初にdelegated credentialを発行し、対応する秘密鍵とともにTLSを終端するサーバに渡します
• TLSハンドシェイク
  • クライアントはこの仕様に対応していることを示すdelegated_credential TLS拡張を送信します。
  • サーバはTLSハンドシェイク中に証明書チェーンとdelegated credentialを送信する
  • クライアントはdelegated credentialを検証し、問題なければ通信を続けます。

delegated credential

delegated credentialは、有効期限と公開鍵をもつ署名されたで＝たです。署名を検証することで証明書が正しく委譲されていることを確認できます。

Credential は以下の情報を含みます。有効期限と公開鍵などです。

      struct {
        uint32 valid_time;
        SignatureScheme expected_cert_verify_algorithm;
        ProtocolVersion expected_version;
        opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
      } Credential;

DelegatedCredentialには、上記のCredentialと署名が含まれます

      struct {
        Credential cred;
        SignatureScheme algorithm;
        opaque signature<0..2^16-1>;
      } DelegatedCredential;

Lurk

以前書いたLurk(Limited Use of Remote Keys)という、秘密鍵を渡さずに第三者にTLS終端をさせる仕様について書きました
asnokaze.hatenablog.com

このLurkとの違いは、ハンドシェイク中に鍵が必要な処理はバックエンドサーバが行っていましたが、Delegated Credentialsでは事前にdelegated credentialを渡せばTLS終端するサーバだけで処理が完結します。