X.509

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

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

歴史[編集]

X.509の第1版は、1988年7月3日X.500標準と関連して公開された。証明書を発行するための認証局(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証明書という言葉は大抵の場合IETFPublic Key Infrastructure (X.509)と証明書失効リストプロファイルのことを指す。これはRFC 5280 (RFC 2459RFC 3280を置き換えた) で規定されている。

証明書[編集]

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 - CER で符号化された証明書、ときによっては証明書群の列
  • .DER - DER で符号化された証明書
  • .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ファイルは、証明書や私有鍵を含むことがあり、このときBEGINEND (とCERTIFICATERSA PRIVATE KEYの組合せ) の行で囲まれている。

X.509証明書の例[編集]

以下の例はOpenSSLでデコードされた、www.freesoft.orgのX.509証明書である。実際の証明書のサイズは約1KBである。証明書は、発行者フィールドに記載されているとおり、ThawteVeriSignに買収された)により発行された。主体者フィールドは多くの個別の情報を含んでいるが、最も重要な部分は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セクションに制約の無い、あらゆる物に署名できる長期的かつ世界的に信頼された証明書であるため、対になる秘密鍵は厳重に保護される必要がある。

セキュリティー[編集]

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

認証局[編集]

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

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

公開鍵インフラ (X.509) ワーキング・グループ[編集]

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

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

参考文献[編集]

  • [ITU-T Recommendation X.509][2] (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 [3] (see also [4]).

関連項目[編集]

外部リンク[編集]