IYASコミュニケーションフィールディングス

トップ

− 研究レポート −

 

件 名 オブジェクト識別子(OID)に関する情報の収集 (No.1)
公開日 2017-06-09
更新日 2017-06-11 (2)

 

OIDの概要

 OID:Obejct IDentifier(日本名:オブジェクト識別子)は、オブジェクト(1つの何らかのデータ)と一対一で付番される世界的にユニーク(重複しない)な識別番号です。OIDには、RFCなどの標準で定められていて、正しい用途には誰でも任意に使用できるOIDもあれば、プライベートOIDとしてその組織が専用で使用するOIDもあります。

 IPv4のプライベートIPアドレスのような、一定のフリーな領域というものが、OIDにはありませんので、OIDが必要となった場合、発行機関に取得を申請し、配分を受ける必要があります。架空のOIDは使ってはいけません

 OIDは、オブジェクトと一対一で付番される世界的なユニークな識別番号というだけで、その用途は多彩です。一般的な用途としては、SNMPのMIBとPKI(公開鍵基盤/電子証明書)関係で見かけることが多いと思います。 

 OIDに関する標準文書は、ITU(国際電気通信連合、日本も加盟)のITU-T Rec X.660で、昨今皆様ご存知の有名なISO側ではISO 9834-1:2012にて共同で標準化されています。2つの標準化団体が相互運用しているため、OIDには、ITU系(0から始まる)とISO系(1から始まる)、ITUとISOの共同運用(2から始まる)の3種類がありますが、通常、PKIやSNMPなどのプライベートOIDとして利用する分についてその違いを考慮する必要はありません。

 OIDは、1.3.6.1.4.1.99999.1.2.3.4のようなドット区切りの数字の集合体で、ツリー構造(パソコンのフォルダやドメイン名のような感じです)で管理されています。ドメイン名との違いは、一番左(レベル1)が最上位で右に進んでいくと下位となっていきます。先述しているOIDは、IANAが再配分しているもので、1.3.6.1.4.1がIANA(厳密には、「iso.org.dod.internet.private.enterprise」)を示し、99999の部分が再配分組織に与えられる個別番号となります。

 OIDには、10進数の整数数値と、レベル(ツリー)を区切る.(ドット)のみが使用できます。各レベル内の桁数の規定はありません。

 数字の羅列では人間が識別しにくいとのことから、セカンドレベル識別子として、アルファベットを用いた以下のような形:

       1 = iso (ISO管理)
       3 = identified-organization 注:orgと短縮可 (ISO/IEC 6523-2に基づき、Farance, Incが管理)
       6 = dod (Defense Communication Agency 米国防総省 管理)
       1 = internet (RFCに基づき、IANAが管理 *注1
       4 = private (IANA管理)
       1 = enterprise (IANA管理)

      「1.3.6.1.4.1」=「iso.org.dod.internet.private.enterprise」
      合体した表現=「iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1)」

にて、表記されることもあります。

 個別番号よりさらに最下位(1.2.3.4の部分)は、再配分を受けた組織が自由に利用できます。番号の構成方法や桁数、更に最下位のレベルの追加など、すべて自由です。配分した組織が禁じていなければ、基本的には、更に自身が再配分することもできます。

 

OIDの取得方法

 OIDは、すでに配分を受けている組織等からの再配分を受ける形で、取得することが可能です。

 割り当ての条件や手数料、利用方法などは、再配分を行う組織等が定めています。

 OIDには、ITU系(0から始まる)、ISO系(1から始まる)、ITU-ISO合体(2から始まる)の3種類がありますが、前述のとおり通常、PKIやSNMPなどのプライベートOIDとして利用する分についてその違いを考慮する必要はありません。

 OIDのルールとして、全ての取得先を通じて、1組織に1つのみというルールがあります。例えば、IANAでOIDの指定を受けたら、総務省やJIPDECなど他の組織からOIDの指定を受けてはいけないということですので、何らかの理由によりOIDの取得を求められて取得する場合など、用途によっては、使用できるOIDに制限を設けている可能性もありますので、注意が必要です。

 以下に、日本からの申請で代表的な発行機関を紹介します。

 取得先1:IANA (Prefix : 1.3.6.1.4.1.*****) ISO系

