インターネットの普及に伴い公開鍵暗号方式は必須の技術となってきた。公開鍵暗号方式を利用する際には、暗号化・署名の検証などを行うために事前に正しい公開鍵が配布されていることが前提となる。
少数の限られた範囲内での利用であれば、直接対面などの手段により安全に公開鍵を流布することが可能であるが、インターネットのような多数で広範囲に渡る通信においては不可能である。
そこで個人、 組織、 サーバに対する公開鍵の正当性を保証する信用のおける第3者機関 (trusted third party) である認証局 (Certificate Authority) という概念が生まれた。
認証局では利用者と公開鍵の対を認証局(の秘密鍵)によるデジタル署名した「公開鍵証明書」を発行する。公開鍵証明書を検証する側では公開鍵証明書の(認証局による)署名を検証して、公開鍵が正当なものであるかどうか確認することができる。
公開鍵証明書は認証書、 証明証などと呼ばれることがある。
このようなしくみを実現した公開鍵証明書の規格の1つに X.509 がある。X.509 は ITU (International Telecommunication Union) や ISO (International Organization for Standardization) で標準化されており、ディレクトリに関する一連の規格である X.500 シリーズの1つに該当する。
そのためエンティティを識別するために X.500 に基づいた名前空間(X.500 識別名)を利用するのが特徴である。
その他の公開鍵証明書フォーマットとしては SPKI (Simple Public Key Infrastructure) や SDSI (Simple Distributed Security Infrastructure) などが存在するが、S/MIMEやSSLなどの多くのセキュリティプロトコルが X.509 をベースにしているためデファクトスタンダードとなっている。
X.509 公開鍵証明書は複数のバージョンがある。1988 年に公開されたバージョン1は基本的な必須項目が定義され、1993 年に公開されたバージョン2ではエンティティの一意性を表わすためのオプショナルな固有識別子が追加された。
更に 1996 年にはさまざまな情報を埋め込めることのできる追加領域を定義したバージョン3が発行されている。現在はこの X.509 v3 公開鍵証明書はよく利用されている。
X.509 は ASN.1 (Abstract Syntax Notation One) と呼ばれる表記法で定義されている。通常 X.509 証明書を保持する際には DER (Distinguished Encoding Rules) と呼ばれるコーディング規則にのっとってエンコーディングされたものを利用する。
図 1 X.509 v3 フォーマット
それぞれのフィールドに表示される情報を説明する。(図 1 X.509 v3 フォーマット)
version は X.509 のバージョンが入る。このフィールドはオプショナルであり、省略された場合は v1 を表す。
serialNumber は認証局がユニークに割り当てるシリアル番号が入る。後述する CRL で利用される。
signature は公開鍵証明書の署名方式が入る。
issuer は公開鍵証明書の発行者である認証局の X.500 識別名が入る。
validity は公開鍵の有効期限(開始日時と終了日時)が入る。
subject は本証明書内に含まれる公開鍵に対応する秘密鍵の所有者の X.500 識別名が入る。
subjectPublicKeyInfo は証明する公開鍵が入る。
issuerUniqueIdentifier 及び subjectUniqueIdentifier は v2 から追加されたオプショナルなフィールドであり、それぞれ認証局の固有識別子,所有者の固有識別子が入る。
extensions は v3 で追加されたオプショナルなフィールドであり、拡張型 (extnId)、拡張値 (extnValue) 及びクリティカルビット (critical) の3つ組の集合が入る。
X.509 で定められた拡張型には keyUsage (公開鍵の利用目的), subjectAltName (所有者の別名), basicConstrains (認証局かどうかを記入) などがある。
v3 拡張フィールドは X.509 で定められた標準の拡張型だけでなく、独自の新しい拡張型も組み込むことが可能である。
そのため v3 拡張型をどう認識するかはアプリケーション側に依存することとなる。クリティカルビットはその拡張型が必須であるかまたは無視可能かを表わすものである。
X.509 では公開鍵証明書だけではなく廃棄証明書リスト (CRL, Certificate Revocation List) のフォーマット(図 2 CRL v2 フォーマット)も定義されている。X.500 識別名の変更や秘密鍵の漏洩などの理由により公開鍵証明書を通常の有効期限内で無効にする機構を実現する。
CRL には v1 と v2 の2つのバージョンが存在する。v2 では CRL の配布場所や廃棄証明書ごとの廃棄理由などを埋め込むことができるようになった。
図 2 CRL v2 フォーマット
それぞれのフィールドに表示される情報を説明する。(図 2 CRL v2 フォーマット)
version は CRL のバージョンが入る。v1 ではこのフィールドは定義されていないため存在すれば v2 である。
・
signatureはCRLの署名方式が入る。
・
issuerはCRLの発行者のX.500 識別名が入る。
・
thisUpdateは本CRLの発行日時が入る。
・
nextUpdateはオプショナルなフィールドであり、次回のCRL発行予定の日時が入る。
・
revokedCertificatesは廃棄する証明書のシリアル番号 (userCertificate) と廃棄日時(revocationDate)の対の集合が入る。
・
更にオプションで各組に対して拡張情報(crlEntryExtensions)を入れることができる。
例えば ・・・・ CRLReason 拡張型は廃棄理由が入る。
・
crlExtensionsはオプショナルなフィールドであり CRL に対する拡張が入る。
cRLNumber (CRL の発行通し番号)、cRLDistributionPoints (CRLの配布場所や扱うCRLLの種類などが入る) などがこれにあたる。
また X.509 では属性証明書 (Attribute Certificate) と呼ばれる公開鍵証明書に類似したフォーマットも定義されている。
公開鍵証明書が公開鍵とその利用者を結びつけるしくみを提供するのに対し、属性証明書は所持者の属性や権限をあらわす証明書であり、属性情報を公開鍵証明書と結び付ける役割を持つ。
現在も標準化が進められている X.509 v3 拡張に対する FPDAM (Proposed Draft Amendment) では X.509 属性証明書に関する部分で大幅な改変が行われており、属性証明書のフォーマットだけでなく各フィールドの詳細やモデルについても触れられている。なおこのドキュメントが正式な形で公開されるのは 2000 年 3 月の予定である。
IETF では PKIX Working Group で X.509 公開鍵証明書を用いた公開鍵インフラの標準化作業が進行中である。1999 年 1 月に RFC Standard Trackとして RFC 2459 が公開されたほか現在の多くのドラフトが標準化の最終段階に入っている。
RFC 2459 では X.509 公開鍵証明書と CRL のプロファイルが紹介されているだけでなく PKIX WG 独自の拡張型も定義されている。そのほかにもマネージメントプロトコル、オンライン有効性確認プロトコル (Online Certificate Status Protocol) などの標準化が行われている。