コンテンツにスキップ

「X.509」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集
削除された内容 追加された内容
ビジュアルウィキテキスト
→‎証明書: 長らく出典を示すことができない記述を除去しました。
m 外部リンクの修正 RFC -> {{IETF RFC}} (Botによる編集)
 
(13人の利用者による、間の28版が非表示)
1行目: 1行目:
[[暗号]]において、'''X.509'''とは、[[ITU-T]]の[[公開鍵基盤|PKI]]の規格である。X.509は、[[公開鍵証明書]]の標準形式や[http://en.wikipedia.org/wiki/Certification_path_validation_algorithm 証明書パス検証アルゴリズム]などを定めている。
{{インターネットセキュリティプロトコル}}[[暗号]]において、'''X.509'''とは、[[ITU-T]]の[[公開鍵基盤]] (PKI)の規格である。X.509は、[[公開鍵証明書]]の標準形式や{{仮リンク|証明書パス検証アルゴリズム|en|Certification path validation algorithm}}などを定めている。


==歴史==
==歴史と用法==


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

実際のところ、''X.509証明書''という言葉は大抵の場合[[IETF]]の {{IETF RFC|5280}} Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（[https://web.archive.org/web/20190306043432/https://www.ipa.go.jp/security/rfc/RFC5280-00JA.html インターネットX.509 PKI： 証明書と CRL のプロファイル]）のことを指す。これを意味する用語として、'''PKIX'''も用いられる。PKIXは、{{IETF RFC|5280}}の3. Overview of Approachにおいて、Public-Key Infrastructure using X.509の略として登場している<ref>{{Cite web |url=https://datatracker.ietf.org/doc/html/rfc5280 |title=Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |accessdate=2019-03-09 |year=2008 |month=May |quote=Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications. |language=英語}}</ref>。


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


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


X.509は[[証明書失効リスト]](CRL)実装に関する標準も含んでいる。[[証明書失効リスト]]はPKIシステムのしばしば無視される側面のひとつである。[[IETF]]が承認している証明書の有効性の検証方法はOCSP（[[Online Certificate Status Protocol]]）である。Firefox 3ではOCSPによる検証はデフォルトで有効になっている。
X.509は[[証明書失効リスト]](CRL)実装に関する標準も含んでいる。[[証明書失効リスト]]はPKIシステムのしばしば無視される側面のひとつである。[[IETF]]が承認している証明書の有効性の検証方法はOCSP（[[Online Certificate Status Protocol]]）である。Firefox 3ではOCSPによる検証はデフォルトで有効になっている。
37行目: 39行目:
=== 証明書ファイルの拡張子 ===
=== 証明書ファイルの拡張子 ===
一般的なX.509証明書の拡張子は、次のとおり。
一般的なX.509証明書の拡張子は、次のとおり。
; <tt>.CER</tt>
* <tt>.CER</tt> - [[Canonical Encoding Rules|CER]] で符号化された証明書、ときによっては証明書群の列
* <tt>.DER</tt> - [[DER]] で符号化された証明書
: 証明書を[[Distinguished Encoding Rules|DER]] で符号化したもの<ref>{{Cite IETF
| title=Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
⚫
* <tt>.PEM</tt> - [[Base64]] で符号化された証明書で、「<tt>-----BEGIN CERTIFICATE-----</tt>」と「<tt>-----END CERTIFICATE-----</tt>」で囲まれている
| rfc=2585
⚫
* <tt>.P7B</tt> - <tt>.p7c</tt>参照
| section=4.1
⚫
* <tt>.P7C</tt> - 被署名データのない [[PKCS|PKCS#7]] のSignedData構造で、証明書 (群) やCRL (群) がある
| sectionname=application/pkix-cert
⚫
* <tt>.PFX</tt> - <tt>.p12</tt>参照
| access-date=2022-02-12
⚫
* <tt>.P12</tt> - (公開鍵や、パスワードで保護された) 私有鍵を含む [[PKCS|PKCS#12]]
| quote=File extension(s): .CER
}}</ref><ref>{{Cite IETF
| title=Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
| rfc=5280
| section=4.2.2.1
| sectionname=Authority Information Access
| access-date=2022-02-12
| quote=HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert <nowiki>[RFC2585]</nowiki> in the content-type header field of the response for a single DER encoded certificate
}}</ref>。
; <tt>.CRT</tt>
: 証明書を{{仮リンク|Privacy-Enhanced Mail|en|Privacy-Enhanced Mail|label=PEM}}形式で符号化したもの<ref>{{Cite IETF
| title=Textual Encodings of PKIX, PKCS, and CMS Structures
| rfc=7468
| section=5.3
| sectionname=File Extension
| access-date=2022-02-12
| quote=To promote interoperability and to separate DER encodings from textual encodings, the extension ".crt" SHOULD be used for the textual encoding of a certificate.
}}</ref>。
; <tt>.DER</tt>
: DER で符号化された証明書
; <tt>.PEM</tt>
⚫
: PEM形式。[[Base64]] で符号化された証明書で、「<tt>-----BEGIN CERTIFICATE-----</tt>」と「<tt>-----END CERTIFICATE-----</tt>」で囲まれている。
; <tt>.P7B</tt>
⚫
: <tt>.p7c</tt>参照
; <tt>.P7C</tt>
⚫
: 被署名データのない [[PKCS|PKCS#7]] のSignedData構造で、証明書 (群) やCRL (群) がある
; <tt>.PFX</tt>
⚫
: <tt>.p12</tt>参照
; <tt>.P12</tt>
⚫
: (公開鍵や、パスワードで保護された) 私有鍵を含む [[PKCS|PKCS#12]]


[[PKCS]] #7 は、データの署名や暗号化 (公式には「"enveloping"」) の標準である。
[[PKCS]] #7 は、データの署名や暗号化 (公式には「"enveloping"」) の標準である。
55行目: 87行目:
==X.509証明書の例==
==X.509証明書の例==


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


Certificate:
Certificate:
141行目: 173行目:
{{sectstub}}
{{sectstub}}


==セキュリティー==
==セキュリティ==


PKIの問題については数多くの出版物がある<ref name="schneier">
⚫
2005年、[[Arjen Lenstra]]と[[Benne de Weger]]は"公開鍵のみが異なる同一署名をもつ2つのX.509証明書を構築するためにハッシュ衝突を使用する方法"を公開した。[[MD5]]ハッシュ関数に対する[[衝突攻撃|collision attack]]を使用して達成している。[http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf]
{{cite web
| url = https://www.schneier.com/paper-pki.pdf
| title = Top 10 PKI risks | format=PDF
| author = Carl Ellison |coauthors= Bruce Schneier
| publisher = Computer Security Journal (Volume XVI, Number 1, 2000) | accessdate=2016-04-01
}}
</ref><ref name="pkinotdead">
{{cite web
⚫
| url = http://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.pdf
| title = PKI: it's not dead, just resting
| author = Peter Gutmann
| publisher = IEEE Computer (Volume:35, Issue: 8)| accessdate=2016-04-01
}}
</ref><ref name="gutmann1">
{{cite web
|last=Gutmann
|first=Peter
|title=Everything you Never Wanted to Know about PKI but were Forced to Find Out | format=PDF
|url=http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf|accessdate=14 November 2011
}}
</ref>。

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


==認証局==
==認証局==
149行目: 204行目:
{{main|認証局}}
{{main|認証局}}


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


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


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


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


{{sectstub}}
{{sectstub}}
169行目: 224行目:
* [[Lightweight Directory Access Protocol|LDAP]]
* [[Lightweight Directory Access Protocol|LDAP]]
* [https://www.trustedcomputinggroup.org/faq/TNCFAQ/ Trusted Computing Group] (TNC TPM NGSCB)
* [https://www.trustedcomputinggroup.org/faq/TNCFAQ/ Trusted Computing Group] (TNC TPM NGSCB)
* [http://www.cablelabs.com/ CableLabs] (North American Cable Industry Technology Forum)
* [https://www.cablelabs.com/ CableLabs] (North American Cable Industry Technology Forum)
* [[WS-Security]]
* [[WS-Security]]
{{sectstub}}
{{sectstub}}


==参考文献==
==参考文献==
* [ITU-T Recommendation X.509][http://www.itu.int/rec/T-REC-X.509-200508-I] (2005): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, 08/05.
* [http://www.itu.int/rec/T-REC-X.509-200508-I 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", {{IETF 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.
* Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", {{IETF 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.
* David Cooper, et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", {{IETF 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 [http://www.win.tue.nl/~bdeweger/CollidingCertificates/] (see also [http://eprint.iacr.org/2005/067]).
* 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 [https://www.win.tue.nl/~bdeweger/CollidingCertificates/] (see also [https://eprint.iacr.org/2005/067]).


== 関連項目 ==
== 関連項目 ==
187行目: 242行目:
* [[認証局]] (CA)
* [[認証局]] (CA)
* [[Pretty Good Privacy]] (PGP)
* [[Pretty Good Privacy]] (PGP)
* [http://en.wikipedia.org/wiki/Certificate_Policy 証明書ポリシー]
* [[:en:Certificate_Policy|証明書ポリシー]]
* [[OCSP|オンライン証明書検証プロトコル]] (OCSP)
* [[OCSP|オンライン証明書検証プロトコル]] (OCSP)
* [[証明書失効リスト|CRL]]
* [[証明書失効リスト|CRL]]

==脚注==
{{脚注ヘルプ}}
{{Reflist|30em}}


==外部リンク==
==外部リンク==
* {{IETF RFC|5280}}
⚫
* Peter Gutmannの [http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt X.509スタイル・ガイド]
** [https://web.archive.org/web/20190306043432/https://www.ipa.go.jp/security/rfc/RFC5280-00JA.html インターネットX.509 PKI： 証明書と CRL のプロファイル] — [[情報処理推進機構|IPA]]による日本語訳
⚫
* [http://www.ietf.org/html.charters/pkix-charter.html PKIXのサイト]
* Peter Gutmannの[https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt X.509スタイル・ガイド]
* [http://www.cacert.org CAcert.org - 無料のデジタル証明書]
⚫
* [https://datatracker.ietf.org/group/pkix/about/ PKIXのサイト]


{{Computer-stub}}
{{Computer-stub}}
{{SSL/TLS}}

[[Category:暗号技術]]
[[Category:X.500]]
[[Category:ITU]]
[[Category:公開鍵基盤]]
[[Category:ITU-T勧告]]
[[Category:暗号化プロトコル]]

2023年11月5日 (日) 18:30時点における最新版

インターネットセキュリティ
プロトコル
キーマネジメント
アプリケーション層
DNS
インターネット層

暗号において、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/[email protected]
       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/[email protected]
       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/[email protected]
       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/[email protected]
       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証明書関連のプロトコル、標準

[編集]

参考文献

[編集]
  • 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]).

関連項目

[編集]

脚注

[編集]
[脚注の使い方]
  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.
  5. ^ Carl Ellison; Bruce Schneier. “Top 10 PKI risks” (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). 2016年4月1日閲覧。
  6. ^ Peter Gutmann. “PKI: it's not dead, just resting”. IEEE Computer (Volume:35, Issue: 8). 2016年4月1日閲覧。
  7. ^ Gutmann, Peter. “Everything you Never Wanted to Know about PKI but were Forced to Find Out” (PDF). 14 November 2011閲覧。

外部リンク

[編集]
スタブアイコン

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

プロトコル
技術
歴史
実装
公証
脆弱性
理論
暗号
プロトコル
実装
「https://ja.wikipedia.org/w/index.php?title=X.509&oldid=97769738」から取得