IANAは、インターネットの資源(IPアドレス、ドメイン名、ポート番号、RFC等)の管理や割り当てを行っている、インターネットの中枢組織です。申請者の国籍や所属に関係なく、申請を受け付けており、費用もかかりません。WEBのみで申請から再配分まで完了しますが、審査は人手ですのでポンとオンラインですぐに再配分されるわけではありません。日本の大手企業(NTT、富士通)や大手PKI(comodo、Cybertrust等)の取得例もあり、また、前述のとおり世界的な組織で信頼性も十分あり、OIDの一番メジャーな取得先です。全て英語で対応する必要があります。
   申請URL → http://pen.iana.org/pen/PenApplication.page

   取得者リスト → https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

 取得先2:日本国総務省 (Prefix : 0.2.440.*****) ITU系

日本政府が公式にOIDの再配分を行っています。日本において登記されている組織、国(地方公共団体)、個人の集まり(人格なき社団)に対して、再配分を受け付けています。費用はかかりませんが、政府への申請とあって、申請書の書面提出や割り当ての基準などが色々と面倒です。しかし、政府からの再配分とあって、当然信頼度は高いものですが、OIDそのものに特に身元保証などはありませんから、総務省からOID取得できたそれなりの組織だなという程度です。
   申請情報 → http://www.soumu.go.jp/main_sosiki/joho_tsusin/hyojun/object.html

 取得先3:JIPDEC (Prefix : 1.2.392.*****) ISO系

日本情報経済社会推進協会が、JISC(日本工業標準調査会)からの委任によりOIDの再配分を行っています。発行対象は総務省とほぼ同じです。日本の大手企業の取得例(ソニー等)もありますが、新規登録及び定期更新に手数料が必要ですので、通常はお選びにならないと思いますが参考までに。
   申請情報 → https://www.jipdec.or.jp/project/OSI_Object.html

 その他、特定の業種向けて、再配分を行っている団体等あります。特定の用途に使用する場合、それらの団体からの取得でシステム構築を含めた一括したサポートを受けられるなどの利点があるかと思います。前述のとおり、1組織1つの原則がありますので、申請先を十分に吟味してください。

 

PKIで使用されるOIDの例

 PKI(公開鍵基盤)において、OIDはその証明書の内容を示すキーとして利用されています。PKI用ソフトウェアなどでは基本的に名称を設定すれば自動的に対応するOIDが使用されますので、ほとんど目にすることはないかと思います。

 ユニークなOIDを使用することにより、PKIというインターネットの信用を世界的に支えているシステムで、デジタル証明書の内容を世界的に共通正確に把握でき、PKIシステムは、OIDを正確に理解すれば正しい認証を行えるということです。

 以下のようなOIDは、定められた用途で使用する場合、自身のPKIシステムにおいて申請等不要で自由に利用できます。このOIDを使用するとPKIに準拠しているシステムやソフトウェアでは共通して右記の内容と解釈され、必要な確認、処理が行われます。

例)
1.3.6.1.5.5.7.48.1    = AIA(機関情報アクセス)/OCSP(オンライン証明書状態プロトコル)

1.3.6.1.5.5.7.48.2    = AIA(機関情報アクセス)/AM(証明機関の発行者)
2.5.29.32.0        = CP(証明書ポリシー)/PI(ポリシーID)/すべての発行ポリシー
2.23.140.1.2.3      = CP(証明書ポリシー)/PI(ポリシーID)/個人認証
2.23.140.1.2.2      = CP(証明書ポリシー)/PI(ポリシーID)/企業認証
2.23.140.1.2.1      = CP(証明書ポリシー)/PI(ポリシーID)/ドメイン認証
1.2.840.113549.1.1.11 = sha256WithRSAEncryption
1.2.840.113549.1.1.5  = SHA-1 with RSA Encryption

 次のようなOIDは、専用のプライベートなOIDなので他者が流用することができません。

例)
1.3.6.1.4.1.6449.1.2.1.1.1 = comodo社発行の電子証明書のCPS
判断理由:IANAによりCOMODO社に再配分されたOIDで、CPSという極めてプライベートなオブジェクトに関連付けされていますので、他者が流用するのは望ましくありません。

 PKIを構築する場合などに、既に発行されいているメジャーなCAの証明書を参考にまねて作成してみるというようなこともあるかと思いますが、その場合には、間違ってもプライベートOIDのデータを流用しないように、OIDは意味をしっかり理解して利用することが大切です。

 

 

 

