C<- 3 ->E


D English

$ DAC
Data Authentication Code, discretionary access control 参照。
 
$ DASS
Distributed Authentication Security Service 参照。
 
$ data (データ)
(I) 情報を特定の物理的な形式で表したもの。通常は、意味を持つ記号の連続。; 特に、コンピュータによって処理または生成できる情報の表現。
 
$ Data Authentication Algorithm (データ認証アルゴリズム)
(N) IV = 0 の DES 暗号ブロックチェーンと等価の鍵付きハッシュ関数。[A9009]

(D) インターネット標準文書は、この用語の小文字表現を、他の種類のチェックサムの同義語として使ってはいけない(SHOULD NOT)
 
$ data authentication code vs. Data Authentication Code (DAC)
1. (N) 大文字:
"Data Authentication Code"は、Data Authentication Algorithm によって計算されるチェックサムについての米国政府標準 [FP113] をいう。 (ANSI 標準 Message Authentication Code [A9009] としても知られている。)

2. (D) 小文字:
インターネット標準文書は、"data authentication code" を 他の種類のチェックサムの同義語として使ってはいけない(SHOULD NOT)。この用語は、潜在的に誤解を招くように概念を混ぜてしまうからである。
authentication code 参照。)
代わりに、意味に応じて、"checksum", "error detection code", "hash", "keyed hash", "Message Authentication Code", "protected checksum" を使う。
 
$ data compromise (データ暴露)
(I) セキュリティインシデントの 1 つ。情報は、権限のない開示、変更、または情報の使用などの潜在的な不正アクセス(無権限アクセス)にさらされる。
compromise 参照。)
 
$ data confidentiality (データの守秘性)
(I) 「(例えば、権限のない任意のシステム主体に対して)情報が利用されない、または権限のない個人、主体、またはプロセスに開示されない特性。。」 [I7498 Part 2]
data confidentiality service 参照。)

(D) インターネット標準文書は、この用語を "privacy" の同義語として使ってはいけない(SHOULD NOT)。これは、異なる概念である。
 
$ data confidentiality service (データ守秘性確保サービス)
(I) 認可されていない開示からデータを防護するセキュリティサービス。
data confidentiality 参照。)

(D) インターネット標準文書は、この用語を "privacy" の同義語として使ってはいけない(SHOULD NOT)。これは、異なる概念である。
 
$ Data Encryption Algorithm (DEA)
(N) 共通鍵暗号技術の 1つ。米国政府の Data Encryption Standard の 1部として規定されている。DEA は、64 ビット鍵を使う。このうち、56 ビットは任意に選択され、8 ビットはパリティビットであり、64 ビットブロックを別の 64 ビットブロックに変換する。 [FP046]
DES, symmetric cryptography 参照。)

(C) このアルゴリズムは、通常、"DES"として言及される。このアルゴリズムは、政府部門以外の標準においても採用されている。
(例: [A3092])
 
$ data encryption key (DEK)
(I) アプリケーションデータを暗号化するために使われる暗号技術的鍵。
key-encrypting key 参照。)
 
$ Data Encryption Standard (DES)
(N) Data Encryption Algorithm を規定し、このアルゴリズムを秘密区分とされていないが取扱に注意を要するデータを防護するために使うことについて、ポリシーを宣言している米国政府標準。[FP046]
(AES, DEA 参照。)
 
$ data integrity (データインテグリティ、データの完全性)
(I) データが、認可されていない、または、偶発的な作法によって、変更されていない、破壊されていない、または、失われていないという属性。
data integrity service 参照。)

(O) 「『情報が 認可されていない作法で変更/破壊されていない』という特性。」 [I7498 Part 2]

