X.509

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

1. 歴史と用法
--------

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

実際のところ、//X.509証明書//という言葉は大抵の場合IETFの RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List  Profileのことを指す。これを意味する用語として、PKIXも用いられる。PKIXは、RFC 5280の3. Overview of Approachにおいて、Public-Key Infrastructure using X.509の略として登場している。

2. 証明書
------

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

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

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

2.1. 証明書の構造
-----------

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

証明書
バージョン
通し番号
アルゴリズムID
発行者
有効期間
開始
満了
主体者
主体者の公開鍵情報
公開鍵アルゴリズム
主体者の公開鍵
発行者の一意な識別子 
主体者の一意な識別子 
拡張 
...
証明書の署名アルゴリズム
証明書の署名発行者、主体者の一意な識別子はVersion 2で、拡張はVersion 3で、導入された。

2.2. 証明書ファイルの拡張子
----------------

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

.CER 証明書をDER で符号化したもの。 .CRT 証明書をPrivacy-Enhanced Mail形式で符号化したもの。 .DER DER で符号化された証明書 .PEM PEM形式。Base64 で符号化された証明書で、「-----BEGIN CERTIFICATE-----」と「-----END CERTIFICATE-----」で囲まれている。 .P7B .p7c参照 .P7C 被署名データのない PKCS#7 のSignedData構造で、証明書  やCRL  がある .PFX .p12参照 .P12  私有鍵を含む PKCS#12PKCS #7 は、データの署名や暗号化  の標準である。 証明書は、署名されたデータの検証に必要なので、SignedData構造に含めることができる。.P7Cファイルは、署名されるべきデータをもたないという、縮退したSignedData構造である。

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

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

3. X.509証明書の例
-------------

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

Certificate: Data: Version: 1  Serial Number: 7829  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:  Modulus : 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
 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

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

Certificate: Data: Version: 3  Serial Number: 1  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.comSubject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key:  Modulus : 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  X509v3 extensions: X509v3 Basic Constraints: criticalCA: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セクションに制約の無い、あらゆる物に署名できる長期的かつ世界的に信頼された証明書であるため、対になる秘密鍵は厳重に保護される必要がある。

4. セキュリティ
---------

PKIの問題については数多くの出版物がある。

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

5. 認証局
------

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

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

6. 公開鍵基盤  ワーキング・グループ
---------------------------

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

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

Transport Layer Security 
S/MIME
IPsec
SSH
スマートカード
HTTPS
Extensible Authentication Protocol
LDAP
[2] 
[3] 
WS-Security

8. 参考文献
-------

[4] : 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", 2459}}, January 1999.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", 3280}}, April 2002.
David Cooper, et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List  Profile", 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 [5] .

9. 関連項目
-------

デジタル証明書
デジタル署名
公開鍵
公開鍵基盤 
認証局 
Pretty Good Privacy 
証明書ポリシー
オンライン証明書検証プロトコル 
CRL

10. 脚注
------

11. 外部リンク
---------

[7] — IPAによる日本語訳
Peter Gutmannの[8]
[9]