暗号技術において、公開鍵基盤（こうかいかぎきばん、、以下PKI）IPA013は公開鍵暗号方式や電子署名方式で用いる公開鍵とその公開鍵の持ち主の対応関係を保証するための仕組みである。公開鍵認証基盤公開鍵認証基盤（PKI）の仕組み (pdf)、地方公共団体情報システム機構公的個人認証サービス。2016年8月4日閲覧用語集「公開鍵認証基盤」、一般財団法人日本情報経済社会推進協会(JIPDEC) 2016年8月4日閲覧公開鍵認証基盤（PKI）の仕組み(pdf)、厚生労働省 2016年8月4日閲覧、公開鍵暗号基盤電子署名について、JIPDEC（一般財団法人日本情報経済社会推進協会）電子署名・認証センター 2016年8月4日閲覧とも呼ばれる。
PKIの実現例として、たとえばX.509（PKIX: Public-Key Infrastructure using X.509）がある。
概要 インターネットのような電子的な通信路を介して通信を行う際、通信の安全性を確保するための技術として、公開鍵暗号方式や電子署名方式がある。これらの技術では通信相手の公開鍵を用いることで送信する文書を暗号化したり、文章に対する署名を検証したりすることで、文章の秘匿性や真正性を保証する。
これらの技術を使う際には、暗号化や署名検証で用いた公開鍵が通信相手のものであることを事前に確認する必要がある。なぜなら、もしこの確認がなされていないと、たとえば、不正者が通信相手の公開鍵を偽の公開鍵とすりかえるなりすましなどの攻撃が可能になってしまうからである。
しかし、公開鍵とその持ち主との対応関係を確実に保証するのは容易ではない。インターネットは基本的に匿名の通信路であるので、公開鍵の所有者と名乗っている人物が本当に所有者当人であるのかを知るのは容易ではないからである。
PKIは、公開鍵とその持ち主の対応関係を認証局（CA、Certification Authority）という第三者機関を用いて保証するための技術である。
各認証局Aは自身の公開鍵を公開しており、この公開鍵とそれに対応する秘密鍵を用いることで、PKIの利用者や団体、他の認証局などの公開鍵とその所有者名Bの組（とその他必要情報を合わせたもの）に対する署名文を作成する。この署名文を、公開鍵の所有者がBであることを保証する公開鍵証明書（public key certificate）という。
PKIの各利用者Cは、自身が最も信頼できると思われる認証局Zの公開鍵を事前に何らかの方法で入手しておく（方法は後述する）。この認証局Zの公開鍵は、PKIにおける全ての信頼関係の起点となるので、認証局ZをCのトラストアンカー（Trust Anchor、信用点とも）というIPA51。2016年8月3日閲覧。
PKIの利用者Cが別の利用者（もしくは団体、認証局）Dの公開鍵が本当にDのものであることを確認するには、に対する公開鍵証明書を入手する。次に、この公開鍵証明書を発行した認証局Eの公開鍵と、に対する公開鍵証明書とを入手する。以下同様に繰り返し、最後にトラストアンカーの認証局Zにたどり着き、しかもそれまでに入手した公開鍵証明書が署名文として正当なものであれば、公開鍵をDの公開鍵として受理し、そうでなければ棄却する。
以上がPKIの基本的な仕組みである。PKIには、この他にも公開鍵を失効するための仕組みや利用者の属性を証明する仕組みなどが備わっている。
認証局
認証局は公開鍵証明書などの電子証明書を発行するエンティティである。
運用ポリシー
各認証局は証明書の利用目的を定める証明書ポリシー（CP、Certificate Policy）と、CA の運用方法を定める認証実施規定（CPS、Certification Practice Statement）を規定する（）IPA034 2016年8月3日閲覧。
信頼モデル
認証局同士の信頼関係のモデルを信頼モデルという。様々な組織が様々な信頼モデルに基づいて認証局を運用しているが、代表的な信頼モデルとして以下のものがある。
単独モデルは1つの認証局が全てのユーザに証明書を発行するモデルであり、企業内の認証局などユーザ数が小規模な場合に用いられる。
階層型モデルは複数の認証局がツリー型の階層構造をなすモデルであり、WebモデルはWebブラウザなどのクライアントアプリケーションに予め認証局の一覧を埋め込むモデルである。
メッシュモデルは階層構造を持たない認証局が相互に認証しあうモデルであり、異なる運用ポリシー(＝CPとCPSの記載内容)を持つ「CAドメイン」の間を横断して接続する際に使われるIPA055。メッシュモデルでは異なるCAドメインにある認証局同士が相互に認証しあう相互認証でつながりあう。相互認証で用いられる証明書を相互認証証明書という。
ブリッジCAモデルは認証局同士がブリッジCAという認証局を通して接続するモデルである。メッシュモデルと同じく異なるCAドメイン間を結びつけるときに用いるが、各認証局が相互に認証しあうメッシュモデルと違い、各認証局は1つのブリッジCAとのみ相互認証する。これにより認証局1ブリッジCA認証局2というブリッジCAを媒介とした信頼関係が形成される。認証局の数が多い場合、認証局同士が直接相互認証するメッシュモデルでは相互認証の数が膨大になるが、ブリッジCAモデルではブリッジCAを媒介としたスター型のトポロジーの相互認証が形成されるのみなので、認証パスの数を減らすことができるという利点があるIPA056。
ルート認証局
ルート認証局とは上位の認証局の認証を受けず、自分の正当性を自分で証明する認証局のことe-words「ルート認証局」 2016年8月3日閲覧で、階層型モデルにおけるツリーの頂点に位置する認証局やWebモデルでアプリケーションに事前に登録されている認証局がこれに相当する。この二種類のルート認証局を区別するため、Webモデルのルート認証局をパブリックルート認証局と呼ぶことがあるJIPDEC用語集「ルート認証局」 2016年8月3日閲覧。ルート認証局以外の認証局は中間認証局と呼ぶ。
ルート認証局はPKIの信頼の起点であるトラストアンカーとして機能する。いずれかのCAドメインに属するルート認証局をトラストアンカーとして採用すれば、そのCAドメインと相互認証されている他のCAドメインの認証局の証明書も、相互認証を介してトラストアンカーまでたどり着くことができる。
電子証明書
電子証明書とは公開鍵証明書をはじめとした、認証局が発行する証明書のことである。電子証明書の標準としてX.509が広く採用されている。X.509に従って作成された電子証明書は、X.509証明書と呼ばれる。
電子証明書の種類
X.509証明書には次の3種類がある。公開鍵とその所有者の対応関係を証明する公開鍵証明書、公開鍵証明書で証明された人が所有する権限や役割を証明する属性証明書、自然に対して発行することを目的とした適格証明書があるIPA033、IPA092 2016年8月3日閲覧。単に証明書といった場合は公開鍵証明書を指すことが多い。
公開鍵証明書には認証局に対して発行するCA証明書とPKIのユーザに対して発行されるエンドエンティティ証明書があるIPA033 2016年8月3日閲覧。CA証明書の特殊なものとして、認証局が自身の秘密鍵で署名した自己署名証明書がある。
暗号用の公開鍵と署名検証用の公開鍵は別のものを用いることが多く、このためこれら２つの公開鍵に別々の公開鍵証明書を発行することが多い。このような方法をデュアル鍵ペア方式という。
認証局が他の認証局に証明書を発行する場合などでは、相手を完全に信用するのではなく、証明書の拡張領域に条件を記載することで条件付きの信頼関係を構築することも可能である。
公開鍵証明書の発行
公開鍵証明書を発行する際、主に2つの作業を行う。1つ目は新しく証明書を発行してほしいエンティティ（以下、「加入者」）の本人確認などの登録手続きで、2つ目は加入者に実際に公開鍵証明書を発行することである。
この２つの手続きをいずれも認証局が行う運用形態もあるが、２つの手続きを別の機関で運用する運用形態もあり、この場合登録手続きを行う機関を登録局（RA、Registration Authority）、証明書発行手続きを行う機関を発行局（IA、Issuing Authority）というOSS モデルカリキュラムの学習ガイダンス6-1-応。暗号化に関する知識 IPA。p14 2016年8月4日閲覧＠ITセキュリティ用語辞典「IA（Issuing Authority）」 2016年8月4日閲覧。
ただし「発行局」という言葉は実際にはあまり使われていず、発行局のことを「認証局」と呼ぶことが多い。本稿でも、以下では発行局を認証局と呼ぶことにする。
証明書の発行手順は以下のとおりである。まず加入者は自身が用いる公開鍵・秘密鍵ペアの生成と登録局における本人確認とを行うIPA032 2016年8月3日閲覧。
次に加入者は登録局に証明書の発行申請を行い、登録局は認証局に証明書の発行を依頼する。認証局は申請書を確認したあと証明書を発行し、登録局経由で証明書を加入者に配布する。
認証局はPKIの他の利用者が加入者の証明書を見つけやすいよう、（もしリポジトリがあれば）加入者の証明書をリポジトリに公開する。
上では加入者が自分で鍵ペアの生成するケースを説明したが、企業が全新入社員を加入者として一括登録するようなケースでは登録局である企業の側が全員分の鍵ペアを生成して各加入者に鍵ペアを配布する事も有り得る。この場合登録局が加入者に証明書を配布する際、一緒に秘密鍵も配布する。
他の利用者の公開鍵証明書の入手
PKIの利用者Aが別の利用者Bの公開鍵証明書を入手する方法として、利用者Bから電子メールなどの手段を用いて公開鍵証明書を送ってもらうというものがある。これをアウトオブバンドの送信方法というIPA62 2016年8月5日閲覧。
また公開鍵暗号や電子署名を利用する通信プロトコルの一部として公開鍵証明書の送信方法が組み込まれている場合があり、こうした通信プロトコルにしたがって利用者Bから公開鍵証明書を送信してもらう方法をインバンドな送信方法というIPA632016年8月5日閲覧。インバンドで公開鍵証明書を送信するプロトコルとしてS/MIME、PGP、TLSなどがある。
利用者Bから直接証明書を送ってもらうのではなく、多数の利用者の証明書を保存しているリポジトリからBの証明書を受け取る方法もある。リポジトリの実装方法に関しては様々なものがあり、いくつかはRFCになっている。具体的にはLDAP（RFC2559）やX.500のようなディレクトリ・サービスを利用したもののほか、FRPやHTTP（RFC2585）を使ったもの、DNS（RFC2538）を使ったものがある。
公開鍵証明書の更新
公開鍵証明書には有効期限が定まっており、この有効期限を超えた期限切れの証明書は無効になってしまう。
そこでPKIの利用者は証明書の期限が切れる前に新しい鍵ペアを生成し、新しい鍵ペアに対する証明書を発行してもらう必要がある。この作業を証明書の更新という。
更新時には古い鍵ペアを使って認証局から認証を受ける事ができるので、新しい証明書の発行の際にはネットワーク越しに更新手続きを行うことができる。
更新手続きを行ってから古い証明書が有効期限切れになるまでの間は、新旧両方の証明書がある事になる。この新旧の証明書を関連付けるため、リンク証明書という証明書を認証局から発行してもらう。リンク証明書にはNewWithOld、OldWithNewなどの証明書がある。NewWithOldは古い鍵ペアを使って作成した新しい公開鍵に対する証明書で、OldWithNewは逆に新しい鍵ペアを使って作成した古い公開鍵に対する証明書である。
利用者Aの古い公開鍵とその証明書（OldWithOld証明書という）をすでに所有している（Aとは別の）利用者Bは、利用者Aの新しい公開鍵とともにNewWithOld証明書を受け取る事で新しい公開鍵の真正性を確認できる。これにより利用者Bは利用者Aが新しい鍵ペアで署名した署名文の正当性を検証する事ができる。
逆に利用者Aの新しい公開鍵とその証明書（NewWithNew証明書という）をすでに所有している（Aとは別の）利用者Cは、利用者Aの古い公開鍵とともにOldWithNew証明書を受け取る事で古い公開鍵の真正性を確認できる。これにより利用者Cは利用者Aが古い鍵ペアで署名した署名文の正当性を検証する事ができる。
公開鍵証明書の失効
自身が保有する秘密鍵が漏洩した場合や、退職等により署名権限失った場合には、まだ期限が切れていない公開鍵証明書を無効化する必要がある。このための手続きを公開鍵証明書の失効というIPA041。
失効した証明書のリストの管理は認証局自身が行う場合と証明書の有効性検証に特化した組織が行う場合があり、後者の場合その組織を検証局というIT用語辞典e-words「検証局」 2016年8月5日閲覧セコムトラストシステムズBPC用語辞典「VA」 2016年8月5日閲覧。
証明書が失効しているか否かを確認する方法としてCRLとOCSPがある。
CRL
CRL（Certificate Revocation List、証明者失効リスト）はすでに失効した公開鍵証明書（のシリアル番号）のリストである。各利用者がこのリストを確認することで公開鍵の失効状況を確認ができるIPA042。
CRLの発行者は多くの場合証明書を発行した認証局自身であり、CRLにはその真正性を示すため発行者の署名が付与されている。
CRLはリポジトリという公開サーバに格納し、PKIの利用者はこのサーバにアクセスすることでCRLを入手できる。
CRLの中には、認証局の失効情報に特化したものが存在し、これを認証局失効リスト（ARL、Authority Revocation List）という。
CRLは定期的に更新され、新しい失効情報がCRLに随時載っていく。しかし利用者が証明書の失効を申請してからCRLが更新されるまでタイムラグが生じるという問題を抱える。そこでCRLの定期更新より早い頻度で最後の更新が行われてからの差分情報が公開することがある。この差分情報をデルタCRLという。
CRLの運用形態にはいくつかある。完全CRLは全ての失効情報を１つのCRLに記載する方法であるが、失効情報の数が大きくなるとCRL取得の負荷が大きくなる。
区分CRLでは失効情報を複数のCRLに分割する。区分CRLを用いるには証明書発行の段階で、その証明書が失効した場合に失効情報がどのCRLに載るかという情報（CRL配布点、CRLDP、CRL Distribution Point）を証明書に記載しておく。PKIの利用者はCRLDPを頼りにして、リポジトリから必要な区分CRLを取得する。
またPKI利用者の利便性を高めるため、様々な認証局が発行したCRLを別のCRL発行者が１つにまとめて配布する場合があり、このようなCRLを間接CRL（indirect CRL）という。
OCSP
OCSP（Online Certificate Status Protocol）は証明書の失効状況の確認を実現するプロトコルでありIPA043、に規定されている。
この方法ではOCSPレスポンダというサーバに証明書が失効しているかどうかの情報が一括管理されている。証明書の失効状況を知りたい利用者（OCSPリクエスタ）がOCSPレスポンダに失効情報の問い合わせを行うと、OCSPレスポンダは「有効」、「失効」、「不明」のいずれかを返す。この際返答内容に対するOCSPレスポンダの署名文も同時に送信する。
失効情報をOCSPレスポンダで管理するため、認証局は失効情報をOCSPレスポンダに送信する必要がある。その際の送信プロトコルに規定はないが、CRLの形で失効情報を認証局から得たり、OCSPのプロトコルにしたがって認証局に失効情報を確認したりする。
またOCSPレスポンダとOCSPリクエスタの間の通信のレイヤに関しても規定がないが、HTTP、SMTP、LDAPなどが使われる。
日本の行政機関におけるPKI
政府認証基盤（GPKI、Government PKI）は日本政府が運用するPKIであり、IT用語辞典e-Words「GPKI」 2016年8月5日閲覧全省庁共通の政府共用認証局（官職認証局）、政府認証基盤の外にある認証局と相互認証するためのブリッジ認証局、および国民や企業に配る文書やプログラムにつける署名に対する証明書を発行するアプリケーション認証局から構成される政府認証基盤(GPKI)について 総務省 行政管理局 政府認証基盤(GPKI)。および同サイトのトップページ。2016年8月5日閲覧政府認証基盤システム調達計画書（区分：最適化対象業務・システム(pdf) 総務省行政管理局行政情報システム企画課 情報システム管理室。2016年8月5日閲覧政府認証基盤（GPKI）アプリケーション認証局 CP/CPS p10。
なおもともとは各省庁が自身で用いる認証局（府省認証局）を設置し、それらを総務省が設置しているブリッジ認証局を通して相互認証する構成であったがIPA081、府省認証局は平成20年以降順次廃止され、上述したスタイルになっている。
政府認証基盤では行政機関の公文書に対して署名するときに用いられる電子証明書を発行しており、これを官職証明書という地方公共団体情報システム機構公的個人認証サービスポータルサイト用語の解説「官職証明書」 2016年8月5日閲覧。他にも府省等が運用する情報システムの認証等に使用する利用者証明書や暗号鍵の証明書として用いる暗号化通信用等証明書を発行している政府認証基盤（GPKI）官職認証局 CP/CPS(pdf) 2016年8月5日閲覧。
一方、日本の地方公共団体は地方公共団体情報システム機構が運営している地方公共団体組織認証基盤（LGPKI、Local Government Public Key Infrastructure）というPKIを利用している地方公共団体組織認証基盤 、地方公共団体情報システム機構。2016年8月5日閲覧。LGPKIの認証局には地方公共団体の首長や管理職に職責証明書を発行する組織認証局、電子行政サービスのWebサーバの証明書などを発行するアプリケーション認証局、およびブリッジ認証局がある。
公的個人認証サービス（JPKI, Japanese Public Key Infrastructure）は都道府県単位認証局が各住人に対して住人の公開鍵に対する証明書を発行するサービスである公的個人認証サービスの利活用について、総務省。2016年8月5日閲覧。この公開鍵と証明書を使うことで各種行政サービスを受けることができる。2016年1月からは民間利用が開放されたので、民間のサービスを受ける際にも公的個人認証サービスが利用可能になったマイナンバーカード（電子証明書）を活用する公的個人認証サービスの利用を行う民間事業者として、初の大臣認定を実施 総務省。2016年8月5日閲覧。
関連技術
時刻認証局とタイムスタンプ
電子的なタイムスタンプとは、 信頼できる第三者機関（時刻認証局、Time Stamping Authority, TSA,一般財団法人日本データ通信協会タイムビジネス認定センター「タイムスタンプの仕組み」 2016年8月25日閲覧）が電子的な文書に対してつける時刻の証明書（タイムスタンプトークン一般財団法人日本データ通信協会タイムビジネス認定センター「タイムスタンプの方式」 2016年8月25日閲覧情報セキュリティ対策研究開発評価等事業タイムスタンプ技術に関する調査報告書(pdf) p10、 IPA、2003年。2016年8月25日閲覧、Time-Stamp Token、TST）を発行する技術である。タイムスタンプトークンの生成方法には様々なものがあるが、後述のようにPKIを利用したものもある。なお時刻認証局が証明書に記載する時刻情報は、原子時計などの正確な時間計測器を管理している時刻配信局（Time Assessment Authority、TAA一般財団法人日本データ通信協会タイムビジネス認定センター「タイムスタンプの時刻」 2016年8月25日閲覧）から配信してもらう。
タイムスタンプには以下の種類がある。 PKIベース：PKIによる公開鍵証明書付きの電子署名を用いる リンクトークン方式：ハッシュチェイン技術を利用した方式。時刻認証局がリンクトークンと呼ばれるハッシュ値１つを管理。不特定多数の利用者から文書が送られてくるたびに、その文書とリンクトークンとのハッシュ値を計算し、そのハッシュ値を新しいリンクトークンとする。 MACベース アーカイビング方式：時刻認証局が文書のハッシュ値をすべて保管する方式 Transient鍵方式：短時間だけ有効な署名鍵を使う方式
方式 X9.95 ISO/IEC 18014 PKI リンクトークン MAC アーカイビング Transient鍵 署名つきリンクトークン
より詳細な分類と評価は日本銀行の宇根正志による文献を参照。
なお、TAAに関する標準はJIS X5094:2011として標準化されており、これは後にISO/IEC 18014-4として国際標準化もされた。
高度電子署名と長期署名 高度電子署名（Advanced Electronic Signature、略してAdES）とはEUの規則eIDASで定められたもので、電子署名の中で自然人ないしその代理人との対応付けがとれるものを指す長期署名フォーマットの標準化と日欧相互運用実験(pdf) 2016年8月26日閲覧。。なお、高度電子署名で、安全な署名デバイスで生成され、さらに適格証明書（qualified certificate）がつけられたものは適格署名（Qualified Signature）という。
高度電子署名の標準化はCMS（暗号メッセージ構文）に従ったCAdES（ETSI TS 101 733、RFC5126、ISO14533-1電子契約導入のための２０のヒントその２０ 2016年8月26日閲覧。）、XMLに従ったXAdES（ETSI TS 101 903、ISO14533-2）、PDFに従ったPAdES（ETSI TS 102 778、ISO 32000-1）がある。いずれも欧州電気通信標準化機構(ETSI)がその標準を策定し、ISOやRFCにも採用されている。
高度電子署名では提供される保護レベルの異なる6つのフォーマットを規定しており、その中には鍵の危殆化などに対応する長期署名の標準も規定されている。以下ではXAdESを例に説明したが、CAdESやPAdESも同様である： XAdES, 高度署名(advanced signature)に関する欧州指針を単に満足するための基本フォーマット XAdES-T（timestamp）：署名行為の否認に対して保護するためにタイムスタンプを追加する。 XAdES-C（complete), オフライン検証や将来的な検証ができるように(証明書や証明書失効リストなどの)検証データへの参照情報を署名文書に追加する。(しかしながら検証情報は保存しない) XAdES-X（extended), 将来、チェーン中の証明書が危殆化する可能性から保護するために、XAdES-Cで導入された参照情報に対してタイムスタンプを追加する。 XAdES-X-L（extended long-term), 証明書や証明書失効リストの配布元が利用できなくなったとしても、将来検証できるように署名文書に証明書や失効リストそのものを追加する。 XAdES-A（archival), 長期に渡る保存期間において署名が脆弱になることによる危殆化を避けるために、アーカイブされたドキュメントに対し定期的(例えば毎年)にタイムスタンプを追加する
権限管理基盤(PMI)と属性証明書 (Privilege Management Infrastructure、PMI)とは、PKIと類似した方法により、個人の持つ権限や属性を証明するための基盤技術であるIPA091 2016/8/29閲覧「電子申請業務におけるX.509属性証明書を用いた資格確認技術の開発」平成13年度年次総括報告書(pdf) 2016/8/29閲覧。この基盤において権限や属性を証明する証明書を（attribute certificate, or authorization certificate、AC）と呼び、PKIと同様X.509のフォーマットに従う。またPKIにおける認証局、ルート認証局に相当する機関をそれぞれ権限局（Attribute Authorities、AA。直訳は「属性権限者」）、ルート権限局（Sources of Authority、SOA）と呼ぶ。
その他 信用の輪 (Web of Trust)
公開鍵への署名を認証局が行う場合、その公開鍵の持ち主を信用するかどうかは、認証局の信用度に委ねられる。また、認証局による署名はコストや手間がかかる場合が多い。さらに、Webブラウザが認証局の公開鍵を同梱している場合、Webブラウザの配布元の信頼性を確保する必要がある。これらの問題を解決する手段として信用の輪 (Web of Trust) を構築する方法が挙げられる。これは、信頼し合う者同士が互いの公開鍵に自ら署名し合うことによって、互いの信用度を維持し、更に複数の者がこれを行うことで、直接署名の交換をしていない者同士でも、信頼している第三者を介することによって相手の信用度を維持できるというものである。この時の相手までの信頼関係の経路のことを信用パス (trust path) という。例としてPGP (Pretty Good Privacy) や、その標準仕様である OpenPGP のフリーな実装であるGnuPG (The GNU Privacy Guard) が挙げられる。PGPやそのクローンがEメールで広く使用されているので、最初にPGPによって実装された信用の輪は2004年現在最も広く使われている双方向PKIとなっている。CAcert.orgは、信頼関係の全情報がすべて中央のデータベースに入れられることを除いて、PGPの信用の輪と同等のPKI Web of Trustを運営している。
MSD (mean shortest distance) 信用の輪における特定の鍵の信用度を表す指標の一つに MSD (mean shortest distance) があるanalysis of the strong set in the PGP web of trust。これは、信頼の輪に含まれているすべての人からの信用パスの最短長の平均値によって計算される。これは、信用パスが長いほど信用度は下がり、また多くの人から署名されているほど信用度が上がるという考え方に基づいている。右図の rio について、MSDを計算すると、信用パスの最短長は、james:1、mike:1、ken:2、john:2、lucy:3であるから、MSD はその平均の1.8となる。
キーサインパーティー 公開鍵への署名は、信頼性を確保するために署名する相手と直接会って行われるが、署名の交換を効率的に行うために、が開催されることがある。これにより、個別に会って行う場合に比べ、一度に多数の人と署名の交換を行うことが可能である。
多くのキーサインパーティーでは、が利用されており、以下の手順によって行う。Keysigning Party Methods - The 'Sassaman-Efficient' Method
キーサインパーティーの主催者に、自分の公開鍵を送付する。 主催者は、参加者の公開鍵が集まった時点で、公開鍵のリストを参加者全員に送付する。 参加者は受け取ったリストを印刷し、リストのハッシュ値を計算して印刷したリストに書き込む。 キーサインパーティーの開始時に参加者全員でハッシュ値を確認し、全員のリストが同一のものであることを検証する。