X.509

暗号において、X.509とは、ITU-Tの公開鍵基盤 (PKI)の規格である。X.509は、公開鍵証明書の標準形式や証明書パス検証アルゴリズム（英語版）などを定めている。

歴史と用法

X.509の第1版は、1988年 7月3日にX.500標準と関連して公開された。証明書を発行するための認証局（証明機関、Certificate authority、CA）の厳密な階層構造を規定している。PGPのような、特別な認証局だけではなく誰でも署名や他人の公開鍵の真正の確認ができるweb of trustモデルと対照的である。第2版は1994年に公開され、証明書の形式はv2となったが、ほとんど使用されていない。1997年の第3版で、証明書の形式がv3となり、証明書失効リストの形式がv2となった。2000年に第4版が公開され、標準拡張フィールドが 1 つ追加されたが、証明書や証明書失効リストの形式は第3版と同じである。X.509 v3の証明書は、ブリッジやメッシュネットワーク(RFC 4158)などの他のトポロジをサポートする柔軟性を備えている。OpenPGPのようなピアツーピア方式のweb of trustモデルもサポートしているが、2004年現在でもほとんど使われていない。X.500システムは今まで完全に実装されたことがない。

実際のところ、X.509証明書という言葉は大抵の場合IETFの RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（インターネットX.509 PKI：証明書と CRL のプロファイル）のことを指す。これを意味する用語として、PKIXも用いられる。PKIXは、RFC 5280の3. Overview of Approachにおいて、Public-Key Infrastructure using X.509の略として登場している^[1]。

証明書

X.509体系では、認証局は公開鍵を特定のX.500の識別名もしくはメールアドレスやDNS エントリのような別の名前に関連付ける証明書を発行する。

組織の信頼されたルート証明書は全従業員に配布可能であるため、従業員は社内PKIシステムを使うことができる。Internet Explorer, Netscape/Mozilla, Opera, Safariのようなブラウザはインストール済みのルート証明書とともに配布されるため、大手ベンダーから入手したSSL証明書はすぐに動作する。事実上、ブラウザの所有者が、どの認証局をブラウザのユーザーにとっての信頼できる第三者にするかを決定している。ルート証明書は削除することも無効にすることもできるが、ユーザーがそれを行うことは極めてまれである。

X.509は証明書失効リスト(CRL)実装に関する標準も含んでいる。証明書失効リストはPKIシステムのしばしば無視される側面のひとつである。IETFが承認している証明書の有効性の検証方法はOCSP（Online Certificate Status Protocol）である。Firefox 3ではOCSPによる検証はデフォルトで有効になっている。

証明書の構造

X.509 v3 デジタル証明書の構造は、次のとおり。

証明書
- バージョン
- 通し番号
- アルゴリズムID
- 発行者
- 有効期間
  - 開始
  - 満了
- 主体者
- 主体者の公開鍵情報
  - 公開鍵アルゴリズム
  - 主体者の公開鍵
- 発行者の一意な識別子 (予備)
- 主体者の一意な識別子 (予備)
- 拡張 (予備)
  - ...
証明書の署名アルゴリズム
証明書の署名

発行者、主体者の一意な識別子はVersion 2で、拡張はVersion 3で、導入された。

証明書ファイルの拡張子

一般的なX.509証明書の拡張子は、次のとおり。

.CER: 証明書をDER で符号化したもの^[2]^[3]。
.CRT: 証明書をPEM（英語版）形式で符号化したもの^[4]。
.DER: DER で符号化された証明書
.PEM: PEM形式。Base64 で符号化された証明書で、「-----BEGIN CERTIFICATE-----」と「-----END CERTIFICATE-----」で囲まれている。
.P7B: .p7c参照
.P7C: 被署名データのない PKCS#7 のSignedData構造で、証明書 (群) やCRL (群) がある
.PFX: .p12参照
.P12: (公開鍵や、パスワードで保護された) 私有鍵を含む PKCS#12

PKCS #7 は、データの署名や暗号化 (公式には「"enveloping"」) の標準である。証明書は、署名されたデータの検証に必要なので、SignedData構造に含めることができる。 .P7Cファイルは、署名されるべきデータをもたないという、縮退したSignedData構造である。

