公開鍵基盤

PKIの実現例として、たとえばX.509（PKIX: Public-Key Infrastructure using X.509）がある。

インターネットのような電子的な通信路を介して通信を行う際、通信の安全性を確保するための技術として、公開鍵暗号方式や電子署名方式がある。これらの技術では通信相手の公開鍵を用いることで送信する文書を暗号化したり、文章に対する署名を検証したりすることで、文章の秘匿性や真正性を保証する。

これらの技術を使う際には、暗号化や署名検証で用いた公開鍵が通信相手のものであることを事前に確認する必要がある。なぜなら、もしこの確認がなされていないと、たとえば、不正者が通信相手の公開鍵を偽の公開鍵とすりかえるなりすましなどの攻撃が可能になってしまうからである。

しかし、公開鍵とその持ち主との対応関係を確実に保証するのは容易ではない。インターネットは基本的に匿名の通信路であるので、公開鍵の所有者と名乗っている人物が本当に所有者当人であるのかを知るのは容易ではないからである。

PKIは、公開鍵とその持ち主の対応関係を認証局（CA、Certification Authority）という第三者機関を用いて保証するための技術である。

各認証局Aは自身の公開鍵pk_Aを公開しており、この公開鍵pk_Aとそれに対応する秘密鍵を用いることで、PKIの利用者や団体、他の認証局などの公開鍵pk_Bとその所有者名Bの組（とその他必要情報を合わせたもの）に対する署名文cert_Bを作成する。この署名文cert_Bを、公開鍵pk_Bの所有者がBであることを保証する公開鍵証明書（public key certificate）という。

PKIの各利用者Cは、自身が最も信頼できると思われる認証局Zの公開鍵を事前に何らかの方法で入手しておく（方法は後述する）。この認証局Zの公開鍵pk_Zは、PKIにおける全ての信頼関係の起点となるので、認証局ZをCのトラストアンカー（Trust Anchor、信用点とも）という。

PKIの利用者Cが別の利用者（もしくは団体、認証局）Dの公開鍵pk_Dが本当にDのものであることを確認するには、pk_Dに対する公開鍵証明書cert_Dを入手する。次に、この公開鍵証明書cert_Dを発行した認証局Eの公開鍵pk_Eと、pk_Eに対する公開鍵証明書cert_Eとを入手する。以下同様に繰り返し、最後にトラストアンカーの認証局Zにたどり着き、しかもそれまでに入手した公開鍵証明書が署名文として正当なものであれば、公開鍵pk_DをDの公開鍵として受理し、そうでなければ棄却する。

以上がPKIの基本的な仕組みである。PKIには、この他にも公開鍵を失効するための仕組みや利用者の属性を証明する仕組みなどが備わっている。

認証局は公開鍵証明書などの電子証明書を発行するエンティティである。

運用ポリシー

各認証局は証明書の利用目的を定める証明書ポリシー（CP、Certificate Policy）と、CA の運用方法を定める認証実施規定（CPS、Certification Practice Statement）を規定する（RFC 3647）。

信頼モデル

認証局同士の信頼関係のモデルを信頼モデルという。様々な組織が様々な信頼モデルに基づいて認証局を運用しているが、代表的な信頼モデルとして以下のものがある。

単独モデルは1つの認証局が全てのユーザに証明書を発行するモデルであり、企業内の認証局などユーザ数が小規模な場合に用いられる。

階層型モデルは複数の認証局がツリー型の階層構造をなすモデルであり、WebモデルはWebブラウザなどのクライアントアプリケーションに予め認証局の一覧を埋め込むモデルである。

メッシュモデルは階層構造を持たない認証局が相互に認証しあうモデルであり、異なる運用ポリシー(＝CPとCPSの記載内容)を持つ「CAドメイン」の間を横断して接続する際に使われる。メッシュモデルでは異なるCAドメインにある認証局同士が相互に認証しあう相互認証でつながりあう。相互認証で用いられる証明書を相互認証証明書という。

