HTTPレイヤで追加のサーバ証明書を送信する Secondary Certificate の仕様について

HTTP/2やHTTP/3のレイヤで追加のサーバ証明書を送信可能にする『Secondary Certificate Authentication of HTTP Servers』という仕様がHTTP WGで議論されています。著者はAppleの方とAkamaiの方の共著になっています。

以前にも、共著に入っているMike Bishop氏から2016年~2018年に同様の提案が出ておりましたが改めて提案されています。前回はクライアント側からのクライアント証明書の追加送信サポートしていましたが、今回はサーバからの追加の証明書を送信するユースケースに絞った提案になっています。

モチベーション

HTTPレイヤで追加のサーバ証明書を送信するモチベーションについて説明します。

HTTP/2ではTCPコネクション、HTTP/3ではQUICコネクション上でHTTPリクエストを送信します。極力そのコネクションを使い回すことが出来たほうが、コネクションを確立する手間も少ないですし、輻輳制御上もメリットがあります。

HTTP/2およびHTTP/3において、コネクションを再利用できる条件は次のとおりです

  • リクエストを送るドメインのIPが同一なこと
  • コネクションを確立した際の証明書が、リクエストを送るドメインとマッチしていること

具体的には *.example.com の証明書で接続したコネクション上では、下記のドメインへのリクエストを送信しても良いことになります

このように証明書がカバーするドメインが多ければコネクションを再利用できる機会が増えます。

今回の提案仕様により、追加のサーバ証明書を送ることができれば、コネクションを再利用できる機会を増やすことが出来ます。

Secondary Certificate Authentication of HTTP Servers

CERTIFICATEフレーム

この仕様では、サーバ側からHTTPレイヤで証明書を送信するために CERTIFICATEフレームを新しく定義しています。

HTTP/2およびHTTP/3でCERTIFICATEフレームを定義していますが、例えばHTTP/3では次のようなメッセージです。

Authenticatorフィールドは証明書と紐づく秘密鍵の所持の証明をするデータです。具体的には『RFC 9261 Exported Authenticators in TLS』を介してえられるデータです

通信の流れ

この拡張仕様を使うためには、SETTINGS_HTTP_SERVER_CERT_AUTHパラメータを交換する必要があります。
その後、CERTIFICATEフレームフレームをh2ではstream 0 、h3ではcontrol streamで送信します。

その他

セキュリティ上の考慮事項についても『Secondary Certificate Authentication of HTTP Servers』にかかれておりますので、気になる方はそちらをご覧頂くのが良いと思います。