PFX (Personal inFormation eXchange) 標準から発展した PKCS #12 は、単一ファイルでの公開鍵と私有鍵の交換に使われる。

.PEMファイルは、証明書や私有鍵を含むことがあり、このときBEGINとEND (とCERTIFICATEやRSA PRIVATE KEYの組合せ) の行で囲まれている。

X.509証明書の例

以下の例はOpenSSLでデコードされた、www.freesoft.orgのX.509証明書である。実際の証明書のサイズは約1KBである。証明書は、発行者フィールドに記載されているとおり、Thawte（VeriSignに買収された）により発行された。主体者フィールドは多くの個別の情報を含んでいるが、最も重要な部分はcommon name (CN)である。これは認証されるホスト名と(ふつう大文字小文字の差を無視して)一致する必要がある。次にRSA公開鍵(法と公開指数)が含まれる。次にくるのは署名である。署名は証明書の最初の部分のMD5ハッシュをThawteのRSA秘密鍵によって暗号化することにより計算される。

Certificate:
   Data:
       Version: 1 (0x0)
       Serial Number: 7829 (0x1e95)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
               OU=Certification Services Division,
               CN=Thawte Server CA/emailAddress=server-certs@thawte.com
       Validity
           Not Before: Jul  9 16:04:02 1998 GMT
           Not After : Jul  9 16:04:02 1999 GMT
       Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
                OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
                   33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
                   66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
                   70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
                   16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
                   c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
                   8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
                   d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
                   e8:35:1c:9e:27:52:7e:41:8f
               Exponent: 65537 (0x10001)
   Signature Algorithm: md5WithRSAEncryption
       93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
       92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
       ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
       d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
       0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
       5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
       8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
       68:9f

この証明書を検証するには、この証明書の発行者(Thawteサーバー証明書発行局)にマッチする証明書が必要である。はじめに、検証者は2つ目の証明書が認証局のものである、すなわち他の証明書を発行するのに使用できることを検証する。この動作はX509v3 extensionセクションにあるCA属性の値を調べることによって行われる。次に、認証局の証明書から取得したRSA公開鍵が、最初の証明書の署名をデコードしてMD5ハッシュを得るために使用される。このMD5ハッシュは証明書の残りの部分から計算された実際のMD5ハッシュと一致しなければならない。以下は認証局の証明書である。

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number: 1 (0x1)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
               OU=Certification Services Division,
               CN=Thawte Server CA/emailAddress=server-certs@thawte.com
       Validity
           Not Before: Aug  1 00:00:00 1996 GMT
           Not After : Dec 31 23:59:59 2020 GMT
       Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
                OU=Certification Services Division,
                CN=Thawte Server CA/emailAddress=server-certs@thawte.com
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
                   68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
                   85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
                   6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
                   6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
                   29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
                   6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
                   5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
                   3a:c2:b5:66:22:12:d6:87:0d
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Basic Constraints: critical
               CA:TRUE
   Signature Algorithm: md5WithRSAEncryption
       07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
       a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
       3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
       4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
       8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
       e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
       b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
       70:47

これは自己署名証明書の例であり、発行者と主体者が同一である。この証明書を自分自身に対して検証する以外に、この証明書を検証する方法はない。代わりに、これらのトップレベル証明書はブラウザによって保持される。ThawteはマイクロソフトとNetscape両方に認められているルート証明書発行局の1つである。この証明書はウェブブラウザと一緒に出荷され、デフォルトで信頼される。この証明書は、X509v3 Basic Constraintsセクションに制約の無い、あらゆる物に署名できる長期的かつ世界的に信頼された証明書であるため、対になる秘密鍵は厳重に保護される必要がある。

セキュリティ

PKIの問題については数多くの出版物がある^[5]^[6]^[7]。

2005年、Arjen LenstraとBenne de Wegerは"公開鍵のみが異なる同一署名をもつ2つのX.509証明書を構築するためにハッシュ衝突を使用する方法"を公開した。MD5ハッシュ関数に対する衝突攻撃 (collision attack)を使用して達成している。[1]

認証局

→詳細は「認証局」を参照

認証局(CA, certificate authority, certification authority)は他者が使うためのデジタル証明書を発行するエンティティである。これは信頼できる第三者機関(TTP, Trusted Third Party)の一例である。認証局は多くの公開鍵基盤の特徴となっている。