ブリッジCAモデルは認証局同士がブリッジCAという認証局を通して接続するモデルである。メッシュモデルと同じく異なるCAドメイン間を結びつけるときに用いるが、各認証局が相互に認証しあうメッシュモデルと違い、各認証局は1つのブリッジCAとのみ相互認証する。これにより認証局1↔ブリッジCA↔認証局2というブリッジCAを媒介とした信頼関係が形成される。認証局の数が多い場合、認証局同士が直接相互認証するメッシュモデルでは相互認証の数が膨大になるが、ブリッジCAモデルではブリッジCAを媒介としたスター型のトポロジーの相互認証が形成されるのみなので、認証パスの数を減らすことができるという利点がある。

ルート認証局

ルート認証局とは上位の認証局の認証を受けず、自分の正当性を自分で証明する認証局のことで、階層型モデルにおけるツリーの頂点に位置する認証局やWebモデルでアプリケーションに事前に登録されている認証局がこれに相当する。この二種類のルート認証局を区別するため、Webモデルのルート認証局をパブリックルート認証局と呼ぶことがある。ルート認証局以外の認証局は中間認証局と呼ぶ。

ルート認証局はPKIの信頼の起点であるトラストアンカーとして機能する。いずれかのCAドメインに属するルート認証局をトラストアンカーとして採用すれば、そのCAドメインと相互認証されている他のCAドメインの認証局の証明書も、相互認証を介してトラストアンカーまでたどり着くことができる。

電子証明書とは公開鍵証明書をはじめとした、認証局が発行する証明書のことである。電子証明書の標準としてX.509が広く採用されている。X.509に従って作成された電子証明書は、X.509証明書と呼ばれる。

電子証明書の種類

X.509証明書には次の3種類がある。公開鍵とその所有者の対応関係を証明する公開鍵証明書、公開鍵証明書で証明された人が所有する権限や役割を証明する属性証明書、自然に対して発行することを目的とした適格証明書がある。単に証明書といった場合は公開鍵証明書を指すことが多い。

公開鍵証明書には認証局に対して発行するCA証明書とPKIのユーザに対して発行されるエンドエンティティ証明書がある。CA証明書の特殊なものとして、認証局が自身の秘密鍵で署名した自己署名証明書がある。

暗号用の公開鍵と署名検証用の公開鍵は別のものを用いることが多く、このためこれら２つの公開鍵に別々の公開鍵証明書を発行することが多い。このような方法をデュアル鍵ペア方式という。

認証局が他の認証局に証明書を発行する場合などでは、相手を完全に信用するのではなく、証明書の拡張領域に条件を記載することで条件付きの信頼関係を構築することも可能である。

公開鍵証明書の発行

公開鍵証明書を発行する際、主に2つの作業を行う。1つ目は新しく証明書を発行してほしいエンティティ（以下、「加入者」）の本人確認などの登録手続きで、2つ目は加入者に実際に公開鍵証明書を発行することである。

この２つの手続きをいずれも認証局が行う運用形態もあるが、２つの手続きを別の機関で運用する運用形態もあり、この場合登録手続きを行う機関を登録局（RA、Registration Authority）、証明書発行手続きを行う機関を発行局（IA、Issuing Authority）という。

ただし「発行局」という言葉は実際にはあまり使われていず、発行局のことを「認証局」と呼ぶことが多い。本稿でも、以下では発行局を認証局と呼ぶことにする。

証明書の発行手順は以下のとおりである。まず加入者は自身が用いる公開鍵・秘密鍵ペアの生成と登録局における本人確認とを行う。

次に加入者は登録局に証明書の発行申請を行い、登録局は認証局に証明書の発行を依頼する。認証局は申請書を確認したあと証明書を発行し、登録局経由で証明書を加入者に配布する。

認証局はPKIの他の利用者が加入者の証明書を見つけやすいよう、（もしリポジトリがあれば）加入者の証明書をリポジトリに公開する。

