ピン

pin-sha256 指令 (HTTP)

[7] PKPpin-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 へ送信される JSONknown-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にエンコードしたものをヘッダ値に入れます。