(C) 値が表す情報ではなく、データ値の一貫性と信頼性を扱う(correctness integrity 参照)、または値のソースの信頼性。(source integrity 参照。)
  •  
  • $ data integrity service (データインテグリティサービス/データ完全性確保サービス)
    (I) データへの変更を検出可能にすることにより、意図的な変更や破壊および偶発的な変更や損失の両方を含むデータへの不正な変更を防止するセキュリティサービス。
    data integrity 参照。)

    (C) データインテグリティサービスは、変更を検出し、適切なシステム主体に報告するだけである。; システムが完全で(エラーフリー)、悪意のあるユーザがまったくアクセスしない限り、変更を防ぐことはできなし。しかし、データインテグリティサービスを提供するシステムは、変更からの修正および復旧を行うことがある。

    (C) データインテグリティサービスと認証サービスの関係:
    データ インテグリティサービスは、データ発信元認証サービスおよびピア主体認証サービスとは別に定義されるが、これらに近い関係を持つ。認証サービスは、定義により、伴うデータインテグリティサービスに依拠する。データ発信元認証サービスは、「受け取られたデータ単位のオリジナルの発信元の身元は、主張どおりであるかどうか」の検証を提供する。; データ単位が変更されている場合は、そのような検証は不可能である。ピア主体認証サービスは、「現在の関連性において、ピア主体の身元は、主張どおりであるかどうか」の検証を提供する。
     
    $ data origin authentication (データ発信元認証)
    (I) 「受け取られたデータの発信元が主張どおりであることの裏付け」[I7498 Part 2]
    authentication 参照。)
     
    $ data origin authentication service (データ発信元認証サービス)
    (I) 受け取られたデータのオリジナルの発信元であると主張するシステム主体の身元を検証するセキュリティサービス。
    authentication, authentication service 参照。)

    (C) このサービスは、データを受け取るまたは保持するどのシステム主体にも提供される。ピア主体認証サービスとは異なり、このサービスは、発信者と受信者間のあらゆる関連から独立しており、該当のデータは過去の任意の時間に発信された可能性がある。

    (C) 秘密鍵を知らない者は正しい署名を偽造できないので、デジタル署名メカニズムを使用してこのサービスを提供できる。しかし、署名者の公開鍵を使用することによって、誰でも、正しく署名されたデータの発信元を検証できる。
     
    (C) このサービスは、通常、接続のないデータインテグリティサービスと組み合わされる。
    data integrity service (におけるデータインテグリティサービスと認証サービスの関係)参照。)
     
    $ data privacy
    (D) インターネット標準文書は、この用語を使ってはいけない(SHOULD NOT)。これは、潜在的に誤解を招くように概念を混ぜてしまうからである。代わりに、意味に応じて、"data confidentiality" もしくは "privacy" を使う。
     
    $ data security (データセキュリティ)
    (I) 意図的または偶発的にかかわらず、権限のない開示、変更、破壊、または損失からデータを防護する。
    (C) データ守秘性確保サービスと、データ インテグリティ サービスの両方は、データセキュリティを達成するために必要とされる。
     
    $ datagram (データグラム)
    (I) 「発信元から目的地への送信に必要な情報を保持する自己完結的で独立したデータ主体。」 [R1983]
     
    $ DEA
    Data Encryption Algorithm 参照。
     
    $ deception
    threat consequence (にある 2番目の定義)参照。
     
    $ decipher
    (D) インターネット標準文書は、特別な状況を除いて、この用語を「復号する(decrypt)」の同義語として使ってはいけない(SHOULD NOT)
    encryption(にある用法)参照。)
     
    $ decipherment
    (D) インターネット標準文書は、特別な状況を除いて、この用語を「復号(decryption)」の同義語として使ってはいけない(SHOULD NOT)
    encryption (にある用法)参照。)
     
    $ decode (デコード)
    (I) エンコードされたデータを、その元の表現形態に戻す変換をすること。
    decrypt 参照。)

    (D) インターネット標準文書は、この用語を "decrypt" の同義語として使ってはいけない(SHOULD NOT)。それは、潜在的に誤解を招くように概念を混ぜてしまうからである。
     
    $ decrypt (復号する)
    (I) 暗号文を暗号化される前の平文の形態に暗号技術的に復元すること。
     
    $ decryption (復号)
    encryption (にある 2番目の定義)参照。
     
    $ dedicated security mode (専用セキュリティモード)
    (I) 情報システムの運用モードのひとつで、システムによって扱われるすべてのデータに対し、すべてのユーザーが権限および知る権利を持つ。システムは、このモードにおいて、ひとつの秘密区分レベル、情報のカテゴリ、レベルとカテゴリの範囲のいずれかを扱う可能性がある。[DOD2]

    (C) このモードは、正式には、米国国防総省のシステム運用承認(system accreditation)に関するポリシーにおいて定義されているが、この用語は、国防総省以外と政府以外においても使われる。
     
    $ default account (デフォルトアカウント)
    (I) 製造されたシステムであらかじめ定義されているシステムログインアカウントで(通常は、ユーザ名とパスワードによってアクセスする)、システムが初めてサービスに供される時点での初期アクセスを可能にする。

    (C) しばしば、デフォルトユーザ名とパスワードは、システムにおいて同じになっている。いかなる場合においても、システムがサービス開始されるとき、デフォルトパスワードは、直ちに変更される必要がある。あるいは、そのデフォルトアカウントは、削除される必要がある。
     
    $ degauss (消磁する)
    (N) テープまたはディスクなどの磁気ストレージメディアからデータを永久的に除去、削除、または消去するために磁気フィールドを加えること。[NCS25] 逆方向の磁気フィールドを加えることにより、磁束密度を 0 に減少させること。
     
    $ degausser (消磁器)
    (N) 磁気ストレージメディアを消磁することができる電子的デバイス。
     
    $ DEK
    data encryption key 参照。
     
    $ delta CRL
    (I) 前回のベース CRL の発行以降に失効した X.509 証明書のエントリだけを含む部分的 CRL。この手法は、非常に大きくて扱いにくくなった CRL を分割するために使用される。
     
    $ denial of service (サービス妨害)
    (I) システム資源への正当なアクセスを妨害すること、またはシステムの運用および機能に遅延を生じさせること。
    availability, critical (resource of a system), flooding. 参照。)
     
    $ DES
    Data Encryption Standard 参照。
     
    $ dictionary attack (辞書攻撃)
    (I) ブルートフォース技術を使用し、ある種の巨大で網羅的なリスト内のすべての単語を連続的に試みる攻撃。
     
    (C) 例えば、認証サービスに対してすべてのパスワード候補を試みる攻撃。; あるいは、暗号化に対し、既知の平文フレーズをすべての鍵候補で暗号化し、そのフレーズを持つ暗号化済みのメッセージを照合することによって鍵を得る攻撃。
     
    $ Diffie-Hellman
    (N) 1976年に Whitfield Diffie と Martin Hellman によって発表された鍵共有(agreement)アルゴリズム。[DH76, R2631]

    (C) Diffie-Hellman は、鍵確立を行うが、暗号化はしない。しかし、Diffie-Hellman が生成した鍵は、暗号化、詳細な鍵管理操作、その他の任意の暗号技術に使用される可能性がある。

    (C) Diffie-Hellman を解読することの難しさは、大きな素数を法とする離散対数問題を解く困難性と同等であると考えられている。このアルゴリズムは、[R2631] と [Schn] において記述されている。簡潔に述べると、まず、アリスとボブは共に、特定の数学的条件を満たす大きな整数をとり、それぞれ個別にこれらの整数を使用して公開鍵と私有鍵の鍵ペアを作成する。次に、彼らはお互いに自分の公開鍵を相手に送る。各々は、自分の私有鍵と相手の公開鍵を使用して鍵 k を計算する。数学的なアルゴリズムにより、この鍵 k は、相互に同じものになる。受動的回線盗聴によっても、共有された k を知ることはできない。k は送信されないし、k を計算するのに必要な私有鍵も送信されないからである。しかし、各主体を他者に認証させるための追加的メカニズム無しでは、このアルゴリズムに基づくプロトコルは、中間者(man-in-the-middle)による攻撃に対して脆弱である可能性がある。
     
    $ digest (ダイジェスト)
    message digest 参照。
     
    $ digital certificate (デジタル証明書)
    (I) デジタルデータオブジェクト (コンピュータによって使用されるデータオブジェクト) の形態をした証明書文書で、データオブジェクトに依存する計算されたデジタル署名値が適用される。
    attribute certificate, capability, public-key certificate 参照。)

    (D) インターネット標準文書は、この用語を 署名された CRL もしくは CKL を言及するように使ってはいけない(SHOULD NOT)。推奨された定義ではこれらの項目を含むように解釈可能だがセキュリティコミュニティは、この用語をそのような意味では使わない。
     
    $ digital certification
    (D) デジタル認証と他の種類の認証の区別が明確につかない状況でない限り、インターネット標準文書は、この用語を "certification" の同義語として使ってはいけない(SHOULD NOT)。このようなケースでは、「公開鍵認証」(public-key certification)または認証されるものを示す他のフレーズを使用する方がよい。
     
    $ digital document (デジタル文書)
    (I) もともと非電子的、非磁気的なメディア(通常はインクで紙に)に書かれた情報またはこのようなタイプの文書の類似物を表す電子データオブジェクト。
     
    $ digital envelope (デジタル封筒)
    (I) 受信者にとってのデジタル封筒とは、
    (a) 暗号化された内容データ(任意の種類)と
    (b) 受信者が使用するために準備された内容暗号化鍵を暗号化したものの組み合わせである。

    (C) インターネット標準文書において、この用語は、最初に使用する時点で定義される必要がある。用語が PKCS #7 で定義され、S/MIME で使用されている場合でも、これは幅広く認知されていないからである。

    (C) デジタル封筒は、暗号化によってデータの守秘性を実装することの同義語ではない。; デジタル封筒は、メッセージまたは他のデータを封印するためのハイブリッドな暗号化方式で、暗号化したデータと防護された鍵の両方を目的の受信者に送信することにより、目的の受信者以外の誰もメッセージを開くことができないようにする。PCKS #7 では、デジタル封筒は、最初に、共通鍵暗号アルゴリズムと秘密鍵を使用してデータを暗号化し、次に、共通鍵暗号アルゴリズムと目的の受信者の公開鍵を使用して秘密鍵を暗号化する。S/MIME において、内容の暗号化鍵を運ぶために追加的手法が規定されている。
     
    $ Digital ID (登録商標)
    (D) インターネット標準文書は、この用語を"digital certificate"の同義語として使ってはいけない(SHOULD NOT)。それは、以下の理由による。
    (a) これは商業分野における登録商標である。
    (b) われわれが確立した他の用語と不必要に重複してはならない
    (c) 証明書は、いつも認証情報として使われるとは限らない。
    しかし、文脈によっては、公開鍵証明書によって運搬される鍵は身元の検証に使用でき、それゆえ、証明書はデジタル識別情報として考えられると説明することが有益である。
    identification 参照。)
     
    $ digital key (デジタル鍵)
    (C) デジタル鍵と他の種類の鍵(たとえば、ドアの施錠に使用する鉄の鍵)の区別が不十分な状況でない限り、形容詞の「デジタル」は「鍵」または「暗号鍵」と共に使用する必要はない。
     
    $ digital notary (デジタル公証)
    (I) 公証人のアナロジー。信頼された日時スタンプを文書に発行することにより、将来、その時点で実際に文書が存在していたことを証明できる。スタンプを発行する前に、署名済みの文書の署名を検証できる。
    notarization 参照。)
     
    $ digital signature (デジタル署名)
    (I) データのあらゆる受信者が、その署名をデータの発信元およびインテグリティを検証するために使えるようなやり方で、暗号アルゴリズムによって算出され、データオブジェクトに追加される値。
    data origin authentication service, data integrity service, digitized signature, electronic signature, signer 参照。)

    (I) 「データユニットの受信者がデータユニットの源泉とインテグリティを証明できるようにし、(例: 受信者による)偽装から防護する、データユニットに追加されたデータ、もしくは、データユニットの暗号技術的な変換。」 [I7498 Part 2]

    (C) 典型的には、そのデータオブジェクトは、ハッシュ関数に対する最初の入力であり、次に、そのハッシュ結果は、署名者のプライベート鍵を使って、暗号技術的に変換される。最終結果としての値は、そのデータオブジェクトのデジタル署名と呼ばれる。その署名の値は、保護されたチェックサムである。なぜなら、暗号技術的ハッシュの属性は、「データオブジェクトが変更された場合、そのデジタル署名は、もはや一致しないこと」を確保するからである。デジタル署名は、偽造不能である。なぜなら、想定される署名者のプライベート鍵を知らずして、署名を正しく作成したり、変更することについて、確信を持つことはできないからである。

    (C) デジタル署名スキームには、ハッシュ結果を変形するために、公開鍵暗号アルゴリズム(例: RSA 参照。)を使うものがある。それゆえ、アリスがボブに送るためにメッセージに署名する必要があるとき、彼女は、そのハッシュ結果を暗号化するために彼女のプライベート鍵を使うことができる。ボブは、メッセージとデジタル署名の両方を受け取る。ボブは、アリスの公開鍵をその署名を復号するために使うことができ、次に、平文の結果を彼が自信でメッセージをハッシュ化して求めたハッシュ結果と比較する。値が等しい場合、ボブは、そのメッセージを受け入れる。なぜなら、それはアリスからのものであり、変更されずに到着したと確信を持てるからである。その値が等しくない場合、ボブは、そのメッセージを棄却する。なぜなら、そのメッセージも、その署名も経路において変えられているからである。
     
    (C) 他のデジタル署名スキーム(例: DSS 参照)は、そのハッシュ結果をデータを暗号化するためには直接使うことができないアルゴリズム(例: DSA, El Gamal 参照)で変換する。このようなスキームは、そのハッシュから署名値を作成し、その署名値を検証するやり方を提供するが、署名値からハッシュ結果を復元するやり方は提供しない。国によっては、このようなスキームは、輸出可能性を高め、利用における他の法的制約を避ける可能性がある。
     
    $ Digital Signature Algorithm (DSA)
    (N) 大きな数値ペアの形態のデジタル署名を作り出す公開鍵暗号アルゴリズム。この署名は、署名者の身元や署名されたデータのインテグリティを検証できるようにルールやパラメータを使って処理される。
    Digital Signature Standard 参照。)
     
    $ Digital Signature Standard (DSS)
    (N) 公開鍵暗号技術を含む DSA(Digital Signature Algorithm)を仕様とする米国政府標準。[FP186]
     
    $ digital watermarking (デジタル透かし)
    (I) デジタルデータ(テキスト、画像、動画もしくは音声)中のビットとして、控えめな印もしくはラベルを分離せずに埋め組むため、および、後でその印を検出したり取り出したりするための情報処理技術。

    (C) 埋め込まれたビット(デジタル透かし)は、しばしば隠されており、通常、感知不能であり、常に控えめであることが意図されている。使われている特定のテクニックによっては、デジタル透かしは、所有権、複製の制御、配布の追跡、データインテグリティの確保および知的財産権を保護するための他の機能の提供を支援できる。[ACM]
     
    $ digitized signature
    (D) インターネット標準文書は、この用語を使ってはいけない(SHOULD NOT)。なぜなら、この定義について、現在、合意が無いからである。手書きの署名のデジタル化された様々な形態をいうのに主に使われているようであるが、この用語は、"digital signature" と混乱する可能性があるので避ける必要がある。
     
    $ directory
    $ Directory
    directory vs. Directory 参照。
     
    $ Directory Access Protocol (DAP)
    (N) クライアント(Directory User Agent)とサーバー(Directory System Agent)間の通信のための OSI プロトコル。[X519]
    Lightweight Directory Access Protocol 参照。)
     
    $ directory vs. Directory
    1. (I) 小文字:
    "directory" という用語は、一般的に、名前が知られている主体についての(デジタル証明書、もしくは CRL のような)情報を提供するデータベースサーバー、もしくは他のシステム をいう。

    2. (I) 大文字:
    "Directory" は、とりわけ、X.500 ディレクトリをいう。
    repository 参照。)
     
    $ disaster plan
    (D) "contingency plan" の同義語。整合性確保の観点から、インターネット標準文書は、"disaster plan" の代わりに "contingency plan" を使う必要がある(SHOULD)
     
    $ disclosure (i.e., unauthorized disclosure)
    threat consequence (にある 2番目の定義)参照。
     
    $ discretionary access control (DAC) (自由裁量的アクセスコントロール)
    (I) 主体の身元と、そのアクセスするシステム資源への認可に基づいてセキュリティポリシーを強要するアクセスコントロールサービス。
    access control list, identity-based security policy, mandatory access control 参照。)

    (C) このサービスは、「自由裁量的(discretionary)」であるという用語である。なぜなら、主体は、自身の権限で他者が何らかの資源にアクセスできるようにするアクセス権限をもつからである。

    (O) 「オブジェクトに対するアクセスを、サブジェクトの身元、かつ/または、所属するグループに基づいて制限する手段。このコントロールは、『一定のアクセス権限をもったサブジェクトは、その権限を(おそらく直接に)いかなる他のサブジェクトに渡すことができる』という意味において、自由裁量的である 。」 [DOD1]
     
    $ disruption
    threat consequence (にある 2番目の定義)参照。
     
    $ Distinguished Encoding Rules (DER)
    (N) Basic Encoding Rules のサブセットであり、これは、あらゆる ASN.1 値をオクテットストリングとして明確に表現する方法を示している。[X690]

    (C) ASN.1 を BER にエンコードするには複数のやり方があるので、DER は、デジタル署名が ASN.1 値として処理されるときのような、一意なエンコーディングが必要とされるアプリケーションにおいて使われている。
     
    $ distinguished name (DN)
    (I) X.500 DIT(Directory Information Tree)において、オブジェクトを一意に表現する識別子。[X501]
    domain name 参照。)

    (C) DN は、DIT のベースから命名されたオブジェクトに至るパスを識別する一式の属性値である。X.509 公開鍵証明書もしくは CRL は、その発行者を識別する DN を含み、X.509 属性証明書は、そのサブジェクトを識別する DN もしくは他の形態の名前を含む。
     
    $ Distributed Authentication Security Service (DASS)
    (I) 分散環境において強力で相互的な認証サービスを提供するために暗号技術的メカニズムを使う実験的なインターネットプロトコル。[R1507]
     
    $ distribution point (配布点)
    (I) X.509 v3 公開鍵証明書拡張中に証明書をリストする可能性がある CRL を取得できる場所として命名された X.500 ディレクトリのエントリ、もしくは、他の情報の源泉。

    (C) X.509 v3 公開鍵証明書は、証明書が掲載されている可能性がある CRL を取得する場所を指名する "cRLDistributionPoints" 拡張をもつ可能性がある。配布点から入手された CRL には、以下の可能性がある。
    (a) ある証明書が失効された理由のすべて、あるいは、その理由の一部を範囲とする。
    (b) その証明書に署名した機関もしくは他の機関によって発行される。
    (c) ある CA によって発行された証明書全体のサブセットのみについての失効エントリを含む。
    (c') 複数 CA についての失効エントリを含む。
     
    $ DN
    distinguished name 参照。
     
    $ DNS
    Domain Name System 参照。
     
    $ DOI
    Domain of Interpretation 参照。
     
    $ domain (ドメイン)
    (I) セキュリティにおける用法:
    システム資源の集合と、その資源に対するアクセス権限をもつシステム主体の集合を含める、セキュリティポリシーによって規定された環境もしくは文脈、セキュリティモデル、もしくは、セキュリティアーキテクチャ。
    domain of interpretation, security perimeter 参照。)

    (I) インターネットにおける用法:
    ドメインを規定する名前以下のインターネットドメインの名前空間の木の部分。[R1034] あるドメインが他のドメインの中にある場合、そのドメインのサブドメインである。例えば、D.C.B.A は、C.B.A のサブドメインである。
    Domain Name System 参照。)

    (O) MISSI における用法:
    MISSI CA のドメインは、 自身の証明書が当該 CA によって署名されている MISSI ユーザの集合である。

    (O) OSI における用法:
    複雑な分散型 OSI システムの運用管理単位。
     
    $ domain name (ドメイン名)
    (I) インターネットの DNS(Domain Name System)[R1034] 中の木の構成要素について規定された識別子のスタイル(大文字小文字を区別しないものであり、ドットによって区分された一連の ASCII ラベル("bbn.com."))であり、ホスト名(例: "rosslyn.bbn.com.")、メールボックス名(例: "rshirey@bbn.com.")および URL(例: "http://www.rosslyn.bbn.com/foo")のような他のインターネット識別子において使われている。
    distinguished name, domain 参照。)

    (C) 各ノードや葉に資源を記述するレコードが保持されている DNS のドメイン名空間は、木構造である。各ノードは、ラベルをもつ。ノードのドメイン名は、ノードからルートに至るパス中のラベルのリストである。ドメイン名中のラベルは、左から右へ印刷されたり、読まれたりする。(最も具体的なもの(ルートから遠い低位のもの)から、最も大づかみなもの(ルートに近い高位のもの)へ。)ルートのラベルは、ヌルストリングであるので、完全なドメイン名は、正しくはドットで終わる。ルート直下にある最上位のドメインは、COM, EDU, GOV, INT, MIL, NET, ORG および(US のような)ISO-3166 の 2 文字の国コードを含む。[R1591]
    country code 参照。)
     
    $ Domain Name System (DNS)
    (I) 主たるインターネット運用データベースであり、これは、複数のサーバーに分散されている。また、クライアントソフトウェアによって、ドメイン名のスタイルのホスト名を IP アドレスに変換(例: "rosslyn.bbn.com" を "192.1.7.10" に変換)し、あるメールボックスのアドレス宛のメールを受け入れるホストを位置付けるような目的のために使われている。[R1034]

    (C) DNS は、3つの主要なコンポーネントを持つ。:
    (C) DNS の拡張 [R2065, R2137, R2536] は、下記の機能をサポートする。
    (a) DNS 用および他のプロトコル用に必要とされる公開鍵についての鍵配布
    (b) 資源レコードについてのデータ発信元認証サービスおよびデータインテグリティサービス
    (c) リゾルバーとサーバー間のトランザクション用のデータ発信元認証サービス
    (d) レコードのアクセスコントロール
     
    $ domain of interpretation (DOI) (解釈範囲)
    (I) IPsec における用法:
    ISAKMP/IKE DOI は、 ペイロードのフォーマット、交換種別、および、セキュリティポリシー、もしくは、暗号アルゴリズムやモードのようなセキュリティ関連情報の命名慣行を規定する。

    (C) 例えば、[R2407] 参照。DOI の概念は、TSIG の CIPSO ワーキンググループによる作業に基づく。
     
    $ dominate (優越する)
    (I) A の階層的秘密区分の方が B より偉い(高位である)か同等である場合や、非階層的な A の分類が B の分類のすべてを含む場合、セキュリティレベル A は、セキュリティレベル B に対して「優越する(dominate)」といわれる。
     
    $ dongle (ドングル)
    (I) 特定のソフトウェアプログラムを動作できるようにするためにコンピュータに接続することが要求されるポータブルな物理的電子デバイス。
    token 参照。)

    (C) ドングルは、要は、ソフトウェアの複製を防止するために使われる物理的な鍵である。なぜなら、そのプログラムは、ドングルが挿されていない限り、動作しないからである。そのソフトウェアが動作するとき、これは定期的にドングルを尋ねて、そのドングルが正しい認証情報で応答しない場合、終了する。ドングルは、もともと、パーソナルコンピュータのシリアル入出力ポートに接続される EPROM(Erasable Programmable Read-Only Memory)として製造された。
     
    $ downgrade (ダウングレード)
    (I) 認可された作法によって情報の秘密区分レベルを引き下げること。
     
    $ draft RFC
    (D) インターネット標準文書は、この用語を使ってはいけない(SHOULD NOT)。なぜなら、「RFC(Request for Comment)」シリーズは、記録の性格をもち、"draft" という分類をもたないからである。
    (代わりに Internet Draft, Internet Standard にある)Draft Standard 参照。)
     
    $ DSA
    Digital Signature Algorithm 参照。
     
    $ DSS
    Digital Signature Standard 参照。
     
    $ dual control (デュアルコントロール)
    (I) どの主体も単独ではシステム資源にアクセスできないように、その資源を防護する文脈において、複数の主体(通常、人間) による運用を使う手順。
    no-lone zone, separation of duties, split knowledge 参照。)
     
    $ dual signature (デュアル署名)
    (D) インターネット標準文書は、次の意味の "SET (trademark) dual signature" として述べる場合以外、この用語を使ってはいけない(SHOULD NOT)。:

    (O) SET における用法:
    2 つの分離されたメッセージに、両者のハッシュ結果をひとつの暗号化した値を含めることによって、2 つの分離されたメッセージを防護する単一のデジタル署名。[SET2]

    (C) 各メッセージを別々にハッシュすることによって生成され、その 2 つのハッシュ結果を含み、その値をハッシュし、そのハッシュ結果を署名者のプライベート鍵で暗号化する。暗号化操作の数を低減し、データを完全に開示せずにデータインテグリティの検証を可能にするために行われる。

    C<- 3 ->E