上では加入者が自分で鍵ペアの生成するケースを説明したが、企業が全新入社員を加入者として一括登録するようなケースでは登録局である企業の側が全員分の鍵ペアを生成して各加入者に鍵ペアを配布する事も有り得る。この場合登録局が加入者に証明書を配布する際、一緒に秘密鍵も配布する。

他の利用者の公開鍵証明書の入手

PKIの利用者Aが別の利用者Bの公開鍵証明書を入手する方法として、利用者Bから電子メールなどの手段を用いて公開鍵証明書を送ってもらうというものがある。これをアウトオブバンドの送信方法という。

また公開鍵暗号や電子署名を利用する通信プロトコルの一部として公開鍵証明書の送信方法が組み込まれている場合があり、こうした通信プロトコルにしたがって利用者Bから公開鍵証明書を送信してもらう方法をインバンドな送信方法という。インバンドで公開鍵証明書を送信するプロトコルとして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が古い鍵ペアで署名した署名文の正当性を検証する事ができる。

公開鍵証明書の失効

自身が保有する秘密鍵が漏洩した場合や、退職等により署名権限失った場合には、まだ期限が切れていない公開鍵証明書を無効化する必要がある。このための手続きを公開鍵証明書の失効という。

失効した証明書のリストの管理は認証局自身が行う場合と証明書の有効性検証に特化した組織が行う場合があり、後者の場合その組織を検証局という。

証明書が失効しているか否かを確認する方法としてCRLとOCSPがある。

CRL

CRL（Certificate Revocation List、証明者失効リスト）はすでに失効した公開鍵証明書（のシリアル番号）のリストである。各利用者がこのリストを確認することで公開鍵の失効状況を確認ができる。

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）は証明書の失効状況の確認を実現するプロトコルであり、RFC 6960に規定されている。

この方法ではOCSPレスポンダというサーバに証明書が失効しているかどうかの情報が一括管理されている。証明書の失効状況を知りたい利用者（OCSPリクエスタ）がOCSPレスポンダに失効情報の問い合わせを行うと、OCSPレスポンダは「有効」、「失効」、「不明」のいずれかを返す。この際返答内容に対するOCSPレスポンダの署名文も同時に送信する。

失効情報をOCSPレスポンダで管理するため、認証局は失効情報をOCSPレスポンダに送信する必要がある。その際の送信プロトコルに規定はないが、CRLの形で失効情報を認証局から得たり、OCSPのプロトコルにしたがって認証局に失効情報を確認したりする。

またOCSPレスポンダとOCSPリクエスタの間の通信のレイヤに関しても規定がないが、HTTP、SMTP、LDAPなどが使われる。

政府認証基盤（GPKI、Government PKI）は日本政府が運用するPKIであり、全省庁共通の政府共用認証局（官職認証局）、政府認証基盤の外にある認証局と相互認証するためのブリッジ認証局、および国民や企業に配る文書やプログラムにつける署名に対する証明書を発行するアプリケーション認証局から構成される。

なおもともとは各省庁が自身で用いる認証局（府省認証局）を設置し、それらを総務省が設置しているブリッジ認証局を通して相互認証する構成であったが、府省認証局は平成20年以降順次廃止され、上述したスタイルになっている。

政府認証基盤では行政機関の公文書に対して署名するときに用いられる電子証明書を発行しており、これを官職証明書という。他にも府省等が運用する情報システムの認証等に使用する利用者証明書や暗号鍵の証明書として用いる暗号化通信用等証明書を発行している。

一方、日本の地方公共団体は地方公共団体情報システム機構が運営している地方公共団体組織認証基盤（LGPKI、Local Government Public Key Infrastructure）というPKIを利用している。LGPKIの認証局には地方公共団体の首長や管理職に職責証明書を発行する組織認証局、電子行政サービスのWebサーバの証明書などを発行するアプリケーション認証局、およびブリッジ認証局がある。

公的個人認証サービス（JPKI, Japanese Public Key Infrastructure）は都道府県単位認証局が各住人に対して住人の公開鍵に対する証明書を発行するサービスである。この公開鍵と証明書を使うことで各種行政サービスを受けることができる。2016年1月からは民間利用が開放されたので、民間のサービスを受ける際にも公的個人認証サービスが利用可能になった。

