ネットワークを介て情報通信を行う際には、その当事者同士が、誰と、どのようなプロトコルで、何を渡すかについて、通信の最初に交換して共有する必要がある。このように共有すべき一連の情報、定義、仕様等が「オブジェクト」と呼ばれる。このような文脈の「オブジェクト」について、国際的に一意に識別できるようにするために、全世界で固有な値が登録・管理されている[4] 。これが、オブジェクトID（オブジェクト識別子：Object Identifier）と呼ばれており、様々な規格がオブジェクトIDとして指されるようになっている。このようなオブジェクトIDのリポジトリは、今日、インターネット上で参照することができる¹。
 　オブジェクトIDは、ツリー構造の採番体系になっており、ルートの直下には、下記のようにISOとITU-Tの両標準化機関と共に、両機関の合同が分岐している。

•  　itu-t (0) 　　：ITU-T
•  　iso (1)　 　　：ISOおよびISO/IEC
•  　joint (2) 　　：合同

 　概ね、国コードのもとに企業コードが登録されるようなディレクトリ構造になっているといえる[5]。 具体的には、わが国においては、企業コード等の登録・管理は、次世代EDI推進協議会（JEDIC）においても行われている²。
 　暗号アルゴリズムを応用するセキュアプロトコルの仕様においても、暗号アルゴリズムIDはオブジェクトIDとして登録される。このオブジェクトIDが、セキュアプロトコルが相互運用可能性を確保しつつ動作する背後で働いているのである。
 　ここで注意を要する暗号アルゴリズムが、いくつかある。例えば、RSASSA-PSSや、RSA-OEAPというアルゴリズムについては、オブジェクトIDのみならず、それらのパラメータも交換・共有されることを要するので、プロトコル仕様がそのために領域を規定していなければならない。
 　後述するように、アプリケーションプログラムを保守する者自身は、移行するセキュアプロトコルをプログラムに実装する必要はない。むしろ保守性の観点から、適切なライブラリを見極めて呼び出すことの方が適切であるといえる。

 　IETF （The Internet Engineering Task Force）のセキュリティエリア内の各 WG が、近年、共通の課題として取り組んできたのが「ハッシュ・アジリティ（Hash Agility）」と呼ばれたハッシュ関数の取り替え可能性の確保の課題である。SHA-1アルゴリズムの将来的な安全性を懸念して、よりセキュアなアルゴリズムに移行できるようにする前提として、インターネットプロトコル仕様の中ではアルゴリズムを交換可能なものとして規定すべきとされた。SHA-1の利用を本文中に明記してしまっていた仕様については、改訂作業が進められた。例えば、RFC 2560が規定していた OCSP（Online Certificate Status Protocol）等が挙げられる。
 　セキュリティエリアからは、2008年8月にTLS（Transport Layer Security）1.2の仕様がRFC 5246として発行された[6]。 この仕様が検討された過程では、上記の交換可能性の確保の観点を越えて、興味深い議論が行われてきた。TLSの仕様では、cipher suite と呼ばれる複数の暗号技術の組み合わせの集合が規定されており、ハンドシェイクの一環で利用されるcipher suite が交渉される。TLSのWGにおいては「これらのcipher suite の集合を、よりセキュアなものの集合に移行しなければならない」という観点から、従前は是とされてきた「下位互換性の確保」を断ち切らなければならないとする議論が行われてきた[7]。 この話題は、ヴァンクーバー会合（2007年12月）からフィラデルフィア会合（2008年3月）にかけて議論されてきた。このように、プロトコル仕様が下位互換性を断ち切ることは、次項で述べる相互運用可能性テストにおいて、考慮すべきテスト項目も変容させる。
 　複数世代のプロトコル仕様を実装しているアプリケーションが、下位互換性を制約する事例もある。ブラウザのひとつ、マイクロソフト社のInternet Explorer 7が2006年末にリリースされて普及してきたが、このデフォルト設定として、SSL 2.0プロトコルが無効とされている[8]。 SSL 2.0仕様には、cipher suite の交渉におけるダウングレード攻撃が可能という脆弱性等があり、これらを解消したSSL 3.0仕様は、1996年に発行された。このデフォルト設定の変更によるSSL 2.0プロトコルの無効化には10年を要したことになる。

 　アプリケーションプログラムを保守してプロトコルを移行させるために修正したり、新規に新しいプロトコルに対応するアプリケーションを開発する者は、将来のプロトコルの移行をも考慮して、プロトコルに依存しないコーディングを心がける必要がある。例えば、プロトコル固有の構造体の要素を自らポインタで操作するようなコーディングをしてしまうと、将来、機能性／相互運用可能性を確保できなくなる懸念があると共に、保守性が損なわれてしまう。
 　保守性を確保するためには、品質の高いライブラリが提供されるようになるのを待って、それらを関数として呼び出すようにする必要がある。この際に、いくつか注意を要する点があるが、これらの注意事項はセキュアプロトコルを対象とする場合に限られない。
 　まず、ライブラリが提供される際には、同様の機能を実現するために、複数の関数が候補となる可能性がある。この際に、保守性の観点からは、特定のバージョンに固有の関数を避けて、複数世代のバージョンを通じて汎用的に利用できるものを探して呼び出すようにすることが望ましい。
 　また、既存のソースコードが、何らかの理由によって、ライブラリ関数を呼び出さずに自らポインタで構造体を操作するようになっている場合、その背景と機能をよく理解した上で、必要な機能を実現するように修正を加える必要がある。

 　新しい通信プロトコル仕様を策定する過程や、その仕様が確定して発行されて他者が実装したとき、加えて仕様の細部を追加的に取り決めようとするときなどに、相互運用可能性テストが実施される。暗号技術を応用するセキュアプロトコルの場合、比較的多くの設定項目が規定されるので、テストケースにおける「場合分け」が膨大となることがある。
 　相互運用可能性テストにおいては、通常、ソフトウェアツールと、テストデータの集合、加えて一連の手続きを解説したドキュメントが利用されるが、先行してリファレンスとする実装を決める必要がある。そして、そのソフトウェアツールは、各プロトコルに固有のものとなり、汎用的なものは見聞きしない。プロトコル仕様のバージョンが上がれば、リファレンス実装やソフトウェアツールも更新する必要がある。
 　複数の組織から各実装を持ち寄ることになるので、中立的な団体が構成されたり、運営にあたることが多い。

 　「システム移行テスト」は、旧システムから新システムへの移行を行う際に、円滑な作業を行うことができるように実施されるテストである。2009年から再編される情報処理技術者試験の出題範囲の体系においては「サービスマネジメント」の項で扱われる基本的な論点でもある。
 　移行の際に必要な一連の作業を、あらかじめドキュメントとして、とりまとめておき、リハーサルとしてのテストを行って、その結果を評価することによって、一連の作業が実際に成功するようにドキュメントを修正して本番に備える。一般に、運用中のシステムについては、長時間停止させることは難しいことが、前提として考慮される。

 　とかくv6対応機器の新規配備が話題になり易いが、既存のシステム／ソフトウェアを活かして移行させる技術についても注目したいところである。
 　「IPv4/IPv6デュアルスタック」(以下、デュアルスタック)とは、ひとつの機器にIPv4とIPv6の両仕様に基づくプロトコルスタックを共存させる仕組みをいう。この仕組みを利用することによって、状況に応じてIPv4またはIPv6の利用を選択できるようになる。
 　IPv4環境とIPv6環境の共存を可能にする仕組みとしては、 この他にもデュアルスタック化が困難な機器を対象とする、 IPv4とIPv6相互のプロトコル変換を目的とした「IPv6/IPv4トランスレータ」と、 IPv6のパケットをIPv4でカプセル化して転送する「IPv6 over IPv4トンネリング」が挙げられる[9]。

 　DNSSECプロトコルが動作するDNSの配備も、今後、広く進めていく必要があると言われている課題であるが、この際の技術的な課題は、まだ整理しきれていないように見受けられる。これに関しては、DNSSEC Deployment Initiative³ が、技術的な課題とロードマップを取りまとめている。ここでは、DNSSECの配備に影響を与えている論点として、下記の論点が識別されている。

•  　Rootの問題
•  　鍵の更新（rollover）
•  　ゾーン横断（Zone walking）
•  　性能
•  　アルゴリズムの更新
•  　アプリケーションの問題