SNMPで使用されるOIDの例

 SNMPで使用されるOIDは、OIDと値が一対一で定義されており、該当するOIDを指定することにより装置が保持しているデータを得ることができます。これは、ネットワーク機器の監視に利用されるもので、OIDは、装置のデータを得るためのキーという役割を果たしています。

1.標準MIB-2

  1.3.6.1.2.1.(.iso.org.dod.internet.mgmt.mib-2)のプレフィックスを持つSNMPのオブジェクトを規定しているOIDです。RFC(インターネット標準)にて規定されているため、各メーカー共通で利用できる基本的なMIBです。機器がサポートしていれば、流用しても利用可能な可能性が高いですが、実装が強制されている訳ではありませんから、使えない場合もあります。
 独自にSNMPを設計する際、規定されているOIDとデータ内容が一致するものであれば自由に利用できます。

 例)
 .1.3.6.1.2.1.1.3 = システム稼働時間
 .1.3.6.1.2.1.1.5 = システム名称

2.プライベートMIB

 ネットワーク機器を製造しているメーカーなどが保有する自社のOIDで独自のSNMPオブジェクトを規定しているOIDです。一見同じ監視項目でもメーカーごとにOIDが異なるため、流用しても利用できません。前述しているMIB-2で規定されていないオブジェクトをメーカーが独自に規定する場合に使用されます。
 下記の通り、一般的と思いがちな装置の温度やCPUの使用率といった項目も、プライベートMIBで管理されていることがあり、複数メーカーの装置監視を設定する場合などには、注意が必要です。
 独自にSNMP対応装置を設計する場合で、標準MIBに規定されていないデータ内容を取得できるようにする場合、前述のとおりOIDの取得申請が必要となります。

 例)
 .1.3.6.1.4.1.119.2 = NEC-MIB
 .1.3.6.1.4.1.119.2.3.84.2.1.1 = 装置の温度
 .1.3.6.1.4.1.119.2.3.84.2.5.2 = CPU使用率(5秒平均)

 

総評

 

 OIDを理解する上でまず理解し難かったのが、ほぼ関連性のないPKIとSNMPが同じOIDという値で管理されていて、また、どちらにも標準規定OIDとプライベートOIDがあるという構造が、その理解を困難にしています。

 今回まとめてみると、OIDは「ただの特定のデータを示すための値」と割り切って考え、規定されているOIDがないから自分でOIDを作りたい!って思ったらOIDの取得を申請して、プライベートOID配分を受ける。配分を受けた部分は自由に付番できるから、PKIでもSMNPでもその他それらの混合などでも、自分がさらに配分してもなんでもOK。と考えたら、結構柔軟なシステムなんだと感心しました。

 

注1: RFC1065(1988年)により、

原文:「As of this writing, the DoD has not indicated how it will manage its subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will allocate a node to the Internet community, to be administered by the Internet Activities Board (IAB) as follows:」

参考訳:「今日現在、DoD(米国防総省)はどのようにOBJECT IDENTIFIERsの下位ツリー(ノード)を配分するかを示していません。 このRFCは、DoDがインターネットActivities Board(IAB)にノードの管理を委任して、インターネットコミュニティに配分すると仮定します:」

と、仮定で示されたものが、DoDからの配分承認がされないまま事実上多数利用されている現状を、RFC1065によりハイジャックされたと表現されている場合があります。現在、RFC上ではRFC3232によりIANAに管理権限が委任され、IANAの管理のもと、多数のインターネットコミュニティにより利用されていますが、今日現在でもDoDは公式には承認も拒絶も表明していない(黙認)ようです。ただし、DoDは、別の国別OID(2.16.840.1.101.2)の方を利用しているようで、将来的には完全にIANAに譲渡されるなどの動きがあるかもしれません。

まだインターネットが世の中に出ていない時代に、OIDが規定されてすぐにこの強引なRFCを起草したエディターとそれをゴリ押しで使ったインターネットコミュニティの人々が、歴史的に利用をしているOIDのようです。

 

Copyright (C) IYAS Communication Fieldings , All Rights Reserved.
このページは著作権法により保護されています。
法律に別段の定めがある場合を除くほか、複写・引用・転載などの行為は固くお断り致します。