時刻認証局とタイムスタンプ

電子的なタイムスタンプとは、 信頼できる第三者機関（時刻認証局、Time Stamping Authority, TSA,）が電子的な文書に対してつける時刻の証明書（タイムスタンプトークン、Time-Stamp Token、TST）を発行する技術である。タイムスタンプトークンの生成方法には様々なものがあるが、後述のようにPKIを利用したものもある。なお時刻認証局が証明書に記載する時刻情報は、原子時計などの正確な時間計測器を管理している時刻配信局（Time Assessment Authority、TAA）から配信してもらう。

タイムスタンプには以下の種類がある。

• PKIベース：PKIによる公開鍵証明書付きの電子署名を用いる
• リンクトークン方式：ハッシュチェイン技術を利用した方式。時刻認証局がリンクトークンと呼ばれるハッシュ値１つを管理。不特定多数の利用者から文書が送られてくるたびに、その文書とリンクトークンとのハッシュ値を計算し、そのハッシュ値を新しいリンクトークンとする。
• MACベース
• アーカイビング方式：時刻認証局が文書のハッシュ値をすべて保管する方式
• Transient鍵方式：短時間だけ有効な署名鍵を使う方式

より詳細な分類と評価は日本銀行の宇根正志による文献を参照。

なお、TAAに関する標準はJIS X5094:2011として標準化されており、これは後にISO/IEC 18014-4として国際標準化もされた。

高度電子署名と長期署名

高度電子署名（Advanced Electronic Signature、略してAdES）とはEUの規則eIDASで定められたもので、電子署名の中で自然人ないしその代理人との対応付けがとれるものを指す。なお、高度電子署名で、安全な署名デバイスで生成され、さらに適格証明書（qualified certificate）がつけられたものは適格署名（Qualified Signature）という。

高度電子署名の標準化はCMS（暗号メッセージ構文）に従ったCAdES（ETSI TS 101 733、RFC5126、ISO14533-1）、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と類似した方法により、個人の持つ権限や属性を証明するための基盤技術である。この基盤において権限や属性を証明する証明書を属性証明書（英語版）（attribute certificate, or authorization certificate、AC）と呼び、ＰＫＩと同様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) がある。これは、信頼の輪に含まれているすべての人からの信用パスの最短長の平均値によって計算される。これは、信用パスが長いほど信用度は下がり、また多くの人から署名されているほど信用度が上がるという考え方に基づいている。右図の rio について、MSDを計算すると、信用パスの最短長は、james:1、mike:1、ken:2、john:2、lucy:3であるから、MSD はその平均の1.8となる。

キーサインパーティー

公開鍵への署名は、信頼性を確保するために署名する相手と直接会って行われるが、署名の交換を効率的に行うために、キーサインパーティー（英語版）が開催されることがある。これにより、個別に会って行う場合に比べ、一度に多数の人と署名の交換を行うことが可能である。

多くのキーサインパーティーでは、Sassaman-Efficient 方式（英語版）が利用されており、以下の手順によって行う。

1. キーサインパーティーの主催者に、自分の公開鍵を送付する。
2. 主催者は、参加者の公開鍵が集まった時点で、公開鍵のリストを参加者全員に送付する。
3. 参加者は受け取ったリストを印刷し、リストのハッシュ値を計算して印刷したリストに書き込む。
4. キーサインパーティーの開始時に参加者全員でハッシュ値を確認し、全員のリストが同一のものであることを検証する。
5. 参加者は2列になって向かい合い、互いに本人確認（パスポートや免許証などの確認）をし、同時にリストのハッシュ値、及び記載された公開鍵の指紋（フィンガープリント）が正しいことを伝える。
6. 本人確認と公開鍵の検証を行ったら、リストに印を付ける。
7. 列をずらし、別の人と5、6の作業を繰り返し、これを全員に対して行う。
8. キーサインパーティーが終わったら、印を付けた相手の公開鍵をキーサーバーからダウンロードする。
9. 公開鍵の指紋がリストに記載されているものと同一であることを確認し、自分の秘密鍵で相手の公開鍵に署名し、相手に送付する。
10. 署名付きの公開鍵を受け取ったら、自分の鍵束に署名付きの鍵を取り込み、キーサーバーにアップロードする。

