HTTP/2における証明書に基づいたリアクティブなクライアント認証その２

20190311追記
最新仕様である、Secondary Certificate Authentication in HTTP/2の解説記事を書きました
asnokaze.hatenablog.com

この記事は
Secondary Certificate Authentication in HTTP/2 という仕様にマージされました

「HTTP/2における証明書に基づいたリアクティブなクライアント認証その１」(2015-10-23)

「Reactive Certificate-Based Client Authentication in HTTP/2」の draft02が出ています。
HTTP/2 on TLSで一度TLSハンドシェイクが完了した後に追加でクライアント証明書要求し認証する場合の仕様になります。HTTP/1.1ではTLSのリネゴシエーションの手順でクライアント証明書の要求を行っていましたが、HTTP/2ではTLSのリネゴシエーションは禁止されています。

以前、draft 00について紹介しましたが draft 01より大きく変更が入っています。

背景及び解決する問題は変わってはいませんが、draft 00はTLSとHTTP/2両方を拡張するような仕様でしたが、draft01よりHTTP/2レイヤのみで証明書の要求・送信を行う仕様になりました。

クライアント証明書の要求はTLS1.3のCertificateRequest、Certificate、CertificateVerifyメッセージを拡張フレームとして定義するような形になっており、さらに証明書と各ストリームを関連付けるための拡張フレームが定義されている。

通信の流れ

フレーム定義

2.1 CERTIFICATE_REQUIREDフレーム

CERTIFICATE_REQUIREDフレームは、HTTPリクエストが証明書認証のためにブロックされていることを通知するためにサーバから送信されます。このフレームはstream 0で以前に送信されているCERTIFICATE_REQUESTフレームの証明書リクエスト識別子を使用することで関連付けられます。

CERTIFICATE_REQUIREDフレームは証明書リクエスト識別子の1オクテットを含みます。

USE_CERTIFICATEフレーム

USE_CERTIFICATEフレームは要求された証明書を提供したことを示すために、CERTIFICATE_REQUIREDフレームへの返答としてクライアントが送信します。

USE_CERTIFICATEフレームは、Request-IDを含みます。これは、サーバによって発行されたIDであり、CERTIFICATEフレームとマッチする必要があります

2.3 CERTIFICATE_REQUESTフレーム

TLS1.3ではCertificateRequestメッセージを定義しており、これはサーバによって指定されたプロパティに適合する証明書をクライアントが提供できるようにするものです。CERTIFICATE_REQUESTフレームはTLS1.3のCertificateRequestメッセージと同等の内容を含みます。ただしどののバージョンのTLSでも使用できます。

 0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-------------------------------+-------------------------------+
    | Request-ID (8)|     Algorithm-Count (16)      | Algorithms  ...
    +---------------------------------------------------------------+
    |       CA-Count (16)           |  Certificate-Authorities(?) ...
    +---------------------------------------------------------------+
    |   Cert-Extension-Count (16)   |       Cert-Extensions(?)    ...
    +---------------------------------------------------------------+

Request-ID: 8bitの識別子であり、続く証明書関連のフレームと関連付けるのに使用されます。
Algorithms: サーバが検証できるhash, 署名アルゴリズムのリスト。TLS1.3で定義される表記で記述(エンコード)される
Certificate-Authorities: 受容出来る certificate_authorities の DN のリスト。
Cert-Extensions: 許可される値のrtificate extension OIDs のリスト

2.4 CERTIFICATE frame

署名書チェインは同じRequest-IDを持つ一連のCERTIFICATE frameフレームとして送信されます。チェインの最後の証明書がリクエストの認証に使用されます。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-------------------------------+-------------------------------+
    | Request-ID (8)|                Certificate (*)              ...
    +---------------------------------------------------------------+

CERTIFICATE_REQUEST: このフレームが応答しているCERTIFICATE_REQUESTのID
Certificate: X.509v3証明書

2.5 CERTIFICATE_PROOFフレーム

CERTIFICATE_PROOFフレームはCERTIFICATEフレームで提出した証明書に対応する秘密鍵の所持を証明するフレームです

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-------------------------------+-------------------------------+
    | Request-ID (8)|         Algorithm (16)        | Signature(*)...
    +---------------------------------------------------------------+

署名の計算は、TLS1.3で記述されているように計算されますcontext stringには "HTTP/2 CERTIFICATE_PROOF"が使用されます。

CERTIFICATE_PROOFフレームは全てのCERTIFICATEフレームを送信した後に送信したのと同じRequest-IDで送信される必要があります。