これらのサービスを料金を取って行う商用の認証局が多く存在している。いくつかの団体や政府は独自の認証局を運営している。また、Let's Encryptのように無償の認証局もある。

公開鍵基盤 (X.509) ワーキング・グループ

公開鍵基盤 (X.509) ワーキング・グループ（PKIXワーキンググループ）はInternet Engineering Task Forceのワーキンググループである。X.509証明書に基づいた公開鍵基盤に関連するRFCを開発している。PKIXワーキング・グループは1995年の秋に設立された。

X.509証明書関連のプロトコル、標準

Transport Layer Security (TLS/SSL)
S/MIME
IPsec
SSH ‐ RFC 6187による拡張仕様
スマートカード
HTTPS
Extensible Authentication Protocol
LDAP
Trusted Computing Group (TNC TPM NGSCB)
CableLabs (North American Cable Industry Technology Forum)
WS-Security

参考文献

ITU-T Recommendation X.509 (2005): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, 08/05.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 3280, April 2002.
David Cooper, et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
Arjen Lenstra, Xiaoyun Wang and Benne de Weger, On the possibility of constructing meaningful hash collisions for public keys, full version, with an appendix on colliding X.509 certificates, 2005 [2] (see also [3]).

脚注

[脚注の使い方]

^ “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” (英語) (2008年5月). 2019年3月9日閲覧。 “Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications.”
^ "application/pkix-cert". Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP (英語). sec. 4.1. doi:10.17487/RFC2585. RFC 2585. 2022年2月12日閲覧。File extension(s): .CER
^ "Authority Information Access". Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (英語). sec. 4.2.2.1. doi:10.17487/RFC5280. RFC 5280. 2022年2月12日閲覧。HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585] in the content-type header field of the response for a single DER encoded certificate
^ "File Extension". Textual Encodings of PKIX, PKCS, and CMS Structures (英語). sec. 5.3. doi:10.17487/RFC7468. RFC 7468. 2022年2月12日閲覧。To promote interoperability and to separate DER encodings from textual encodings, the extension ".crt" SHOULD be used for the textual encoding of a certificate.
^ Carl Ellison; Bruce Schneier. “Top 10 PKI risks” (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). 2016年4月1日閲覧。
^ Peter Gutmann. “PKI: it's not dead, just resting”. IEEE Computer (Volume:35, Issue: 8). 2016年4月1日閲覧。
^ Gutmann, Peter. “Everything you Never Wanted to Know about PKI but were Forced to Find Out” (PDF). 14 November 2011閲覧。

外部リンク

RFC 5280
- インターネットX.509 PKI：証明書と CRL のプロファイル — IPAによる日本語訳
Peter GutmannのX.509スタイル・ガイド
PKIXのサイト

この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

[1] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” (英語) (2008年5月). 2019年3月9日閲覧。 “Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications.”

[2] "application/pkix-cert". Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP (英語). sec. 4.1. doi:10.17487/RFC2585. RFC 2585. 2022年2月12日閲覧。File extension(s): .CER

[3] "Authority Information Access". Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (英語). sec. 4.2.2.1. doi:10.17487/RFC5280. RFC 5280. 2022年2月12日閲覧。HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585] in the content-type header field of the response for a single DER encoded certificate

[4] "File Extension". Textual Encodings of PKIX, PKCS, and CMS Structures (英語). sec. 5.3. doi:10.17487/RFC7468. RFC 7468. 2022年2月12日閲覧。To promote interoperability and to separate DER encodings from textual encodings, the extension ".crt" SHOULD be used for the textual encoding of a certificate.

[schneier-5] Carl Ellison; Bruce Schneier. “Top 10 PKI risks” (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). 2016年4月1日閲覧。

[pkinotdead-6] Peter Gutmann. “PKI: it's not dead, just resting”. IEEE Computer (Volume:35, Issue: 8). 2016年4月1日閲覧。

[gutmann1-7] Gutmann, Peter. “Everything you Never Wanted to Know about PKI but were Forced to Find Out” (PDF). 14 November 2011閲覧。

[1]

[2]

[3]

[4]

[5]

[6]

[7]