注意点として、公開鍵への署名を施す場合に念入りに本人確認を行うことである。インターネット上に配布されている公開鍵に対する安易な署名など、本人確認をせずに署名を行った場合、鍵の持ち主を特定することができず Web of Trust そのものの信頼性が著しく損なわれることになる。

また、未署名の公開鍵によるソフトウェアへの署名は、署名の意味をなさないことについても注意が必要である。

利用

Debianやその派生OSなどの一部のLinuxディストリビューションでは、配布されているすべてのパッケージについて開発者がGnuPG署名を施すことで、パッケージの改ざんを防止している。したがって、Debianの開発者には Web of Trust への参加が義務付けられている。Linuxカーネルの開発においても、Web of Trust への参加が求められている。一方、開発者に限らず一般のユーザーも、Web of Trust に参加することで自分が使用しているソフトウェアの安全性を検証できる。

GitやBazaarなどの一部のバージョン管理システムには、リビジョンに対してGnuPG署名を施すことができるシステムが備わっている。

簡易公開鍵基盤（Simple Public Key Infrastructure)

その他の選択肢として簡易公開鍵基盤（SPKI、スプーキーと読む）がある。これは公開鍵によるパブリック認証を行うものではないが、X.509の複雑さとPGPの Web of trust を克服しようという三つの独立した試みから生まれた。SPKIは人を鍵に結び付けることはしない。何故なら信頼されるのは人ではなく鍵そのものだからである。SPKIでは発行者が即ち承認者(verifier)でもあるので、信頼という概念がない。これはSPKIの用語で「オーソライゼーション・ループ」と呼ばれており、オーソライゼーションが設計に深く関わっている。

ロボットCA

ロボットCAとは、公開鍵の正当性を特定の条件から自動的に検証し、その条件について有効性を証明するための署名を自動的に行う無人プログラムである。ロボットCAは公開鍵システムの攻撃者、特に合法なサイトからのすべてのネットワークトラフィックを一時転換する種の攻撃者を排除もしくは大いに抑制することができる。

1976年にディフィー（Whitfield Diffie)、ヘルマン（Martin Hellman）の両名によって発表された安全な鍵交換の仕組みであるDiffie-Hellman（DH)、そして1978年にロナルド・リベスト（Ron Rivest)、アディ・シャミア（Adi Shamir)、レオナルド・エーデルマン（Leonard Adleman）の3名によって発表された非対称鍵アルゴリズムであるRSAは、安全な通信について劇的な変化をもたらした。高速デジタル通信（インターネットやその前身）の更なる発展により、利用者がお互いに安全に通信できる方法や、更に利用者が実際に対話していた人を確認できる方法の必要性が明白になった。利用者の同一性を公開鍵に結び付ける、暗号的に保護された証明書のアイデアが精力的に研究された。

初期の暗号技術の中から効果的な使い方ができる組み合わせが発明および分析された。World Wide Web（WWW）の発明とその急速な普及と共に、認証（authentication）と安全な通信の必要性が更に深刻となった。（電子商取引や、Webブラウザから商用データベースへのオンラインアクセスなど）商用の理由だけで十分だった。ネットスケープコミュニケーションズ（Netscape Communications Corporation）のテヘール・エルガメル（Taher ElGamal）たちは、鍵の立証やサーバ認証（v3より前は片方向のみ）などを含む、Secure Sockets Layer（SSL）プロトコル（httpsプロトコル）を開発した。このようにPKIの構造はWebの利用者/サイトが望む（あるいはそれ以上の）安全な通信のために造られた

