[7] PKP の pin-sha256 指令は、 ホストの SPKI Fingerprint を表します。

仕様書

意味

[2] pin-* 指令は、ホスト運用者が当該ホストに束縛されるべき暗号学的identityを示すものです >>1。 ピンを符号化したものです。

[10] ピンPinは、 既知の暗号学的ハッシュアルゴリズムの識別子と、 それを使って計算した SPKI Fingerprint の組み合わせです >>11。

[12] SPKI だけを取り出した時不完全となる場合は、 ピンを作ることはできません >>11。[13] 運用者が古い公開鍵を含む新しい証明書を生成できるように、 証明書全体ではなく公開鍵をピンとして使います。 >>11

構文

[3] 指令の名前は、 pin- に字句を続けたものです >>1。 暗号学的ハッシュアルゴリズムを表すもので、 RFC 6234 SHA256 を表す sha256 (つまり pin-sha256) のみが認められています >>1。

大文字・小文字不区別です。

[4] 指令の値は、引用文字列です >>1。 これは Base64符号化SPKI Fingerprint です。

[15] どうやら字句として表現できる場合でも引用文字列であることが求められているようです。

文脈

[8] PKP ヘッダーで使うことができます。

[14] 本指令と同じものが report-uri へ送信される JSON の known-pins の値としても使われます。

ヘッダーに含めるべきピン

[17] サーバーは、証明書鎖中のいずれかの証明書の SPKI Fingerprint を最低でも含めなければなりません。

[9] なぜか仕様書上はサーバーの要件とはされていませんが、そうでなければクライアントは接続を拒否することになります。

[18] サーバーは末端実体証明書だけでなく、中間発行者や trust anchor の証明書のピンも含められます >>16。

[19] trust anchor の証明書、すなわちルート証明書は TLS では転送しなくても良いことになっていますが、そのピンを含めても問題無さそうです。

[20] サーバーの管理者が秘密鍵を紛失すると、 同じ公開鍵の新しい証明書を発行できなくなりますから、 末端実体証明書のピンのみの PKP だと、 しばらくクライアントが接続できないことになってしまいます。 これを防ぐため、 CA証明書のピンを含めることで、 その CA が発行した証明書なら他の証明書でも接続できる状態となります。 >>16

[21] サーバー管理者が CA を信用していることが前提となります。

[23] 加えて、サーバーはバックアップピンBackup Pinとして証明書鎖のいずれの証明書のものでもないピンを含めなければなりません >>16。 これは秘密鍵紛失等の際にかわりに使うため鍵を予め用意しておくものです >>22。 利用者エージェントは、PKP ヘッダーにバックアップピンが含まれていることを要求しなければなりません >>22, >>24。

処理

[5] 未知のハッシュアルゴリズムの指令は、無視しなければなりません >>1, >>11。

[6] 認識できる pin-* 指令がなく、 当該ホストが Known Pinned Host なら、 そのホストが Known Pinned Host であるとみなすのをやめなければなりません >>1。 利用者にこれを示すべきです >>1。

メモ

[25] 不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記 ( 版) http://d.hatena.ne.jp/jovi0608/20140902/1409635279

ハッシュ方法は仕様上 sha256のみですが、当初より Google は sha1 を使っていたため、Chromeでは sha1 も使えるようです。このハッシュ値をbase64にエンコードしたものをヘッダ値に入れます。