PP pki data

署名は、それを検証する公開鍵がなければ無価値であり、BIP70はその鍵を単独ではなく証明書の中に含めて送信していました。このフィールドには、生のDER証明書のリストを包む小さなprotobufのラッパーが入っており、証明書は加盟店から外側へ向かう順に並んでいました。その中身が、ウォレットに企業名を表示するか、警告のみを表示するかを決めていました。

仕組み

状態: 歴史的。PP pki dataは、PaymentRequestメッセージの5つのフィールドのうち3番目のフィールドであり、Bitcoin Coreはそれを読み取るコードをバージョン0.20.0で削除しました。このバージョンは2020年6月3日にリリースされています。

バイト列の中には、X509Certificatesという名前のprotobufメッセージがあり、繰り返しフィールドをちょうど1つ持ち、各エントリはバイナリ形式の完全な証明書でした。順序は好みに委ねられず規定されており、加盟店自身の証明書が最初に来て、その後に公開ルートへ到達するために必要な中間証明書が続きました。

ルート証明書自体は意図的に含まれていませんでした。この理由はBIP70の範囲をはるかに超えて一般化できます。検証しようとしている相手から受け取ったルート証明書は何も証明しません。誰でもルート証明書を生成し、それで任意のものに署名できるからです。信頼は、お使いのデバイスがすでに保持しているリストから届かなければなりません。

使用されているエンコーディングであるDERは、ASN.1の正規のバイナリ形式です。つまり、1つの構造に対して有効なバイト列はちょうど1つです。BEGIN CERTIFICATE行を伴うおなじみのPEM形式は、同じバイト列をbase64で表したもので、約3割多くの容量を要するため、通信上の形式は常に生の形式です。

証明書がリクエストのサイズの大部分を占めていました。アウトプット、タイムスタンプ、メモを合わせても数百バイト程度であるのに対し、RSA-2048の証明書1つだけでも、名前や拡張を数える前の時点で256バイトのモジュラスと256バイトの署名を抱えており、それが2つ連なると数千バイトに達します。pki typeが"none"の場合、このフィールドは単に空であり、ウォレットには宛先以外に表示するものがありませんでした。

どこで見られるか

同じ証明書リストが、同じリーフ先頭の順序で、HTTPS接続のたびに届きます。

TLSサーバーは自身の証明書を最初に送り、その後に中間証明書を送り、上述の理由からルート証明書を省略します。どのサイトが送信する正確なリストも、1つのコマンドopenssl s_client -showcerts -connect example.com:443で読み取ることができ、出力されるのはBIP70が運んでいたものと同一の内容を、バイナリではなくPEMで示したものです。

ビットコインを購入する人にとっての教訓は、それらのバイト列が語らないことにあります。有効な証明書チェーンは、発行の時点で何らかの機関がドメイン名の管理を確認したことを証明します。しかし、企業の所有者が誰か、そのページが取引所のクローンかどうか、その取引所が出金に応じられるかどうかについては何も語りません。フィッシングサイトは完全に有効な証明書を、無料で数秒で取得しており、それが生み出す鍵アイコンは本物と区別がつきません。

したがって、鍵ではなくドメインを読んでください。検索広告経由ではなく、一度作成したブックマークから取引所へアクセスし、資金を預けるサイトでの証明書警告は、促しではなく完全な停止と受け止めてください。

PP pki data vs証明書チェーン

PP pki dataは容器であり、証明書チェーンはその中に入るものでした。pki dataという呼称が意味を持つのは、BIP70のドキュメントやアーカイブされたウォレットのソースコードを読むときだけです。他の何もこの用語を使ったことがないからです。これに対し、チェーンは日常的に依存している生きたものであり、BIP70が書き記した順序の規則、すなわちリーフを先頭にしてルートを省略するという規則は、TLSが今も従っている規則です。