ベンダーや起業家が広大な市場の可能性を予測し、新しい会社や企業内プロジェクトを始め、責任からの保護と法的な承認について議論され始めた。米国弁護士協会（American Bar Association、ABA）のテクノロジ・プロジェクトはPKI運用に関して予測し得る法的な側面について広範囲に渡る分析を発表し（ABA digital signature guidelines（英語版） 参照）、その後間もなくして、（1995年の米国ユタ州を皮切りに）世界中のあらゆる国や自治体が、法律の制定および規則の採択をし始めた。消費者団体などは、プライバシー、アクセス、責任について、幾つかの地域では更に考慮するべきであるという問題を挙げた。

制定された法律や規則とは異なり、上手くいっている商取引にPKIの体系を組み込むには技術上や運用上の問題があり、またそれは先駆者が予想していたより遥かに進展が遅かった。

21世紀の初めの数年までには、基本的な暗号技術を正確に展開することは容易ではない事や、（手動または自動の）運用手順を正確に設計することは容易ではない事（もし技術的に完璧に実施するように設計したとしても）、そして定められた標準規格はそれらの目的のために尊重するには不十分なことが明確になった。

PKIベンダーは市場を造ったが、1990年代中頃には必ずしも思い描いていた物ではなく、ゆっくり、そして期待されていた物とは多少違った方向に成長していった。PKIは、期待されていた幾つかの問題は解決せず、いくつもの大手ベンダーが撤退したり他社に買収されることになった。PKI最大の成功は政府に採用されたことである。現時点における最大のPKI実装は、米国防衛情報システム局（Defense Information Systems Agency、DISA）PKI infrastructure for the Common Access Cards programである。

PKIはさまざまなベンダからさまざまな種類のものが提供され、さまざまな使用方法がある(公開鍵の配布、ユーザの個人情報の隠蔽など)。

• 文章の暗号化や認証 --- 文章がXMLであればXML署名やXML暗号化など。文章が電子メールであれば、OpenPGPやS/MIMEなど。
• ユーザー認証 --- スマートカードログオン、TLSによるクライアント認証など。
• 安全な通信プロトコルの初期セットアップ --- インターネット鍵交換（IKE）やTLSなど。 IKE、TLSともに初期セットアップ時は公開鍵暗号を用いるが、実際の通信は公開鍵暗号より速度が速い共通鍵暗号を用いる。

一部の主要な認証局（Verisignなど）は、他のソフトウェアが使用できないためここには記述していない。

• Red Hat Certificate System
• Computer Associates eTrust PKI
• Entrust
• マイクロソフト
• US Government External Certificate Authority (ECA)
• Nexus
• OpenCA（サーバソフトを含む公的に利用可能なPKIを目指すオープンソース運動）
• RSA Security
• phpki
• GenCerti
• ejbca
• newpki
• Papyrus CA Software
• pyCA
• IDX-PKI
• EuropePKI（休止中）
• TinyCA
• ElyCA
• SimpleCA
• SeguriData

• PKI 関連技術情報 独立行政法人情報処理推進機構 技術本部 セキュリティセンター(IPA ISEC)（脚注のIPA041等はこの資料の41頁を表す）

• 公開鍵暗号
• データ完全性

日本のサイト

• PKI関連技術解説（独立行政法人 情報処理推進機構）

海外のサイト

• PKI tutorial by Peter Gutmann
• PKIX workgroup
• Easing the PAIN^{[リンク切れ]} — a detailed explanation of PKI Privacy, Authentication, Integrity and Non-repudiation （PAIN）
• NIST PKI Program — in which the National Institute of Standards and Technology (NIST) is attempting to develop a public key infrastructure
• Mozilla Open Source PKI Projects
• NewPKI^{[リンク切れ]} — a PKI based on the OpenSSL low-level API

ロボットCA

• CAcert.org
• cardboard.net llc^{[リンク切れ]}
• Imperial Violet （Adam Langley）
• Toehold （Kyle Hasselbacher）^{[リンク切れ]}
• Thawte.com 123 SSL Certificates
• Geotrust QuickSSL Certificates
• Godaddy Turbo SSL Certificates