[要約] RFC 4949 - Internet Security Glossary, Version 2は、インターネットセキュリティに関連する用語とその定義を提供する文書です。この文書の目的は、セキュリティ関連の議論や文書で用語が一貫して使用されることを促進することにあります。主にセキュリティ技術者、開発者、ポリシー作成者が参照するために利用されます。関連するRFCにはRFC 2828（Internet Security Glossaryの初版）などがあります。この文書は、インターネットセキュリティの基礎を理解する上で重要なリソースとなっています。
Network Working Group R. Shirey
Request for Comments: 4949 August 2007
FYI: 36
Obsoletes: 2828
Category: Informational
Internet Security Glossary, Version 2
インターネットセキュリティ用語集バージョン2
Status of This Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティに関する情報を提供します。インターネット規格はあらゆる種類の標準を指定していません。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）IETF Trust（2007）。
RFC Editor Note
RFCエディタノート
This document is both a major revision and a major expansion of the Security Glossary in RFC 2828. This revised Glossary is an extensive reference that should help the Internet community to improve the clarity of documentation and discussion in an important area of Internet technology. However, readers should be aware of the following:
この文書は、RFC 2828のセキュリティ用語集の主な改訂と大きな拡大の両方です。この改訂された用語集は、インターネットコミュニティがインターネット技術の重要な分野での文書化と議論を改善するのに役立つ広範囲の参照です。ただし、読者は次のことを知っておくべきです。
(1) The recommendations and some particular interpretations in definitions are those of the author, not an official IETF position. The IETF has not taken a formal position either for or against recommendations made by this Glossary, and the use of RFC 2119 language (e.g., SHOULD NOT) in the Glossary must be understood as unofficial. In other words, the usage rules, wording interpretations, and other recommendations that the Glossary offers are personal opinions of the Glossary's author. Readers must judge for themselves whether or not to follow his recommendations, based on their own knowledge combined with the reasoning presented in the Glossary.
（1）定義の推奨事項およびいくつかの特定の解釈は、著者のものであり、公式のIETFの位置ではありません。IETFは、この用語集によって行われた推奨事項のどちらかで正式な立場を取っていないため、用語集にRFC 2119言語（例えば、そうでなければならない）の使用は非公式として理解されなければなりません。言い換えれば、使用規則、表彰の解釈、および用語集が提供するその他の推奨事項は、用語集の著者の個人的な意見です。読者は、用語集に提示された推論と組み合わされた彼ら自身の知識に基づいて、自分の勧告に従うかどうかを彼ら自身のために判断しなければなりません。
(2) The glossary is rich in the history of early network security work, but it may be somewhat incomplete in describing recent security work, which has been developing rapidly.
（2）用語集は、初期のネットワークセキュリティ作業の歴史に富んでいますが、急速に発展してきた最近のセキュリティ作業を説明するのに多少不完全かもしれません。
Abstract
概要
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.
この用語集は、情報システムセキュリティのための用語の定義、略語、および説明を提供します。334ページのエントリーは、インターネット規格プロセス（RFC 2026）で生成された書面による資料の理解度を向上させるための推奨事項を提供します。推奨事項は、（a）同じ概念が言及されているときはいつでも同じ文書を使用する必要があるという原則に従ってください。（b）彼らの普通辞書の意味で用語を使用してください。（c）オープンパブリケーションで既に確立されている用語を使用する。（d）特定のベンダーを支持するか、特定の技術や機構を他の競合する、または開発することができるという用語を避けてください。
Table of Contents
目次
1. Introduction ....................................................3
2. Format of Entries ...............................................4
2.1. Order of Entries ...........................................4
2.2. Capitalization and Abbreviations ...........................5
2.3. Support for Automated Searching ............................5
2.4. Definition Type and Context ................................5
2.5. Explanatory Notes ..........................................6
2.6. Cross-References ...........................................6
2.7. Trademarks .................................................6
2.8. The New Punctuation ........................................6
3. Types of Entries ................................................7
3.1. Type "I": Recommended Definitions of Internet Origin .......7
3.2. Type "N": Recommended Definitions of Non-Internet Origin ...8
3.3. Type "O": Other Terms and Definitions To Be Noted ..........8
3.4. Type "D": Deprecated Terms and Definitions .................8
3.5. Definition Substitutions ...................................8
4. Definitions .....................................................9
5. Security Considerations .......................................343
6. Normative Reference ...........................................343
7. Informative References ........................................343
8. Acknowledgments ...............................................364
This Glossary is *not* an Internet Standard, and its recommendations represent only the opinions of its author. However, this Glossary gives reasons for its recommendations -- especially for the SHOULD NOTs -- so that readers can judge for themselves what to do.
この用語集は*インターネット規格ではなく、その勧告はその著者の意見のみを表しています。しかし、この用語集はその勧告の理由を与えています - 特にあなたのために読者が自分自身のために自分自身を判断することができるように。
This Glossary provides an internally consistent and self-contained set of terms, abbreviations, and definitions -- supported by explanations, recommendations, and references -- for terminology that concerns information system security. The intent of this Glossary is to improve the comprehensibility of written materials that are generated in the Internet Standards Process (RFC 2026) -- i.e., RFCs, Internet-Drafts, and other items of discourse -- which are referred to here as IDOCs. A few non-security, networking terms are included to make the Glossary self-contained, but more complete glossaries of such terms are available elsewhere [A1523, F1037, R1208, R1983].
この用語集は、情報システムのセキュリティに関する用語を説明するための、説明、推奨事項、および参照でサポートされている、内部的に一貫した自己完結型の用語、略語、および定義を提供します。この用語集の意図は、インターネット規格プロセス（RFC 2026） - すなわちRFC、インターネットドラフト、およびその他の談話項目で生成される書面による材料の理解度を向上させることである。いくつかの非セキュリティ、ネットワーク用語が自己完結型にするために含まれていますが、そのような用語の完全な用語集は他の場所で利用可能です[A1523、F1037、R1208、R1983]。
This Glossary supports the goals of the Internet Standards Process:
この用語集は、インターネット標準プロセスの目標をサポートしています。
o Clear, Concise, Easily Understood Documentation
o 明確で簡潔で、簡単に理解されていました
This Glossary seeks to improve comprehensibility of security-related content of IDOCs. That requires wording to be clear and understandable, and requires the set of security-related terms and definitions to be consistent and self-supporting. Also, terminology needs to be uniform across all IDOCs; i.e., the same term or definition needs to be used whenever and wherever the same concept is mentioned. Harmonization of existing IDOCs need not be done immediately, but it is desirable to correct and standardize terminology when new versions are issued in the normal course of standards development and evolution.
この用語集は、IDocのセキュリティ関連の内容の理解を向上させようとしています。それは文言が明確で理解できるようにすることを必要とし、そして一貫したセキュリティ関連の用語および定義を一貫性および自立的なものにすることを要求する。また、用語はすべてのIDOCにわたって均一である必要があります。すなわち、同じ概念が言及されているときはいつでも同じ用語または定義を使用する必要がある。既存のIDOCの調和はすぐに行われる必要はありませんが、通常の基準の開発と進化の中で新しいバージョンが発行されたときに用語を修正し標準化することが望ましいです。
o Technical Excellence
o 技術的な卓越性
Just as Internet Standard (STD) protocols should operate effectively, IDOCs should use terminology accurately, precisely, and unambiguously to enable standards to be implemented correctly.
Internet Standard（STD）プロトコルが効果的に動作するように、IDocは標準を正確に正確に実行できるように、識別を正確に、正確に、明確に使用する必要があります。
o Prior Implementation and Testing
o 従来の実装とテスト
Just as STD protocols require demonstrated experience and stability before adoption, IDOCs need to use well-established language; and the robustness principle for protocols -- "be liberal in what you accept, and conservative in what you send" -- is also applicable to the language used in IDOCs that describe protocols. Using terms in their plainest, dictionary sense (when appropriate) helps to make them more easily understood by international readers. IDOCs need to avoid using private, newly invented terms in place of generally accepted terms from open publications. IDOCs need to avoid substituting new definitions that conflict with established ones. IDOCs need to avoid using "cute" synonyms (e.g., "Green Book"), because no matter how popular a nickname may be in one community, it is likely to cause confusion in another.
STDプロトコルが採用の前に実証された経験と安定性を必要とするように、IDocは確立された言語を使用する必要があります。プロトコルのための堅牢性の原則 - 「あなたが受け入れたものの自由主義者、そしてあなたが送るものに保守的な」 - プロトコルを記述するIDocで使用される言語にも適用されます。普通の、辞書の意味（適切な場合）の用語を使用すると、国際読者によってより簡単に理解するのに役立ちます。IDocは、開いた出版物から一般に認められている用語の代わりに、プライベート、新しく発明された用語を使用しないでください。IDocは、確立されたものと矛盾する新しい定義を置き換えるのを避ける必要があります。IDocは、ニックネームが1つのコミュニティにどれほど人気があるかもしれないので、他の人に混乱を引き起こす可能性があるため、「かわいい」同義語（例えば、「グリーンブック」）を使用するのを避ける必要があります。
However, although this Glossary strives for plain, internationally understood English language, its terms and definitions are biased toward English as used in the United States of America (U.S.). Also, with regard to terminology used by national governments and in national defense areas, the glossary addresses only U.S. usage.
しかし、この用語集は平野で、国際的に理解されている英語のために努力していますが、その条件と定義は、アメリカ合衆国（米国）で使用されているように英語に偏っています。また、国民政府と国家防衛地域で使用される用語に関しては、用語集は米国の使用だけに対処しています。
o Openness, Fairness, and Timeliness
o 開放性、公平性、そしてタイムレベル
IDOCs need to avoid using proprietary and trademarked terms for purposes other than referring to those particular systems. IDOCs also need to avoid terms that either favor a particular vendor or favor a particular security technology or mechanism over other, competing techniques that already exist or might be developed in the future. The set of terminology used across the set of IDOCs needs to be flexible and adaptable as the state of Internet security art evolves.
IDocは、それらの特定のシステムを参照する以外の目的のための独自の用語および商標の用語を使用するのを避ける必要があります。IDocsはまた、特定のベンダーを支持するか、または他の競合技術または将来開発される可能性がある特定のセキュリティ技術またはそのメカニズムを支持するための用語を避ける必要がある。IDOCのセットにわたって使用される用語のセットは、インターネットセキュリティアートの状態が進化するにつれて柔軟で適応可能である必要があります。
In support of those goals, this Glossary offers guidance by marking terms and definitions as being either endorsed or deprecated for use in IDOCs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are intended to be interpreted the same way as in an Internet Standard (i.e., as specified in RFC 2119 [R2119]). Other glossaries (e.g., [Raym]) list additional terms that deal with Internet security but have not been included in this Glossary because they are not appropriate for IDOCs.
これらの目標をサポートしているため、この用語集は、IDocsでの使用のために承認または廃止されるような用語と定義をマーキングすることによってガイダンスを提供します。キーワード「必ず」、「推奨する」、「推奨」、「5月」、および「オプション」は、インターネット規格と同じ方法で解釈されることを意図している（すなわち、RFC 2119 [R2119]）。その他の用語集（例えば、[raym]）は、インターネットセキュリティを扱う追加の用語をリストしていますが、IDocに適していないため、この用語集に含まれていません。
Section 4 presents Glossary entries in the following manner:
セクション4は、次のように用語集のエントリを示しています。
Entries are sorted in lexicographic order, without regard to capitalization. Numeric digits are treated as preceding alphabetic characters, and special characters are treated as preceding digits. Blanks are treated as preceding non-blank characters, except that a hyphen or slash between the parts of a multiword entry (e.g., "RED/BLACK separation") is treated like a blank.
資本化に関しては、辞書の順序でエントリーが並べ替えられています。数字は前のアルファベット文字として扱われ、特殊文字は前の桁として扱われます。ブランクは、マルチワードエントリの部分（例えば、「赤/黒分離」）の間のハイフンまたはスラッシュが空白のように扱われることを除いて、前の空白の文字の前の非空白文字として扱われます。
If an entry has multiple definitions (e.g., "domain"), they are numbered beginning with "1", and any of those multiple definitions that are RECOMMENDED for use in IDOCs are presented before other definitions for that entry. If definitions are closely related (e.g., "threat"), they are denoted by adding letters to a number, such as "1a" and "1b".
エントリに複数の定義（例えば「ドメイン」）がある場合、それらは「1」で始まる番号が付けられ、IDocでの使用に推奨されている複数の定義のいずれかは、そのエントリの他の定義の前に表示されます。定義が密接に関連している場合（例えば「脅威」）、それらは「1A」や「1B」のような数字に文字を追加することによって示される。
Entries that are proper nouns are capitalized (e.g., "Data Encryption Algorithm"), as are other words derived from proper nouns (e.g., "Caesar cipher"). All other entries are not capitalized (e.g., "certification authority"). Each acronym or other abbreviation that appears in this Glossary, either as an entry or in a definition or explanation, is defined in this Glossary, except items of common English usage, such as "a.k.a.", "e.g.", "etc.", "i.e.", "vol.", "pp.", and "U.S.".
適切な名詞のエントリは、適切な名詞（例えば、「Caesar暗号」）から導き出された他の単語と同様に、資本化されている（例えば、「データ暗号化アルゴリズム」）。他のすべてのエントリは資本化されていません（例えば、「認証局」）。この用語集に表示される各頭字語またはその他の省略形は、エントリとして、または定義または説明のいずれかで、この用語集に定義されています。「IE」、「VOL」、「PP」、「US」。
Each entry is preceded by a dollar sign ($) and a space. This makes it possible to find the defining entry for an item "X" by searching for the character string "$ X", without stopping at other entries in which "X" is used in explanations.
各エントリの前にはドル記号（$）とスペースがあります。これにより、説明に「X」が使用されている他のエントリに停止することなく、文字列「$ X」を検索することで、項目「X」の定義項目を見つけることができる。
Each entry is preceded by a character -- I, N, O, or D -- enclosed in parentheses, to indicate the type of definition (as is explained further in Section 3): - "I" for a RECOMMENDED term or definition of Internet origin. - "N" if RECOMMENDED but not of Internet origin. - "O" for a term or definition that is NOT recommended for use in IDOCs but is something that authors of Internet documents should know about. - "D" for a term or definition that is deprecated and SHOULD NOT be used in Internet documents.
各エントリの前には、（セクション3でさらに説明されているように）定義の種類を示すために、括弧内に囲まれた文字I、N、O、またはD - が前述しています。 - 推奨される用語または定義インターネットの起源 - 推奨されているがインターネットの起源の場合は「n」。 - IDocでの使用に推奨されていないが、インターネット文書の作者が知っておくべきことです。 - 推奨されない用語または定義の「D」は、インターネット文書で使用しないでください。
If a definition is valid only in a specific context (e.g., "baggage"), that context is shown immediately following the definition type and is enclosed by a pair of slash symbols (/). If the definition is valid only for specific parts of speech, that is shown in the same way (e.g., "archive").
定義が特定の文脈（例えば、「手荷物」）でのみ有効である場合、そのコンテキストは定義タイプの直後に表示され、一対のスラッシュシンボル（/）によって囲まれている。定義が音声の特定の部分に対してのみ有効である場合、それは同じ方法で示されています（例えば、「アーカイブ」）。
Some entries have explanatory text that is introduced by one or more of the following keywords: - Deprecated Abbreviation (e.g., "AA") - Deprecated Definition (e.g., "digital certification") - Deprecated Usage (e.g., "authenticate") - Deprecated Term (e.g., "certificate authority") - Pronunciation (e.g., "*-property") - Derivation (e.g., "discretionary access control") - Tutorial (e.g., "accreditation") - Example (e.g., "back door") - Usage (e.g., "access")
一部のエントリには、次のキーワードのうちの1つ以上によって導入された説明文があります。 - 非推奨の省略形（「AA」） - 非推奨の定義（例えば、「デジタル認証」） - 非推奨使用（例えば、「認証」） - 非推奨用語（「認証局」） - 発音（例えば、「* -property」） - 派生（例えば、「裁量アクセス制御」） - チュートリアル（例えば、「認定」） - 例（例：「バックドア」） - 使用法（例：「アクセス」）
Explanatory text in this Glossary MAY be reused in IDOCs. However, this text is not intended to authoritatively supersede text of an IDOC in which the Glossary entry is already used.
この用語集の説明文は、IDOCで再利用できます。ただし、このテキストは、用語集のエントリがすでに使用されているIDocのテキストを信頼することを意図していません。
Some entries contain a parenthetical remark of the form "(See: X.)", where X is a list of other, related terms. Some entries contain a remark of the form "(Compare: X)", where X is a list of terms that either are antonyms of the entry or differ in some other manner worth noting.
一部のエントリには、「（参照：X.）」という形式の括弧付き発言が含まれています。ここで、xは他の関連項目のリストです。一部のエントリには、 "（compare：x）"という形式の発言が含まれています。ここで、xはエントリの反称である場合のいずれかの用語のリストです。
All servicemarks and trademarks that appear in this Glossary are used in an editorial fashion and to the benefit of the mark owner, without any intention of infringement.
この用語集に現れるすべてのServiceMarksと商標は、侵害の意図なしに、編集的な方法とマークの所有者の利益に使用されています。
This Glossary uses the "new" or "logical" punctuation style favored by computer programmers, as described by Raymond [Raym]: Programmers use pairs of quotation marks the same way they use pairs of parentheses, i.e., as balanced delimiters. For example, if "Alice sends" is a phrase, and so are "Bill receives" and "Eve listens", then a programmer would write the following sentence:
この用語集は、Raymond [Raym]：プログラマのペアを使用するのと同じ方法で、すなわちバランスの取れた区切り文字を使用するのと同じ方法で、コンピュータプログラマによって支持されている「新規」または「論理的な」句読点を使用しています。たとえば、「Alice Sends」がフレーズである場合は、「請求書受信」と「EVE Listens」がある場合、プログラマは次の文を書くでしょう。
"Alice sends", "Bill receives", and "Eve listens".
「アリスを送る」、「受取人」、「Eve Listens」。
According to standard American usage, the punctuation in that sentence is incorrect; the continuation commas and the final period should go inside the string quotes, like this:
標準的なアメリカの使用法によると、その文の句読点は正しくありません。継続コンマと最後の期間は、次のように文字列引用符の内側に入るべきです。
"Alice sends," "Bill receives," and "Eve listens."
「アリスを送る」、「受取人」、「eve listens」
However, a programmer would not include a character in a literal string if the character did not belong there, because that could cause an error. For example, suppose a sentence in a draft of a tutorial on the vi editing language looked like this:
ただし、文字がそこに属していなかった場合、プログラマは文字列に文字を含まないであろう。たとえば、vi編集言語に関するチュートリアルのドラフトの文の文をこのように見えたとします。
Then delete one line from the file by typing "dd".
その後、 "dd"を入力してファイルから1行を削除します。
A book editor following standard usage might change the sentence to look like this:
標準使用に続く本エディタは、このようになるように文を変更するかもしれません：
Then delete one line from the file by typing "dd."
次に、「DD」と入力してファイルから1行を削除します。
However, in the vi language, the dot character repeats the last command accepted. So, if a reader entered "dd.", two lines would be deleted instead of one.
ただし、VI言語では、ドット文字は最後に受け入れられたコマンドを繰り返します。したがって、リーダーが "DD"に入った場合は、1行ずつ削除されます。
Similarly, use of standard American punctuation might cause misunderstanding in entries in this Glossary. Thus, the new punctuation is used here, and we recommend it for IDOCs.
同様に、標準的なアメリカの句読点の使用は、この用語集のエントリーの誤解を引き起こす可能性があります。したがって、ここでは新しい句読点が使用されており、IDOCのために推奨します。
Each entry in this Glossary is marked as type I, N, O, or D:
この用語集の各エントリは、タイプI、N、O、またはDとしてマークされています。
The marking "I" indicates two things: - Origin: "I" (as opposed to "N") means either that the Internet Standards Process or Internet community is authoritative for the definition *or* that the term is sufficiently generic that this Glossary can freely state a definition without contradicting a non-Internet authority (e.g., "attack"). - Recommendation: "I" (as opposed to "O") means that the term and definition are RECOMMENDED for use in IDOCs. However, some "I" entries may be accompanied by a "Usage" note that states a limitation (e.g., "certification"), and IDOCs SHOULD NOT use the defined term outside that limited context.
マーキング「i」は、2つのことを示しています。 - 由来：「N」とは対照的に、インターネット標準プロセスまたはインターネットコミュニティが定義*または*という用語がこの用語集で十分に一般的なものであることを意味します。インターネット非インターネット権限に矛盾することなく定義を自由に述べることができます（例：「攻撃」）。 - 推奨事項：「i」（「O」とは対照的に）は、IDOCでの使用に用語と定義が推奨されることを意味します。しかしながら、いくつかの「I」エントリは、制限（例えば、「証明書」）を述べる「使用法」についての注意を伴うことがあり、IDOCはその限られた文脈の外部で定義された用語を使用しないでください。
Many "I" entries are proper nouns (e.g., "Internet Protocol") for which the definition is intended only to provide basic information; i.e., the authoritative definition of such terms is found elsewhere. For a proper noun described as an "Internet protocol", please refer to the current edition of "Internet Official Protocol Standards" (Standard 1) for the standardization status of the protocol.
多くの「I」エントリは、定義が基本情報を提供するためだけに意図されているのが意図されている適切な名詞（例えば、「インターネットプロトコル」）である。すなわち、そのような用語の権威ある定義は他の場所にあります。「インターネットプロトコル」として記載されている適切な名詞の場合は、プロトコルの標準化状況については、現在の「インターネット公式プロトコル標準」（標準1）の現在の版を参照してください。
The marking "N" indicates two things: - Origin: "N" (as opposed to "I") means that the entry has a non-Internet basis or origin. - Recommendation: "N" (as opposed to "O") means that the term and definition are RECOMMENDED for use in IDOCs, if they are needed at all in IDOCs. Many of these entries are accompanied by a label that states a context (e.g., "package") or a note that states a limitation (e.g., "data integrity"), and IDOCs SHOULD NOT use the defined term outside that context or limit. Some of the contexts are rarely if ever expected to occur in an IDOC (e.g., "baggage"). In those cases, the listing exists to make Internet authors aware of the non-Internet usage so that they can avoid conflicts with non-Internet documents.
マーキング「n」は2つのことを示します。 - 原点： "N"（ "i"）は、エントリにインターネットでないか起源があることを意味します。 - 推奨事項：「N」（「O」とは対照的に）は、IDOCで必要な場合は、IDOCでの使用に用語と定義が推奨されることを意味します。これらのエントリの多くは、コンテキスト（例えば、「パッケージ」）を述べるラベル（例えば、「データ整合性」）、およびIDocがそのコンテキストまたは制限の外側で定義された用語を使用しないことを示すラベルを伴う。いくつかの文脈は、IDoc（例えば、「手荷物」）で発生したことが予想された場合にはめったにない。そのような場合、インターネット以外の文書との競合を回避できるように、インターネットの使用者がインターネットではない使用を認識させるためのリストが存在します。
The marking "O" means that the definition is of non-Internet origin and SHOULD NOT be used in IDOCs *except* in cases where the term is specifically identified as non-Internet.
マーキング「O」とは、定義がインターネットではない原点であり、IDOCS *では使用しないでください。
For example, an IDOC might mention "BCA" (see: brand certification authority) or "baggage" as an example of some concept; in that case, the document should specifically say "SET(trademark) BCA" or "SET(trademark) baggage" and include the definition of the term.
たとえば、IDocは「BCA」（ブランド認証局）または「手荷物」の例として、「BCA」と言及することがあります。その場合、文書は「セット（登録商標）BCA」または「セット（登録商標）手荷物」と言うべきであり、その用語の定義を含める必要があります。
If this Glossary recommends that a term or definition SHOULD NOT be used in IDOCs, then the entry is marked as type "D", and an explanatory note -- "Deprecated Term", "Deprecated Abbreviation", "Deprecated Definition", or "Deprecated Usage" -- is provided.
この用語集ではIDocで使用しないでください、そのエントリはタイプ "D"としてマークされ、説明ノート - 「廃止予定語」、「廃止予定略語」、「非推奨定義」、または「」廃止予定の使用法 " - が提供されています。
Some terms have a definition published by a non-Internet authority -- a government (e.g., "object reuse"), an industry (e.g., "Secure Data Exchange"), a national authority (e.g., "Data Encryption Standard"), or an international body (e.g., "data confidentiality") -- that is suitable for use in IDOCs. In those cases, this Glossary marks the definition "N", recommending its use in Internet documents.
いくつかの用語は、インターネット非インターネット当局（例えば、「オブジェクト再利用」）、業界（例えば、「安全なデータ交換」）、国内当局（例えば、「データ暗号化規格」）によって公開されている定義を有する。または国際的な体（例えば、「データ機密性」） - IDocでの使用に適しています。そのような場合、この用語集は定義 "N"をマークし、インターネット文書での使用を推奨します。
Other such terms have definitions that are inadequate or inappropriate for IDOCs. For example, a definition might be outdated or too narrow, or it might need clarification by substituting more careful wording (e.g., "authentication exchange") or explanations, using other terms that are defined in this Glossary. In those cases, this Glossary marks the entry "O", and provides an "I" or "N" entry that precedes, and is intended to supersede, the "O" entry.
その他のそのような用語は、IDOCに不適切または不適切な定義を持っています。たとえば、定義が古くなったり狭すぎたりするか、またはこの用語集に定義されている他の用語を使用して、より慎重な表現（例えば、「認証交換」）や説明を置き換えることによって明確化が必要な場合があります。そのような場合、この用語集はエントリ「o」をマークし、前に「i」または「N」エントリを提供し、「O」エントリを提供することを目的としています。
In some cases where this Glossary provides a definition to supersede an "O" definition, the substitute is intended to subsume the meaning of the "O" entry and not conflict with it. For the term "security service", for example, the "O" definition deals narrowly with only communication services provided by layers in the OSIRM and is inadequate for the full range of IDOC usage, while the new "I" definition provided by this Glossary can be used in more situations and for more kinds of service. However, the "O" definition is also listed so that IDOC authors will be aware of the context in which the term is used more narrowly.
この用語集が「O」の定義を提供するための定義を提供する場合によっては、代替品は「O」エントリの意味をサブ化することを意図しており、それと矛盾しない。たとえば、「セキュリティサービス」という用語の場合、「O」定義は、OSIRMのレイヤーによって提供される通信サービスだけで狭く扱い、IDocの使用状況には不十分ですが、この用語集によって提供された新しい「I」の定義より多くの状況で、そしてさらなるサービスのために使用することができます。ただし、IDocの作者が用語がより狭く使用されているコンテキストを認識するように、 "O"定義もリストされています。
When making substitutions, this Glossary attempts to avoid contradicting any non-Internet authority. Still, terminology differs between authorities such as the American Bar Association, OSI, SET, the U.S. DoD, and other authorities; and this Glossary probably is not exactly aligned with any of them.
置換を行うとき、この用語集はインターネット以外の権限を矛盾しないようにします。それでも、アメリカのバー協会、OSI、セット、米国のDOD、その他の当局などの当局間で用語が異なります。そしてこの用語集はおそらくそれらのいずれかと正確に整列していません。
$ *-property (N) Synonym for "confinement property" in the context of the Bell-LaPadula model. Pronunciation: star property.
$ * -property（n）Bell-Lapadulaモデルのコンテキストにおける「閉じ込めプロパティ」の同義語。発音：スタープロパティ。
$ 3DES (N) See: Triple Data Encryption Algorithm.
$ 3DES（N）：トリプルデータ暗号化アルゴリズムを参照してください。
$ A1 computer system (O) /TCSEC/ See: Tutorial under "Trusted Computer System Evaluation Criteria". (Compare: beyond A1.)
$ A1コンピュータシステム（O）/ TCSEC /参照：「信頼できるコンピュータシステム評価基準」の下のチュートリアル。（比較：A1を超えて。）
$ AA (D) See: Deprecated Usage under "attribute authority".
$ AA（D）「属性局」の下での廃止予定の使用法を参照してください。
$ ABA Guidelines (N) "American Bar Association (ABA) Digital Signature Guidelines" [DSG], a framework of legal principles for using digital signatures and digital certificates in electronic commerce.
$ ABAガイドライン（N）「デジタルシグネチャと電子商取引のデジタル証明書を使用するための法的原則の枠組み「DSG」。
$ Abstract Syntax Notation One (ASN.1) (N) A standard for describing data objects. [Larm, X680] (See: CMS.)
$ 抽象構文表記法1（ASN.1）（n）データオブジェクトを記述するための標準。[LARM、X680]（CMSを参照）
Usage: IDOCs SHOULD use the term "ASN.1" narrowly to describe the notation or language called "Abstract Syntax Notation One". IDOCs MAY use the term more broadly to encompass the notation, its associated encoding rules (see: BER), and software tools that assist in its use, when the context makes this meaning clear.
使用法：IDOCは「ASN.1」という用語を狭く使用して、「抽象構文表記法1」と呼ばれる表記または言語を説明する必要があります。IDocは、表記を網羅するために、その用語をより広く使用して、その使用を意味するときにその使用を支援するソフトウェアツールを包含して、その使用が明確にする場合があります。
Tutorial: OSIRM defines computer network functionality in layers. Protocols and data objects at higher layers are abstractly defined to be implemented using protocols and data objects from lower layers. A higher layer may define transfers of abstract objects between computers, and a lower layer may define those transfers concretely as strings of bits. Syntax is needed to specify data formats of abstract objects, and encoding rules are needed to transform abstract objects into bit strings at lower layers. OSI standards use ASN.1 for those specifications and use various encoding rules for those transformations. (See: BER.)
チュートリアル：OSIRRはレイヤー内のコンピュータネットワーク機能を定義します。上位層のプロトコルとデータオブジェクトは、下位レイヤーからプロトコルとデータオブジェクトを使用して実装されるように抽象的に定義されています。より高い層は、コンピュータ間の抽象オブジェクトの転送を定義し、下位層はビットの文字列としてそれらの転送を具体的に定義することができる。構文は抽象オブジェクトのデータフォーマットを指定するために必要であり、抽象オブジェクトを下位レイヤのビット文字列に変換するために符号化規則が必要です。OSI規格はこれらの仕様にASN.1を使用し、それらの変換にさまざまなエンコード規則を使用します。（参照：BER。）
In ASN.1, formal names are written without spaces, and separate words in a name are indicated by capitalizing the first letter of each word except the first word. For example, the name of a CRL is "certificateRevocationList".
ASN.1では、正式な名前はスペースなしで書かれており、名前の別の単語は、最初の単語を除く各単語の最初の文字を大文字にすることによって示されます。たとえば、CRLの名前は "certificateRevocationList"です。
$ ACC (I) See: access control center.
$ ACC（I）アクセスコントロールセンターを参照してください。
$ acceptable risk (I) A risk that is understood and tolerated by a system's user, operator, owner, or accreditor, usually because the cost or difficulty of implementing an effective countermeasure for the associated vulnerability exceeds the expectation of loss. (See: adequate security, risk, "second law" under "Courtney's laws".)
$ 許容されるリスク（i）システムのユーザー、オペレーター、所有者、または認定者によって理解され許容される危険性は、通常、関連する脆弱性のための効果的な対策を実行することの費用や困難が損失の期待を超えるためです。（「コートニーの法律」の「適切なセキュリティ、リスク、「第2法」）。）
$ access 1a. (I) The ability and means to communicate with or otherwise interact with a system to use system resources either to handle information or to gain knowledge of the information the system contains. (Compare: handle.)
$ アクセス1a。（i）情報を処理するため、またはシステムに含まれる情報の知識を得るためにシステムリソースを使用するためにシステムと通信するか、そうでなければ対話することができる能力と手段。（比較：ハンドル。）
Usage: The definition is intended to include all types of communication with a system, including one-way communication in either direction. In actual practice, however, passive users might be treated as not having "access" and, therefore, be exempt from most requirements of the system's security policy. (See: "passive user" under "user".)
使用法：定義は、どちらの方向への一方向通信を含む、システムとのすべてのタイプの通信を含むことを目的としています。しかしながら、実際の慣習では、パッシブユーザは「アクセス」を持たないと扱われる可能性があり、したがってシステムのセキュリティポリシーのほとんどの要件から免除される可能性があります。（「ユーザー」の下にある「パッシブユーザー」を参照してください。）
1b. (O) "Opportunity to make use of an information system (IS) resource." [C4009]
1b。（O）「情報システム（IS）リソースを利用する機会」[C4009]
2. (O) /formal model/ "A specific type of interaction between a subject and an object that results in the flow of information from one to the other." [NCS04]
2. （O）/正式モデル/「対象と他方から情報の流れをもたらす対象との間の特定の種類の対話。[NCS04]
$ Access Certificate for Electronic Services (ACES) (O) A PKI operated by the U.S. Government's General Services Administration in cooperation with industry partners. (See: CAM.)
$ 電子サービスのためのアクセス証明書（ACE）（O）業界パートナーと協力して米国政府の一般サービス管理によって運営されているPKI。（参照：カム。）
$ access control 1. (I) Protection of system resources against unauthorized access.
$ アクセス制御1.（i）不正アクセスに対するシステムリソースの保護。
2. (I) A process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy. (See: access, access control service, computer security, discretionary access control, mandatory access control, role-based access control.)
2. （i）システムリソースの使用がセキュリティポリシーに従って規制され、そのポリシーに従って許可されたエンティティ（ユーザ、プログラム、プロセス、またはその他のシステム）によってのみ許可されています。（アクセス、アクセス制御サービス、コンピュータセキュリティ、任意アクセス制御、必須アクセス制御、ロールベースのアクセス制御）
3. (I) /formal model/ Limitations on interactions between subjects and objects in an information system.
3. （i）/情報システム内の対象と物体間の相互作用の/正式なモデル/制限
4. (O) "The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner." [I7498-2]
4. （O）「資源の使用防止方法を含むリソースの不正使用防止」。[I7498-2]
5. (O) /U.S. Government/ A system using physical, electronic, or human controls to identify or admit personnel with properly authorized access to a SCIF.
5. （O）/U.S。政府/身体的、電子的、または人間のコントロールを使用して、担当者が正しく認証されたSCIFへのアクセス権を承認または認めること。
$ access control center (ACC) (I) A computer that maintains a database (possibly in the form of an access control matrix) defining the security policy for an access control service, and that acts as a server for clients requesting access control decisions.
$ アクセス制御センター（ACC）（i）アクセス制御サービスのセキュリティポリシーを定義するデータベース（おそらくアクセス制御行列の形式で）を維持し、アクセス制御の決定を要求するクライアントとして機能するコンピュータ。
Tutorial: An ACC is sometimes used in conjunction with a key center to implement access control in a key-distribution system for symmetric cryptography. (See: BLACKER, Kerberos.)
チュートリアル：ACCは、対称暗号化のための鍵配布システムでアクセス制御を実装するためにキーセンターと組み合わせて使用されることがあります。（参照：ブラック、Kerberos。）
$ access control list (ACL) (I) /information system/ A mechanism that implements access control for a system resource by enumerating the system entities that are permitted to access the resource and stating, either implicitly or explicitly, the access modes granted to each entity. (Compare: access control matrix, access list, access profile, capability list.)
$ アクセス制御リスト（I）/情報システム/情報システム/システムリソースのアクセス制御を実装し、暗黙的または明示的に各エンティティに付与されたアクセスモードを列挙することによってシステムリソースのアクセス制御を実装するメカニズム。（比較：アクセス制御マトリックス、アクセスリスト、アクセスプロファイル、機能リスト）
$ access control matrix (I) A rectangular array of cells, with one row per subject and one column per object. The entry in a cell -- that is, the entry for a particular subject-object pair -- indicates the access mode that the subject is permitted to exercise on the object. Each column is equivalent to an "access control list" for the object; and each row is equivalent to an "access profile" for the subject.
$ ACCESS制御行列（I）件数ごとに1行、オブジェクトごとに1列のセルの長方形のセルの配列。セル内のエントリ - つまり、特定の件名オブジェクトペアのエントリは、対象がオブジェクトに対して行動することが許可されているアクセスモードを示します。各列は、オブジェクトの「アクセス制御リスト」と同じです。そして、各行は、件名の「アクセスプロファイル」と同じです。
$ access control service (I) A security service that protects against a system entity using a system resource in a way not authorized by the system's security policy. (See: access control, discretionary access control, identity-based security policy, mandatory access control, rule-based security policy.)
$ アクセス制御サービス（i）システムのセキュリティポリシーによって許可されていない方法でシステムリソースを使用してシステムエンティティを保護するセキュリティサービス。（アクセス制御、任意アクセス制御、IDベースのセキュリティポリシー、必須アクセス制御、ルールベースのセキュリティポリシー）
Tutorial: This service includes protecting against use of a resource in an unauthorized manner by an entity (i.e., a principal) that is authorized to use the resource in some other manner. (See: insider.) The two basic mechanisms for implementing this service are ACLs and tickets.
チュートリアル：このサービスは、他の方法でリソースを使用することを許可されているエンティティ（すなわちプリンシパル）によって、リソースの使用に対する保護を許可されていない方法で保護することを含む。（インサイダーを参照）このサービスを実装するための2つの基本メカニズムはACLとチケットです。
$ access level 1. (D) Synonym for the hierarchical "classification level" in a security level. [C4009] (See: security level.)
$ アクセスレベル1.（d）セキュリティレベルで階層的な「分類レベル」の同義語。[C4009]（セキュリティレベルを参照）
2. (D) Synonym for "clearance level".
2. （d）「クリアランスレベル」の同義語。
Deprecated Definitions: IDOCs SHOULD NOT use this term with these definitions because they duplicate the meaning of more specific terms. Any IDOC that uses this term SHOULD provide a specific definition for it because access control may be based on many attributes other than classification level and clearance level.
廃止予定の定義：IDocは、それらがより具体的な用語の意味を複製するため、この用語をこれらの定義で使用しないでください。この用語を使用するIDocは、アクセス制御が分類レベルおよびクリアランスレベル以外の多くの属性に基づいている可能性があるため、特定の定義を提供する必要があります。
$ access list (I) /physical security/ Roster of persons who are authorized to enter a controlled area. (Compare: access control list.)
$ アクセスリスト（I）/物理的なセキュリティ/名簿が管理されていることを許可されている人の事業者の事業者の事業者。（比較：アクセス制御リスト）
$ access mode (I) A distinct type of data processing operation (e.g., read, write, append, or execute, or a combination of operations) that a subject can potentially perform on an object in an information system. [Huff] (See: read, write.)
$ アクセスモード（i）被写体が情報システム内のオブジェクト上で潜在的に実行できるように、異なる種類のデータ処理動作（例えば、読み出し、書き込み、追加、実行、または操作の組み合わせ）。[huff]（参照：読み、書く。）
$ access policy (I) A kind of "security policy". (See: access, access control.)
$ アクセスポリシー（i）一種の「セキュリティポリシー」。（「アクセス・アクセス制御」を参照）
$ access profile (O) Synonym for "capability list".
$ アクセスプロファイル（O）「機能リスト」の同義語。
Usage: IDOCs that use this term SHOULD state a definition for it because the definition is not widely known.
使用法：定義が広く知られていないため、この用語を使用するIDocは、定義を定義します。
$ access right (I) Synonym for "authorization"; emphasizes the possession of the authorization by a system entity.
$ アクセス権（i）「承認」の同義語。システムエンティティによる承認の所有を強調します。
$ accountability (I) The property of a system or system resource that ensures that the actions of a system entity may be traced uniquely to that entity, which can then be held responsible for its actions. [Huff] (See: audit service.)
$ 説明責任（i）システムエンティティの動作がそのエンティティに対して一意にトレースされていることを保証するシステムリソースまたはシステムリソースのプロパティは、そのアクションに対して責任を負うことができます。[huff]（監査サービスを参照してください。）
Tutorial: Accountability (a.k.a. individual accountability) typically requires a system ability to positively associate the identity of a user with the time, method, and mode of the user's access to the system. This ability supports detection and subsequent investigation of security breaches. Individual persons who are system users are held accountable for their actions after being notified of the rules of behavior for using the system and the penalties associated with violating those rules.
チュートリアル：説明責任（A.K.A.個々の説明責任）は通常、ユーザーの識別情報をユーザーのシステムへのユーザーのアクセスの時間、方法、およびモードに積極的に関連付けるシステム能力を必要とする。この能力は、セキュリティ違反の検出とその後の調査をサポートしています。システムユーザーである個人は、システムを使用した行動規則とそれらの規則に違反することに関連した罰則を通知した後に、その行動に責任があります。
$ accounting See: COMSEC accounting.
$ 会計：COMSECアカウンティング
$ accounting legend code (ALC) (O) /U.S. Government/ Numeric system used to indicate the minimum accounting controls required for items of COMSEC material within the CMCS. [C4009] (See: COMSEC accounting.)
$ 会計伝説コード（ALC）/U.S。政府/数値システムCMCS内のCOMSEC材料の項目に必要な最小の会計管理を示すために使用されます。[C4009]（COMSECアカウンティング参照）
$ accreditation (N) An administrative action by which a designated authority declares that an information system is approved to operate in a particular security configuration with a prescribed set of safeguards. [FP102, SP37] (See: certification.)
$ 認定（n）指定された権限が、情報システムが特定のセキュリティ構成で動作することを承認されていると宣言された管理行為は、規定のセーフガードのセットを承認します。[FP102、SP37]（認証参照）
Tutorial: An accreditation is usually based on a technical certification of the system's security mechanisms. To accredit a system, the approving authority must determine that any residual risk is an acceptable risk. Although the terms "certification" and "accreditation" are used more in the U.S. DoD and other U.S. Government agencies than in commercial organizations, the concepts apply any place where managers are required to deal with and accept responsibility for security risks. For example, the American Bar Association is developing accreditation criteria for CAs.
チュートリアル：認定は通常、システムのセキュリティメカニズムの技術認証に基づいています。システムを承認するために、承認された権限は残余リスクが許容できるリスクであると判断しなければなりません。「認証」および「認定」という用語は、商業組織よりも米国のDODおよび他の米国政府機関でもっと使用されていますが、概念は管理者がセキュリティリスクに対する責任と責任を負うために必要な場所を適用します。たとえば、アメリカのバーの協会はCASの認定基準を開発しています。
$ accreditation boundary (O) Synonym for "security perimeter". [C4009]
$ 認定境界（O）「セキュリティ周辺」の同義語。[C4009]
$ accreditor (N) A management official who has been designated to have the formal authority to "accredit" an information system, i.e., to authorize the operation of, and the processing of sensitive data in, the system and to accept the residual risk associated with the system. (See: accreditation, residual risk.)
$ Accreditor（N）情報システムの正式な権限を「AccreDit」、すなわち、システムの操作を承認するための正式な権限、すなわち機密データの処理、および関連する残余リスクを受け入れるように指定された管理者。システム。（認定、リスクの残留リスクを参照してください。）
$ ACES (O) See: Access Certificate for Electronic Services.
$ ACES（O）電子サービスのアクセス証明書を参照してください。
$ ACL (I) See: access control list.
$ ACL（i）アクセス制御リストを参照してください。
$ acquirer 1. (O) /SET/ "The financial institution that establishes an account with a merchant and processes payment card authorizations and payments." [SET1]
$ Acquirer 1.（O）/ SET /「マーチャントでアカウントを確立し、支払いカードの承認と支払いを処理する金融機関」。[SET1]
2. (O) /SET/ "The institution (or its agent) that acquires from the card acceptor the financial data relating to the transaction and initiates that data into an interchange system." [SET2]
2. （O）/ SET /「カード受領者から取得した機関（またはその代理店）は、取引に関する財務データを取得し、そのデータを交換システムに開始します。」[SET2]
$ activation data (N) Secret data, other than keys, that is required to access a cryptographic module. (See: CIK. Compare: initialization value.)
$ アクティベーションデータ（n）暗号化モジュールにアクセスするために必要なキー以外の秘密データ。（以下を参照してください。比較：初期化値を比較してください。）
$ active attack (I) See: secondary definition under "attack".
$ アクティブ攻撃（I）「攻撃」の下の二次定義を参照してください。
$ active content 1a. (I) Executable software that is bound to a document or other data file and that executes automatically when a user accesses the file, without explicit initiation by the user. (Compare: mobile code.)
$ アクティブコンテンツ1A。（i）文書または他のデータファイルにバインドされ、ユーザがユーザが明示的に開始することなく、ユーザがファイルにアクセスしたときに自動的に実行される実行可能ソフトウェア。（比較：モバイルコード。）
Tutorial: Active content can be mobile code when its associated file is transferred across a network.
チュートリアル：関連するファイルがネットワークを介して転送されると、アクティブなコンテンツはモバイルコードになる可能性があります。
1b. (O) "Electronic documents that can carry out or trigger actions automatically on a computer platform without the intervention of a user. [This technology enables] mobile code associated with a document to execute as the document is rendered." [SP28]
1b。（O） "ユーザを介しずにコンピュータプラットフォーム上で動作を自動的に実行またはトリガすることができる電子文書。[このテクノロジ]ドキュメントとして実行するために実行される文書に関連付けられているモバイルコードがレンダリングされます。」[SP28]
$ active user (I) See: secondary definition under "system user".
$ アクティブユーザー（i）「システムユーザー」の下のセカンダリ定義。
$ active wiretapping (I) A wiretapping attack that attempts to alter data being communicated or otherwise affect data flow. (See: wiretapping. Compare: active attack, passive wiretapping.)
$ アクティブな盗聴（I）通信中またはその他の方法でデータフローに影響を与えることを試みる盗聴攻撃。（盗聴：Active Attack、Passive Wirepapping。）
$ add-on security (N) The retrofitting of protection mechanisms, implemented by hardware or software, in an information system after the system has become operational. [FP039] (Compare: baked-in security.)
$ アドオンセキュリティ（n）システムが動作可能になった後に、情報システムで、ハードウェアまたはソフトウェアによって実装された保護メカニズムの後処理。[FP039]（比較：焼き止めセキュリティ。）
$ adequate security (O) /U.S. DoD/ "Security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information." (See: acceptable risk, residual risk.)
$ 適切なセキュリティ（O）/U.S。DOD /「セキュリティは、損失、誤用、または情報の修正によるアクセスまたは修正されたアクセスによる危害の危害と大きさに対応しています。」（：許容されるリスク、残留リスク。）
$ administrative security 1. (I) Management procedures and constraints to prevent unauthorized access to a system. (See: "third law" under "Courtney's laws", manager, operational security, procedural security, security architecture. Compare: technical security.)
$ 管理セキュリティ1.（i）システムへの不正アクセスを防ぐための管理手順と制約。（「Courtney's Laws」、マネージャー、業務セキュリティ、手続きセキュリティ、セキュリティアーキテクチャの下の「第三法則」。比較：技術的セキュリティ。）
Examples: Clear delineation and separation of duties; configuration control.
例：明確な描写と職務の分離。構成制御
Usage: Administrative security is usually understood to consist of methods and mechanisms that are implemented and executed primarily by people, rather than by automated systems.
使用法：管理セキュリティは通常、自動化されたシステムではなく、主に人々によって実装され実行されたメソッドとメカニズムで構成されています。
2. (O) "The management constraints, operational procedures, accountability procedures, and supplemental controls established to provide an acceptable level of protection for sensitive data." [FP039]
2. （O） "管理制約、運用手順、説明責任手順、および補足制御は、機密データのための許容可能な保護レベルを提供するために確立された補足的なコントロール。」[FP039]
$ administrator 1. (O) /Common Criteria/ A person that is responsible for configuring, maintaining, and administering the TOE in a correct manner for maximum security. (See: administrative security.)
$ 管理者1.（O）/共通基準/最大限のセキュリティのために正しい方法でTOEの設定、維持、管理を担当する人。（：管理セキュリティを参照してください。）
2. (O) /ITSEC/ A person in contact with the TOE, who is responsible for maintaining its operational capability.
2. （O）/ ITSEC / TOEと接触している人、その運用能力を維持する責任があります。
$ Advanced Encryption Standard (AES) (N) A U.S. Government standard [FP197] (the successor to DES) that (a) specifies "the AES algorithm", which is a symmetric block cipher that is based on Rijndael and uses key sizes of 128, 192, or 256 bits to operate on a 128-bit block, and (b) states policy for using that algorithm to protect unclassified, sensitive data.
$ 高度な暗号化規格（AES）（N）米国政府標準[FP197]（A）は、Rijndaelに基づく対称ブロック暗号であり、キーサイズを使用する「AESアルゴリズム」を指定し、128のキーサイズを使用する。、192、または256ビット、または256ビットは128ビットブロックで動作し、（b）そのアルゴリズムを使用して、未分類の機密データを保護するためのポリシーのポリシー。
Tutorial: Rijndael was designed to handle additional block sizes and key lengths that were not adopted in the AES. Rijndael was selected by NIST through a public competition that was held to find a successor to the DEA; the other finalists were MARS, RC6, Serpent, and Twofish.
チュートリアル：Rijndaelは、AESで採用されていなかった追加のブロックサイズとキー長を処理するように設計されていました。Rijndaelは、DEAの後継者を見つけるために開催された公共の競争を通じてNISTによって選択されました。他のファイナリストは火星、rc6、蛇、そして二曲でした。
$ adversary 1. (I) An entity that attacks a system. (Compare: cracker, intruder, hacker.)
$ 敵対者1.（i）システムを攻撃するエンティティ。（Chasker、Intruder、Hacker。）
2. (I) An entity that is a threat to a system.
2. （i）システムへの脅威であるエンティティ。
$ AES (N) See: Advanced Encryption Standard.
$ AES（N）は、高度な暗号化規格を参照してください。
$ Affirm (O) A formal methodology, language, and integrated set of software tools developed at the University of Southern California's Information Sciences Institute for specifying, coding, and verifying software to produce correct and reliable programs. [Cheh]
$ 南カリフォルニア州情報科学研究所で開発された正式な方法論、言語、および統合されたセットは、正しい、信頼性の高いプログラムを作成するためのソフトウェアを作成、コーディング、および検証するためのソフトウェアツールの統合されたセットです。[Cheh]
$ aggregation (I) A circumstance in which a collection of information items is required to be classified at a higher security level than any of the items is classified individually. (See: classification.)
$ 集約（i）情報項目の収集を必要な項目よりも高いセキュリティレベルで分類する必要がある状況は、個別に分類されています。（分類を参照してください。）
$ AH (I) See: Authentication Header
$ ああ（i）認証ヘッダーを参照してください
$ air gap (I) An interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control). (See: sneaker net. Compare: gateway.)
$ エアギャップ（i）それらが物理的に接続されていない（a）2つのシステム間のインタフェースは、任意の論理接続が自動化されていない（すなわち、データは、人間の制御下で手動でのみ手動でのみ転送される）。（：スニーカーネット。比較：ゲートウェイ。）
Example: Computer A and computer B are on opposite sides of a room. To move data from A to B, a person carries a disk across the room. If A and B operate in different security domains, then moving data across the air gap may involve an upgrade or downgrade operation.
例：コンピュータAとコンピュータBは部屋の反対側にあります。AからBへデータを移動するために、人は部屋を横切ってディスクを運びます。AとBが異なるセキュリティドメインで動作する場合は、エアギャップを介してデータを移動すると、アップグレードまたはダウングレード操作が含まれます。
$ ALC (O) See: accounting legend code.
$ alc（o）は、会計伝説コードを参照してください。
$ algorithm (I) A finite set of step-by-step instructions for a problem-solving or computation procedure, especially one that can be implemented by a computer. (See: cryptographic algorithm.)
$ アルゴリズム（i）問題解決または計算手順のためのステップバイステップの命令の有限セット、特にコンピュータによって実装することができるもの。（暗号化アルゴリズムを参照してください。）
$ alias (I) A name that an entity uses in place of its real name, usually for the purpose of either anonymity or masquerade.
$ 別名（i）エンティティがその実名の代わりに使用する名前、通常は匿名性またはマスカレードのどちらかを目的としています。
$ Alice and Bob (I) The parties that are most often called upon to illustrate the operation of bipartite security protocols. These and other dramatis personae are listed by Schneier [Schn].
$ アリスとボブ（i）バイパリットセキュリティプロトコルの動作を説明するために最も頻繁に呼ばれる当事者。これらおよび他のDramatis PersoneaeはシュナリエのSchnier [Schn]によってリストされています。
$ American National Standards Institute (ANSI) (N) A private, not-for-profit association that administers U.S. private-sector voluntary standards.
$ American National Standards Institute（ansi）（n）米国の民間部門の自発的基準を管理するプライベートでありません非営利団体。
Tutorial: ANSI has approximately 1,000 member organizations, including equipment users, manufacturers, and others. These include commercial firms, governmental agencies, and other institutions and international entities.
チュートリアル：ANSIには、機器ユーザー、製造業者などを含む約1,000人の会員組織があります。これらには、商業企業、政府機関、その他の機関や国際事業体が含まれます。
ANSI is the sole U.S. representative to (a) ISO and (b) (via the U.S. National Committee) the International Electrotechnical Commission (IEC), which are the two major, non-treaty, international standards organizations.
ANSIは、（a）ISOおよび（B）（米国国家委員会を介して）（米国国家委員会を介して）国際電気工学委員会（IEC）を代表しています。
ANSI provides a forum for ANSI-accredited standards development groups. Among those groups, the following are especially relevant to Internet security: - International Committee for Information Technology Standardization (INCITS) (formerly X3): Primary U.S. focus of standardization in information and communications technologies, encompassing storage, processing, transfer, display, management, organization, and retrieval of information. Example: [A3092]. - Accredited Standards Committee X9: Develops, establishes, maintains, and promotes standards for the financial services industry. Example: [A9009]. - Alliance for Telecommunications Industry Solutions (ATIS): Develops standards, specifications, guidelines, requirements, technical reports, industry processes, and verification tests for interoperability and reliability of telecommunications networks, equipment, and software. Example: [A1523].
ANSIは、ANSI認定標準開発グループのフォーラムを提供しています。これらのグループの中では、インターネットセキュリティに関する特に関連性があります。組織、および情報の検索例：[A3092]。 - 認定標準委員会X9：金融サービス業界の基準を開発、設立、維持、および促進する。例：[A9009]。 - 電気通信業界ソリューション（ATIS）のアライアンス：電気通信ネットワーク、機器、およびソフトウェアの相互運用性と信頼性のための標準、仕様、ガイドライン、要件、技術報告、業界プロセス、および検証試験を開発しています。例：[A1523]。
$ American Standard Code for Information Interchange (ASCII) (N) A scheme that encodes 128 specified characters -- the numbers 0-9, the letters a-z and A-Z, some basic punctuation symbols, some control codes that originated with Teletype machines, and a blank space -- into the 7-bit binary integers. Forms the basis of the character set representations used in most computers and many Internet standards. [FP001] (See: code.)
$ インターチェンジ（ASCII）のアメリカ標準コード（n）指定された文字の1つの文字 - 数値0から9、文字AZ、AZ、いくつかの基本的な句読記号、テレタイプマシンで発信された一部の制御コード、および空白スペース - 7ビットのバイナリ整数に。ほとんどのコンピュータおよび多くのインターネット規格で使用されている文字セット表現の基礎を形成します。[FP001]（コードを参照してください。）
$ Anderson report (O) A 1972 study of computer security that was written by James P. Anderson for the U.S. Air Force [Ande].
$ Anderson Report（O）米国空軍[Ande]のJames P.Andersonによって書かれたコンピュータセキュリティに関する1972年。
Tutorial: Anderson collaborated with a panel of experts to study Air Force requirements for multilevel security. The study recommended research and development that was urgently needed to provide secure information processing for command and control systems and support systems. The report introduced the reference monitor concept and provided development impetus for computer and network security technology. However, many of the security problems that the 1972 report called "current" still plague information systems today.
チュートリアル：Andersonは、マルチレベルセキュリティのための空軍要件を研究するために専門家のパネルと協力しました。この研究は、コマンドおよび制御システムおよびサポートシステムのための安全な情報処理を提供するために緊急に必要とされた研究開発を推奨した。報告書は、参照モニタの概念を紹介し、コンピュータおよびネットワークセキュリティ技術の開発推進力を提供しました。ただし、1972年のレポートが「現在の」と呼ばれるセキュリティ上の問題の多くは、今日の情報システムを悩ませます。
$ anomaly detection (I) An intrusion detection method that searches for activity that is different from the normal behavior of system entities and system resources. (See: IDS. Compare: misuse detection.)
$ 異常検出（i）システムエンティティとシステムリソースの通常の動作とは異なる活動を検索する侵入検知方法。（IDS。比較：誤用検出。）
$ anonymity (I) The condition of an identity being unknown or concealed. (See: alias, anonymizer, anonymous credential, anonymous login, identity, onion routing, persona certificate. Compare: privacy.)
$ 匿名性（i）不明または隠されているアイデンティティの状態。（エイリアス、匿名化計、匿名の信任状、匿名ログイン、ID、玉石ルーティング、PersonA証明書。比較：プライバシー。）
Tutorial: An application may require security services that maintain anonymity of users or other system entities, perhaps to preserve their privacy or hide them from attack. To hide an entity's real name, an alias may be used; for example, a financial institution may assign account numbers. Parties to transactions can thus remain relatively anonymous, but can also accept the transactions as legitimate. Real names of the parties cannot be easily determined by observers of the transactions, but an authorized third party may be able to map an alias to a real name, such as by presenting the institution with a court order. In other applications, anonymous entities may be completely untraceable.
チュートリアル：アプリケーションでは、ユーザーまたは他のシステムエンティティの匿名性を維持するセキュリティサービスが必要になる場合があります。エンティティの本名を非表示にするために、エイリアスを使用することができます。たとえば、金融機関は口座番号を割り当てることがあります。したがって、取引の当事者は比較的匿名のままであり得るが、トランザクションを正当なものとして受け入れることもできる。当事者の実名は、取引の観察者によって容易に決定することはできませんが、執行された第三者は、機関を裁判所の順序で提示するなど、別名を実際の名前にマッピングできる可能性があります。他のアプリケーションでは、匿名エンティティは完全に追跡できない可能性があります。
$ anonymizer (I) An internetwork service, usually provided via a proxy server, that provides anonymity and privacy for clients. That is, the service enables a client to access servers (a) without allowing anyone to gather information about which servers the client accesses and (b) without allowing the accessed servers to gather information about the client, such as its IP address.
$匿名化装置（i）通常、プロキシサーバーを介して提供されるインターネットワークサービス。クライアントの匿名性とプライバシーを提供します。すなわち、サービスは、アクセスしたサーバがそのIPアドレスなどのクライアントに関する情報を収集することなく、誰かがクライアントにアクセスし、（B）の情報を収集することなく、クライアントがサーバにアクセスすることを可能にする。
$ anonymous credential (D) /U.S. Government/ A credential that (a) can be used to authenticate a person as having a specific attribute or being a member of a specific group (e.g., military veterans or U.S. citizens) but (b) does not reveal the individual identity of the person that presents the credential. [M0404] (See: anonymity.)
$ 匿名信任状（D）/U.S。政府/（a）の信任状は、特定の属性を持つこと、または特定のグループ（例えば、軍事退役軍人または米国市民）のメンバーであることを人を認証するために使用することができますが、（b）人の個々のアイデンティティを明らかにしていないそれは資格情報を提示します。[M0404]（匿名性を参照）
Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts in a potentially misleading way. For example, when the credential is an X.509 certificate, the term could be misunderstood to mean that the certificate was signed by a CA that has a persona certificate. Instead, use "attribute certificate", "organizational certificate", or "persona certificate" depending on what is meant, and provide additional explanations as needed.
廃止予定語：IDocsはこの用語を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。たとえば、信任状がX.509証明書の場合、その用語は、証明書がPersona証明書を持つCAによって署名されたことを意味するように誤解される可能性があります。代わりに、何をしている内容に応じて「属性証明書」、「組織証明書」、「PERSEA証明書」を使用し、必要に応じて追加の説明を提供します。
$ anonymous login (I) An access control feature (actually, an access control vulnerability) in many Internet hosts that enables users to gain access to general-purpose or public services and resources of a host (such as allowing any user to transfer data using FTP) without having a pre-established, identity-specific account (i.e., user name and password). (See: anonymity.)
$ 匿名ログイン（i）多くのインターネットホスト内のアクセス制御機能（実際、アクセス制御の脆弱性）は、ユーザーがホストの汎用または公共サービスおよびリソースにアクセスできるようにする（ユーザーがFTPを使用してデータを転送できるようにするなど）。事前に確立されたアイデンティティ固有のアカウント（つまり、ユーザー名とパスワード）を持たずに）。（匿名性を参照してください。）
Tutorial: This feature exposes a system to more threats than when all the users are known, pre-registered entities that are individually accountable for their actions. A user logs in using a special, publicly known user name (e.g., "anonymous", "guest", or "ftp"). To use the public login name, the user is not required to know a secret password and may not be required to input anything at all except the name. In other cases, to complete the normal sequence of steps in a login protocol, the system may require the user to input a matching, publicly known password (such as "anonymous") or may ask the user for an e-mail address or some other arbitrary character string.
チュートリアル：この機能は、すべてのユーザーが既知の場合よりも多くの脅威にシステムを公開しています。ユーザーは、特別な公的に既知のユーザー名（例えば、「匿名」、「ゲスト」、または「FTP」）を使用してログインします。パブリックログイン名を使用するには、ユーザーは秘密のパスワードを知る必要はなく、名前以外のものをすべて入力する必要はないかもしれません。他の場合には、ログインプロトコル内の通常のステップのシーケンスを完了するために、システムは、ユーザがマッチング、公知のパスワードを入力すること（「匿名」）を入力することを要求しているか、またはユーザに電子メールアドレスまたは一部をユーザに尋ねることがある。その他の任意の文字列。
$ ANSI (N) See: American National Standards Institute.
$ ANSI（N）参照：アメリカの国家規格研究所。
$ anti-jam (N) "Measures ensuring that transmitted information can be received despite deliberate jamming attempts." [C4009] (See: electronic security, frequency hopping, jam, spread spectrum.)
$ 故意のジャミング試行にもかかわらず、送信された情報を受信できるようにする対策。」[C4009]（電子セキュリティ、周波数ホッピング、ジャム、スペクトルスペクトル）
$ apex trust anchor (N) The trust anchor that is superior to all other trust anchors in a particular system or context. (See: trust anchor, top CA.)
$ Apex Trust Anchor（N）特定のシステムやコンテキストの他のすべての信託アンカーより優れている信託アンカー。（参照：信託アンカー、トップCA.）
$ API (I) See: application programming interface.
$ API（i）アプリケーションプログラミングインタフェースを参照してください。
$ APOP (I) See: POP3 APOP.
$ apop（i）POP3 APOPを参照してください。
$ Application Layer See: Internet Protocol Suite, OSIRM.
$ アプリケーション層参照：インターネットプロトコルスイート、OSIRM。
$ application program (I) A computer program that performs a specific function directly for a user (as opposed to a program that is part of a computer operating system and exists to perform functions in support of application programs).
$ アプリケーションプログラム（i）ユーザに直接特定の機能を実行するコンピュータプログラム（コンピュータオペレーティングシステムの一部であり、アプリケーションプログラムのサポートに機能を実行するための機能を実行するためのプログラムとは対照的に）。
$ architecture (I) See: security architecture, system architecture.
$ アーキテクチャ（i）セキュリティアーキテクチャ、システムアーキテクチャ。
$ archive 1a. (I) /noun/ A collection of data that is stored for a relatively long period of time for historical and other purposes, such as to support audit service, availability service, or system integrity service. (Compare: backup, repository.)
$ アーカイブ1A。（i）/名詞/監査サービス、可用性サービス、またはシステム整合性サービスをサポートするなど、履歴およびその他の目的のために比較的長期間保存されているデータのコレクション。（比較：バックアップ、リポジトリ。）
1b. (I) /verb/ To store data in such a way as to create an archive. (Compare: back up.)
1b。（i）/動詞/アーカイブを作成するようにデータを格納する。（比較：バックアップ。）
Tutorial: A digital signature may need to be verified many years after the signing occurs. The CA -- the one that issued the certificate containing the public key needed to verify that signature -- may not stay in operation that long. So every CA needs to provide for long-term storage of the information needed to verify the signatures of those to whom it issues certificates.
チュートリアル：署名が発生してから長年にわたるデジタル署名を検証する必要があるかもしれません。CA - その署名を検証するために必要な公開鍵を含む証明書を発行したもの - 長さに滞在しない場合があります。そのため、すべてのCAは、証明書を発行するものの署名を検証するために必要な情報を長期保存する必要があります。
$ ARPANET (I) Advanced Research Projects Agency (ARPA) Network, a pioneer packet-switched network that (a) was designed, implemented, operated, and maintained by BBN from January 1969 until July 1975 under contract to the U.S. Government; (b) led to the development of today's Internet; and (c) was decommissioned in June 1990. [B4799, Hafn]
$ Arpanet（i）先端研究プロジェクト機構（A）は、1969年1月から1975年7月までの米国政府に契約して、（A）が設計、実施、運営、管理され、実施、実施、維持されたパイオニアパケット交換ネットワーク。（b）今日のインターネットの開発につながりました。（c）は1990年6月に廃止されました。[B4799、HAFN]
$ ASCII (N) See: American Standard Code for Information Interchange.
$ ASCII（N）情報インターチェンジのためのアメリカの標準コード。
$ ASN.1 (N) See: Abstract Syntax Notation One.
$ ASN.1（n）参照：抽象構文表記法1。
$ asset (I) A system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission.
$ 資産（i）情報システムのセキュリティポリシーによって保護されることが必要なシステムリソース、（B）は対策によって保護されることを意図した、またはシステムの任務に必要な（C）を意図しています。
$ association (I) A cooperative relationship between system entities, usually for the purpose of transferring information between them. (See: security association.)
$ 関連付け（i）システムエンティティ間の協調関係は、通常それらの間で情報を転送する目的で。（セキュリティ協会を参照してください。）
$ assurance See: security assurance.
$ 保証参照：セキュリティ保証
$ assurance level (N) A rank on a hierarchical scale that judges the confidence someone can have that a TOE adequately fulfills stated security requirements. (See: assurance, certificate policy, EAL, TCSEC.)
$ 保証レベル（n）信頼性を判断する階層スケールのランクは、TOEが述べられたセキュリティ要件を適切に満たすことができることを持つことができます。（保証、証明書ポリシー、EAL、TCSECを参照）
Example: U.S. Government guidance [M0404] describes four assurance levels for identity authentication, where each level "describes the [U.S. Federal Government] agency's degree of certainty that the user has presented [a credential] that refers to [the user's] identity." In that guidance, assurance is defined as (a) "the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued" and (b) "the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued."
例：米国政府ガイダンス[M0404]は、身元認証のための4つの保証レベルを記述し、各レベルは「米国連邦政府政府」代理店の確実性度を表していることを、「ユーザ」アイデンティティを指す「信任状」を提示した。そのガイダンスでは、保証は（A）「信任状が発行された個人の身元を確立するために使用された獣医プロセスへの信頼度」と定義されています。信任状は、信任状が発行された個人です。」
The four levels are described as follows: - Level 1: Little or no confidence in the asserted identity. - Level 2: Some confidence in the asserted identity. - Level 3: High confidence in the asserted identity. - Level 4: Very high confidence in the asserted identity.
4つのレベルは次のように説明されています。 - レベル1：アサートされたアイデンティティへの信頼性がほとんどまたはまったくありません。 - レベル2：アサートされたアイデンティティへの自信。 - レベル3：アサートされたアイデンティティへの高い信頼性。 - レベル4：アサートされたアイデンティティへの非常に高い信頼性。
Standards for determining these levels are provided in a NIST publication [SP12]. However, as noted there, an assurance level is "a degree of confidence, not a true measure of how secure the system actually is. This distinction is necessary because it is extremely difficult -- and in many cases, virtually impossible -- to know exactly how secure a system is."
これらのレベルを決定するための基準は、NIST出版物[SP12]に提供されています。しかし、そこに記載されているように、保証レベルは「自信のある程度であり、実際にシステムの安全性の実際の尺度ではありません。この区別は必要なので必要です - そして多くの場合、事実上不可能 - 知るまさにシステムの確保方法
$ asymmetric cryptography (I) A modern branch of cryptography (popularly known as "public-key cryptography") in which the algorithms use a pair of keys (a public key and a private key) and use a different component of the pair for each of two counterpart cryptographic operations (e.g., encryption and decryption, or signature creation and signature verification). (See: key pair, symmetric cryptography.)
$非対称暗号化（i）アルゴリズムが一対のキー（公開鍵と秘密鍵）を使用し、それぞれのペアの異なるコンポーネントを使用する暗号化の現代のブランチ（「公開鍵暗号化」として知られている）2つの対応する暗号化操作（例えば、暗号化および復号化、または署名の作成および署名検証など）。（参照：キーペア、対称暗号化。）
Tutorial: Asymmetric algorithms have key management advantages over equivalently strong symmetric ones. First, one key of the pair need not be known by anyone but its owner; so it can more easily be kept secret. Second, although the other key is shared by all entities that use the algorithm, that key need not be kept secret from other, non-using entities; thus, the key-distribution part of key management can be done more easily.
チュートリアル：非対称アルゴリズムは、同等の強力な対称性を超える重要な管理上の利点を持っています。まず、ペアの1つのキーは、その所有者が誰でも知られている必要はありません。それで、それはより簡単に秘密にされることができます。第二に、他のキーはアルゴリズムを使用するすべてのエンティティによって共有されていますが、そのキーは他の非使用エンティティから秘密にされる必要はありません。したがって、鍵管理の鍵配信部分をより容易に行うことができる。
Asymmetric cryptography can be used to create algorithms for encryption, digital signature, and key agreement: - In an asymmetric encryption algorithm (e.g., "RSA"), when Alice wants to ensure confidentiality for data she sends to Bob, she encrypts the data with a public key provided by Bob. Only Bob has the matching private key that is needed to decrypt the data. (Compare: seal.) - In an asymmetric digital signature algorithm (e.g., "DSA"), when Alice wants to ensure data integrity or provide authentication for data she sends to Bob, she uses her private key to sign the data (i.e., create a digital signature based on the data). To verify the signature, Bob uses the matching public key that Alice has provided. - In an asymmetric key-agreement algorithm (e.g., "Diffie-Hellman-Merkle"), Alice and Bob each send their own public key to the other party. Then each uses their own private key and the other's public key to compute the new key value.
非対称暗号化は、暗号化、デジタル署名、およびキー契約のためのアルゴリズムを作成するために使用することができます： - 非対称暗号化アルゴリズム（例えば、 "RSA"）では、アリスがボブに送信するデータの機密性を確保したい場合、彼女はデータを暗号化しますボブが提供する公開鍵。データの復号化に必要なマッチング秘密鍵のみがBOBだけです。（比較します。データに基づいてデジタル署名を作成します）。署名を確認するために、BOBはアリスが提供したマッチング公開鍵を使用します。 - 非対称鍵合意アルゴリズム（例えば、「Diffie-Hellman-Merkle」）では、AliceとBobはそれぞれ独自の公開鍵を相手に送ります。その後、それぞれが自分の秘密鍵と他方の公開鍵を使用して新しいキー値を計算します。
$ asymmetric key (I) A cryptographic key that is used in an asymmetric cryptographic algorithm. (See: asymmetric cryptography, private key, public key.)
$ 非対称キー（i）非対称暗号化アルゴリズムで使用される暗号鍵。（非対称暗号、秘密鍵、公開鍵を参照）
$ ATIS (N) See: "Alliance for Telecommunications Industry Solutions" under "ANSI".
$ ATIS（N）「ANSI」の「電気通信業界ソリューションの同盟」。
$ attack 1. (I) An intentional act by which an entity attempts to evade security services and violate the security policy of a system. That is, an actual assault on system security that derives from an intelligent threat. (See: penetration, violation, vulnerability.)
$ 攻撃1.（i）エンティティがセキュリティサービスを回避し、システムのセキュリティポリシーに違反しようとする意図的な行為。つまり、インテリジェントな脅威から派生するシステムセキュリティに関する実際のアサルト。（浸透、違反、脆弱性を参照してください。）
2. (I) A method or technique used in an assault (e.g., masquerade). (See: blind attack, distributed attack.) Tutorial: Attacks can be characterized according to intent: - An "active attack" attempts to alter system resources or affect their operation. - A "passive attack" attempts to learn or make use of information from a system but does not affect system resources of that system. (See: wiretapping.)
（i）攻撃で使用される方法または技術（例えば、マスカレード）。チュートリアル：攻撃は意図に従って特徴付けることができます。 - 「アクティブな攻撃」はシステムリソースを変更したり、自分の操作に影響を与えようとします。 - 「パッシブ攻撃」とは、システムから情報を学習または利用することを試みますが、そのシステムのシステムリソースには影響しません。（：盗聴を参照してください。）
The object of a passive attack might be to obtain data that is needed for an off-line attack. - An "off-line attack" is one in which the attacker obtains data from the target system and then analyzes the data on a different system of the attacker's own choosing, possibly in preparation for a second stage of attack on the target.
パッシブ攻撃の目的は、オフライン攻撃に必要なデータを取得することです。 - 「オフライン攻撃」は、攻撃者がターゲットシステムからデータを取得し、攻撃者自身の異なるシステムでデータを分析し、おそらくターゲットへの攻撃の2段階の攻撃に準備しています。
Attacks can be characterized according to point of initiation: - An "inside attack" is one that is initiated by an entity inside the security perimeter (an "insider"), i.e., an entity that is authorized to access system resources but uses them in a way not approved by the party that granted the authorization. - An "outside attack" is initiated from outside the security perimeter, by an unauthorized or illegitimate user of the system (an "outsider"). In the Internet, potential outside attackers range from amateur pranksters to organized criminals, international terrorists, and hostile governments. Attacks can be characterized according to method of delivery: - In a "direct attack", the attacker addresses attacking packets to the intended victim(s). - In an "indirect attack", the attacker addresses packets to a third party, and the packets either have the address(es) of the intended victim(s) as their source address(es) or indicate the intended victim(s) in some other way. The third party responds by sending one or more attacking packets to the intended victims. The attacker can use third parties as attack amplifiers by providing a broadcast address as the victim address (e.g., "smurf attack"). (See: reflector attack. Compare: reflection attack, replay attack.)
攻撃は開始のポイントに従って特徴付けることができます。 - 「内部攻撃」は、セキュリティ周辺の内側のエンティティ（「インサイダー」）、すなわちシステムリソースにアクセスすることを許可されているがそれらを使用するエンティティによって開始されるものです。許可を与えたパーティーによって承認されていない方法。 - 「外部攻撃」は、システムの不正または違法なユーザーによって、セキュリティ周辺の外部から開始されます（「アウトサー」）。インターネットでは、攻撃者の潜在的な攻撃者がアマチュアのいたずらスターから組織化された犯罪者、国際テロリスト、そして敵対的な政府の範囲です。攻撃は配達方法に従って特徴付けることができます。 - 「直接攻撃」において、攻撃者は意図された犠牲者にパケットを攻撃することを望んでいます。 - 「間接攻撃」では、攻撃者はパケットを第三者にアドレス指定し、パケットは意図された犠牲者のアドレス（S）をソースアドレスとして持つか、または意図された犠牲者を示しています。その他の方法です。第三者は、1つ以上の攻撃のパケットを意図された犠牲者に送信することによって反応します。攻撃者は、犠牲者アドレスとしてブロードキャストアドレスを提供することによって、第三者を攻撃増幅器として使用することができます（例えば、「Smurf Attack」）。 （参照：反射攻撃。比較：反射攻撃、再生攻撃）
The term "attack" relates to some other basic security terms as shown in the following diagram:
「攻撃」という用語は、次の図に示すように、他の基本的なセキュリティ条件に関連しています。
+ - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+
| An Attack: | |Counter- | | A System Resource: |
| i.e., A Threat Action | | measure | | Target of the Attack |
| +----------+ | | | | +-----------------+ |
| | Attacker |<==================||<========= | |
| | i.e., | Passive | | | | | Vulnerability | |
| | A Threat |<=================>||<========> | |
| | Agent | or Active | | | | +-------|||-------+ |
| +----------+ Attack | | | | VVV |
| | | | | Threat Consequences |
+ - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+
$ attack potential (I) The perceived likelihood of success should an attack be launched, expressed in terms of the attacker's ability (i.e., expertise and resources) and motivation. (Compare: threat, risk.)
$ 攻撃の可能性（i）攻撃者の能力（すなわち、専門知識と資源）とモチベーションの観点から表現された攻撃の可能性が発売されるべきです。（比較：脅威、リスク。）
$ attack sensing, warning, and response (I) A set of security services that cooperate with audit service to detect and react to indications of threat actions, including both inside and outside attacks. (See: indicator.)
$ 攻撃検知、警告、および対応（i）監査サービスと協力して、内外と外部の両方の攻撃を含む脅威の行動の表示を検出して反応するセキュリティサービスのセットです。（参照：インジケーターを参照してください。）
$ attack tree (I) A branching, hierarchical data structure that represents a set of potential approaches to achieving an event in which system security is penetrated or compromised in a specified way. [Moor]
$ 攻撃ツリー（i）システムセキュリティが特定の方法で侵入または侵害されているイベントを達成するための一連の潜在的なアプローチを表す分岐、階層データ構造。[ムーア]
Tutorial: Attack trees are special cases of fault trees. The security incident that is the goal of the attack is represented as the root node of the tree, and the ways that an attacker could reach that goal are iteratively and incrementally represented as branches and subnodes of the tree. Each subnode defines a subgoal, and each subgoal may have its own set of further subgoals, etc. The final nodes on the paths outward from the root, i.e., the leaf nodes, represent different ways to initiate an attack. Each node other than a leaf is either an AND-node or an OR-node. To achieve the goal represented by an AND-node, the subgoals represented by all of that node's subnodes must be achieved; and for an OR-node, at least one of the subgoals must be achieved. Branches can be labeled with values representing difficulty, cost, or other attack attributes, so that alternative attacks can be compared.
チュートリアル：攻撃ツリーは障害ツリーの特別なケースです。攻撃の目的であるセキュリティインシデントは、ツリーのルートノードとして表され、攻撃者がその目標に達する方法は繰り返し、徐々にツリーの分岐とサブノードとして表されます。各サブノードはサブゴールを定義し、各サブゴールはそれ自身のさらなるサブゴールなどのセットを持つことができます。ルートから外側にある、すなわちリーフノードは、攻撃を開始するためのさまざまな方法を表します。リーフ以外の各ノードは、ANDノードまたはORノードのいずれかです。ANDノードで表される目標を達成するためには、そのノードのサブノードのすべてで表されるサブゴールを達成する必要があります。そして、またはORノードの場合、サブゴールの少なくとも1つを達成する必要があります。分岐は、困難、コスト、または他の攻撃属性を表す値でラベル付けすることができるので、代替攻撃を比較することができる。
$ attribute (N) Information of a particular type concerning an identifiable system entity or object. An "attribute type" is the component of an attribute that indicates the class of information given by the attribute; and an "attribute value" is a particular instance of the class of information indicated by an attribute type. (See: attribute certificate.)
$ 属性（n）識別可能なシステムエンティティまたはオブジェクトに関する特定の型の情報。"属性type"は、属性によって指定された情報のクラスを示す属性のコンポーネントです。「属性値」は、属性タイプによって示される情報のクラスの特定のインスタンスです。（属性証明書を参照してください。）
$ attribute authority (AA) 1. (N) A CA that issues attribute certificates.
$ 属性権限（AA）1.（n）属性証明書を発行するCA。
2. (O) "An authority [that] assigns privileges by issuing attribute certificates." [X509]
2. （O） "属性証明書を発行して特権を割り当てます。」[X509]
Deprecated Usage: The abbreviation "AA" SHOULD NOT be used in an IDOC unless it is first defined in the IDOC.
廃止予定の使用法：IDocで最初に定義されていない限り、略語「aa」はIDocでは使用されるべきではありません。
$ attribute certificate 1. (I) A digital certificate that binds a set of descriptive data items, other than a public key, either directly to a subject name or to the identifier of another certificate that is a public-key certificate. (See: capability token.)
$ 属性証明書1.（i）公開鍵以外の一連の記述データ項目を、件名または公開鍵証明書である他の証明書の識別子にバインドするデジタル証明書。（能力トークンを参照してください。）
2. (O) "A data structure, digitally signed by an [a]ttribute [a]uthority, that binds some attribute values with identification information about its holder." [X509]
2. （o） "データ構造は、[属性] [属性値を識別情報にバインドする属性値をその保有者に関する識別情報にバインドされている）によってデジタル署名されました。[X509]
Tutorial: A public-key certificate binds a subject name to a public key value, along with information needed to perform certain cryptographic functions using that key. Other attributes of a subject, such as a security clearance, may be certified in a separate kind of digital certificate, called an attribute certificate. A subject may have multiple attribute certificates associated with its name or with each of its public-key certificates.
チュートリアル：公開鍵証明書は、そのキーを使用して特定の暗号機能を実行するために必要な情報とともに、件名を公開鍵の値にバインドします。セキュリティクリアランスなどの主題の他の属性は、属性証明書と呼ばれる別の種類のデジタル証明書で認定されてもよい。対象は、その名前またはその公開鍵証明書と関連付けられた複数の属性証明書を持つことができます。
An attribute certificate might be issued to a subject in the following situations: - Different lifetimes: When the lifetime of an attribute binding is shorter than that of the related public-key certificate, or when it is desirable not to need to revoke a subject's public key just to revoke an attribute. - Different authorities: When the authority responsible for the attributes is different than the one that issues the public-key certificate for the subject. (There is no requirement that an attribute certificate be issued by the same CA that issued the associated public-key certificate.)
次のような状況では、属性証明書が件名に発行されることがあります。 - 存在する寿命：属性バインディングの有効期間が関連する公開鍵証明書の存続期間よりも短い場合、または被験者の一般の人々を取り消す必要がない場合属性を取り消すためだけにキーを押します。 - さまざまな権限：属性を担当する権限が、件名の公開鍵証明書を発行するものと異なる場合。（関連する公開鍵証明書を発行したのと同じCAによって属性証明書を発行する必要はありません。）
$ audit See: security audit.
$ 監査：セキュリティ監査
$ audit log (I) Synonym for "security audit trail".
$ 監査ログ（I）「セキュリティ監査証跡」の同義語。
$ audit service (I) A security service that records information needed to establish accountability for system events and for the actions of system entities that cause them. (See: security audit.)
$ 監査サービス（i）システムイベントの説明責任とそれらを引き起こすシステムエンティティのアクションを確立するために必要な情報を記録するセキュリティサービス。（セキュリティ監査を参照してください。）
$ audit trail (I) See: security audit trail.
$ 監査証跡（I）：セキュリティ監査証跡。
$ AUTH (I) See: POP3 AUTH.
$ auth（i）参照：POP3認証。
$ authenticate (I) Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource. (See: authentication, validate vs. verify, "relationship between data integrity service and authentication services" under "data integrity service".)
$ （i）認証（すなわち、システムエンティティまたはシステムリソースの場合）を検証する（すなわち、）属性値を検証する。（「認証、VS.データ整合性サービス」の「データ整合性サービスと認証サービス間の関係」を参照）。）
Deprecated Usage: In general English usage, this term is used with the meaning "to prove genuine" (e.g., an art expert authenticates a Michelangelo painting); but IDOCs should restrict usage as follows: - IDOCs SHOULD NOT use this term to refer to proving or checking that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. Instead, use "verify". - IDOCs SHOULD NOT use this term to refer to proving the truth or accuracy of a fact or value such as a digital signature. Instead, use "verify". - IDOCs SHOULD NOT use this term to refer to establishing the soundness or correctness of a construct, such as a digital certificate. Instead, use "validate".
廃止予定の使用法：一般的な英語の使用法では、この用語は「本物を証明するための意味」と共に使用されます（例えば、アート専門家はミケランジェロ絵画を認証します）。しかし、IDocは次のように使用を制限する必要があります。代わりに、「検証」を使用してください。 - IDOCはこの用語を使用して、デジタル署名などの事実や価値の真実や正確性を証明することを指すべきではありません。代わりに、「検証」を使用してください。 - IDOCは、この用語を使用して、デジタル証明書などの構築物の健全性または正確さを確立することを指すべきです。代わりに、「検証」を使用してください。
$ authentication (I) The process of verifying a claim that a system entity or system resource has a certain attribute value. (See: attribute, authenticate, authentication exchange, authentication information, credential, data origin authentication, peer entity authentication, "relationship between data integrity service and authentication services" under "data integrity service", simple authentication, strong authentication, verification, X.509.) Tutorial: Security services frequently depend on authentication of the identity of users, but authentication may involve any type of attribute that is recognized by a system. A claim may be made by a subject about itself (e.g., at login, a user typically asserts its identity) or a claim may be made on behalf of a subject or object by some other system entity (e.g., a user may claim that a data object originates from a specific source, or that a data object is classified at a specific security level).
$認証（i）システムエンティティまたはシステムリソースが特定の属性値を有するという請求を検証するプロセス。（属性、認証、認証交換、認証情報、認証情報、データ原点認証、ピアエンティティ認証、「データ整合性サービスと認証サービス間の関係」、単純認証、強力な認証、検証、X.509.）チュートリアル：セキュリティサービスは頻繁にユーザーのIDの認証に依存しますが、認証にはシステムによって認識される任意のタイプの属性が含まれます。クレームは、それ自体に関する被験者によって（例えば、ログイン時にユーザが典型的にはその身元を主張する）、または他のシステムエンティティによって主語またはオブジェクトを代わって行われてもよい（例えば、ユーザがそれを主張することがあるかもしれない）。データオブジェクトは特定のソースから発信されるか、またはデータオブジェクトが特定のセキュリティレベルで分類されていることを示します。
An authentication process consists of two basic steps: - Identification step: Presenting the claimed attribute value (e.g., a user identifier) to the authentication subsystem. - Verification step: Presenting or generating authentication information (e.g., a value signed with a private key) that acts as evidence to prove the binding between the attribute and that for which it is claimed. (See: verification.)
認証プロセスは、2つの基本的なステップで構成されています。 - 識別ステップ：クレームされた属性値（例えば、ユーザ識別子）を認証サブシステムに提示する。 - 検証ステップ：認証情報を提示または生成する（例えば、秘密鍵で署名された値）。（検証を参照してください。）
$ authentication code (D) Synonym for a checksum based on cryptography. (Compare: Data Authentication Code, Message Authentication Code.)
$ 認証コード（d）暗号化に基づくチェックサムの同義語。（比較：データ認証コード、メッセージ認証コード）
Deprecated Term: IDOCs SHOULD NOT use this uncapitalized term as a synonym for any kind of checksum, regardless of whether or not the checksum is cryptographic. Instead, use "checksum", "Data Authentication Code", "error detection code", "hash", "keyed hash", "Message Authentication Code", "protected checksum", or some other recommended term, depending on what is meant.
廃止予定の用語：チェックサムが暗号化されているかどうかにかかわらず、IDocはこの不安定な用語をあらゆる種類のチェックサムの同義語として使用しないでください。代わりに、「チェックサム」、「データ認証コード」、「エラー検出コード」、「ハッシュ」、「キー入力ハッシュ」、「メッセージ認証コード」、「保護チェックサム」、「保護チェックサム」、またはその他の推奨用語、またはその他の推奨用語を使用してください。。
The term mixes concepts in a potentially misleading way. The word "authentication" is misleading because the checksum may be used to perform a data integrity function rather than a data origin authentication function.
この用語は潜在的に誤解を招くような方法でミックスされます。チェックサムを使用してデータの原点認証機能ではなくデータ整合性機能を実行できるため、「認証」という単語が誤解を招くことです。
$ authentication exchange 1. (I) A mechanism to verify the identity of an entity by means of information exchange.
$ 認証Exchange 1.（i）情報交換によるエンティティの身元を検証するためのメカニズム。
2. (O) "A mechanism intended to ensure the identity of an entity by means of information exchange." [I7498-2]
2. （O）「情報交換による事業体の身元を確保するためのメカニズム」。[I7498-2]
$ Authentication Header (AH) (I) An Internet protocol [R2402, R4302] designed to provide connectionless data integrity service and connectionless data origin authentication service for IP datagrams, and (optionally) to provide partial sequence integrity and protection against replay attacks. (See: IPsec. Compare: ESP.) Tutorial: Replay protection may be selected by the receiver when a security association is established. AH authenticates the upper-layer PDU that is carried as an IP SDU, and also authenticates as much of the IP PCI (i.e., the IP header) as possible. However, some IP header fields may change in transit, and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. Thus, the values of such fields cannot be protected end-to-end by AH; protection of the IP header by AH is only partial when such fields are present.
$認証ヘッダー（AH）（i）IPデータグラムのためのConnectless Data Integrityサービスとコネクションレスデータオリジナル認証サービスを提供するように設計された[R2402、R4302]、および（オプションで）IPデータグラムのための（オプションで）再生攻撃に対する部分的なシーケンスの整合性と保護を提供するように設計されています。（参照：IPsec。比較：ESP。）チュートリアル：セキュリティアソシエーションが確立されたときに再生保護を受信者によって選択することができます。AHは、IP SDUとして搭載されている上位層PDUを認証し、また可能な限り多くのIP PCI（すなわちIPヘッダ）を認証します。ただし、パケットが受信側に到着した場合は、IPヘッダーフィールドの中にはトランジット内で変更される可能性があります。したがって、そのようなフィールドの値は、AHによってエンドツーエンドで保護することはできません。AHによるIPヘッダの保護は、そのようなフィールドが存在するときにのみ部分的なのです。
AH may be used alone, or in combination with the ESP, or in a nested fashion with tunneling. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a host and a gateway. ESP can provide nearly the same security services as AH, and ESP can also provide data confidentiality service. The main difference between authentication services provided by ESP and AH is the extent of the coverage; ESP does not protect IP header fields unless they are encapsulated by AH.
ああは単独で、またはESP、またはトンネリングで入れ子になっている方法で使用することができます。セキュリティサービスは、一対の通信ホスト間、またはCommunicating Security Gatewaysの間、またはホストとゲートウェイの間に提供できます。ESPはAHとほぼ同じセキュリティサービスを提供することができ、ESPはデータ機密保持サービスを提供することもできます。ESPとああによって提供される認証サービスの主な違いは、カバレッジの範囲です。ESPは、AHによってカプセル化されていない限り、IPヘッダーフィールドを保護しません。
$ authentication information (I) Information used to verify an identity claimed by or for an entity. (See: authentication, credential, user. Compare: identification information.)
$ 認証情報（i）エンティティによって要求されている身元を検証するために使用される情報。（認証、資格情報、ユーザー。比較：識別情報。）
Tutorial: Authentication information may exist as, or be derived from, one of the following: (a) Something the entity knows (see: password); (b) something the entity possesses (see: token); (c) something the entity is (see: biometric authentication).
チュートリアル：認証情報は、次のいずれかのいずれかとして存在することがあります。（a）エンティティが知っている何か（パスワードを参照）。（b）企業が持っているもの（トークンを参照）。（c）事業体があるもの（バイオメトリック認証を参照）。
$ authentication service (I) A security service that verifies an identity claimed by or for an entity. (See: authentication.)
$ 認証サービス（i）エンティティを主張した識別情報を検証するセキュリティサービス。（認証を参照してください。）
Tutorial: In a network, there are two general forms of authentication service: data origin authentication service and peer entity authentication service.
チュートリアル：ネットワークでは、認証サービスの2つの一般的な形式があります。データオリジナル認証サービスとピアエンティティ認証サービス。
$ authenticity (I) The property of being genuine and able to be verified and be trusted. (See: authenticate, authentication, validate vs. verify.)
$ 信憑性（i）本物であり、検証され、信頼されることができるという性質。（認証、認証、検証対Verify。）
$ authority (D) /PKI/ "An entity [that is] responsible for the issuance of certificates." [X509]
$ 権限（D）/ PKI /「証明書の発行に責任がある企業」[X509]
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for attribute authority, certification authority, registration authority, or similar terms; the shortened form may cause confusion. Instead, use the full term at the first instance of usage and then, if it is necessary to shorten text, use AA, CA, RA, and other abbreviations defined in this Glossary.
廃止予定の使用法：IDOCは、この用語を属性局、認証局、登録局、または同様の用語の同義語として使用しないでください。短縮された形は混乱を引き起こす可能性があります。代わりに、最初の使用例で全文を使用してから、テキストを短くする必要がある場合は、この用語集に定義されているAA、CA、RA、およびその他の省略形を使用します。
$ authority certificate (D) "A certificate issued to an authority (e.g. either to a certification authority or to an attribute authority)." [X509] (See: authority.)
$ 権限証明書（D） "当局に発行された証明書（例えば、認証局または属性局のいずれか）。」[X509]（官能を参照）
Deprecated Term: IDOCs SHOULD NOT use this term because it is ambiguous. Instead, use the full term "certification authority certificate", "attribute authority certificate", "registration authority certificate", etc. at the first instance of usage and then, if it is necessary to shorten text, use AA, CA, RA, and other abbreviations defined in this Glossary.
廃止予定の用語：IDOCは、あいまいなので、この用語を使用しないでください。代わりに、最初の使用例では、「認証局証明書」、「属性局証明書」、「登録局証明書」などを使用してから、テキストを短くする必要がある場合は、AA、CA、RAを使用する必要がある場合は、そしてこの用語集に定義された他の略語。
$ Authority Information Access extension (I) The private extension defined by PKIX for X.509 certificates to indicate "how to access CA information and services for the issuer of the certificate in which the extension appears. Information and services may include on-line validation services and CA policy data." [R3280] (See: private extension.)
$ 権限情報アクセス拡張（i）拡張子が表示される証明書の発行者のためのCA情報やサービスにアクセスする方法を示すためにPKIX for X.509証明書によって定義されたプライベート拡張。情報とサービスにはオンライン検証サービスが含まれる場合があります。そしてCAポリシーデータ」[R3280]（秘密の拡張子を参照）
$ authorization 1a. (I) An approval that is granted to a system entity to access a system resource. (Compare: permission, privilege.)
$ 承認1A。（i）システムリソースにアクセスするためにシステムエンティティに付与されている承認。（比較：権限、特権）
Usage: Some synonyms are "permission" and "privilege". Specific terms are preferred in certain contexts: - /PKI/ "Authorization" SHOULD be used, to align with "certification authority" in the standard [X509]. - /role-based access control/ "Permission" SHOULD be used, to align with the standard [ANSI]. - /computer operating systems/ "Privilege" SHOULD be used, to align with the literature. (See: privileged process, privileged user.)
使用法：一部の同義語は「許可」と「特権」です。特定の用語は特定のコンテキストで優先されます。 - 標準[ANSI]に合わせるために、/役割ベースのアクセス制御/「許可」を使用する必要があります。 - /「コンピュータオペレーティングシステム/特権」を使用して、文献に合わせる必要があります。（：特権プロセス、特権ユーザー。）
Tutorial: The semantics and granularity of authorizations depend on the application and implementation (see: "first law" under "Courtney's laws"). An authorization may specify a particular access mode -- such as read, write, or execute -- for one or more system resources.
チュートリアル：承認の意味論と粒度は、アプリケーションと実装によって異なります（「Courtney's Laws」の下の「最初の法律」）。許可は、1つ以上のシステムリソースについて、読み取り、書き込み、または実行など、特定のアクセスモードを指定することができます。
1b. (I) A process for granting approval to a system entity to access a system resource.
1b。（i）システムエンティティにシステムリソースにアクセスするための承認を与えるためのプロセス。
2. (O) /SET/ "The process by which a properly appointed person or persons grants permission to perform some action on behalf of an organization. This process assesses transaction risk, confirms that a given transaction does not raise the account holder's debt above the account's credit limit, and reserves the specified amount of credit. (When a merchant obtains authorization, payment for the authorized amount is guaranteed -- provided, of course, that the merchant followed the rules associated with the authorization process.)" [SET2]
2. （O）/ SET /「適切に任命された人物または人員が組織に代わって何らかの行動を実行する許可を与えるプロセス。このプロセスは取引リスクを評価し、与えられた取引がアカウントの上に口座保有者の借金を上げないことを確認します。信用限度、および指定された信用額を予約します。（マーチャントが承認を取得すると、許可された金額の支払いが保証されています。もちろん、販売者が許可プロセスに関連した規則に従ったことがあります）」[set2]
$ authorization credential (I) See: /access control/ under "credential".
$ 認証信任状（i）/アクセス制御/「信任状」の下にある。
$ authorize (I) Grant an authorization to a system entity.
$ 承認（i）システムエンティティへの許可を付与します。
$ authorized user (I) /access control/ A system entity that accesses a system resource for which the entity has received an authorization. (Compare: insider, outsider, unauthorized user.)
$ 許可されたユーザー（I）/アクセス制御/エンティティが許可を受けたシステムリソースにアクセスするシステムエンティティ。（比較：インサイダー、アウトサイダー、不正なユーザー。）
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.
廃止予定の使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されており、簡単に誤解される可能性があるため、定義を記載する必要があります。
$ automated information system See: information system.
$ 自動情報システム参照：情報システム
$ availability 1. (I) The property of a system or a system resource being accessible, or usable or operational upon demand, by an authorized system entity, according to performance specifications for the system; i.e., a system is available if it provides services according to the system design whenever users request them. (See: critical, denial of service. Compare: precedence, reliability, survivability.)
$ 可用性1.（i）システムのパフォーマンス仕様に従って、承認されたシステムエンティティによって、システムまたはシステムリソースの財産、または需要が求められている、または使用可能または運用上の財産。すなわち、ユーザがそれらを要求するたびにシステム設計に従ってサービスを提供する場合、システムが利用可能である。（Critical、Service datibal。比較：優先順位、信頼性、生存可能性。）
2. (O) "The property of being accessible and usable upon demand by an authorized entity." [I7498-2]
2. （o）「アクセス可能で、許可されたエンティティによる需要に応じて使用可能」の財産。[I7498-2]
3. (D) "Timely, reliable access to data and information services for authorized users." [C4009]
3. （d）「タイムリーで、許可されたユーザーのためのデータおよび情報サービスへの信頼性の高いアクセス」。[C4009]
Deprecated Definition: IDOCs SHOULD NOT use the term with definition 3; the definition mixes "availability" with "reliability", which is a different property. (See: reliability.) Tutorial: Availability requirements can be specified by quantitative metrics, but sometimes are stated qualitatively, such as in the following: - "Flexible tolerance for delay" may mean that brief system outages do not endanger mission accomplishment, but extended outages may endanger the mission. - "Minimum tolerance for delay" may mean that mission accomplishment requires the system to provide requested services in a short time.
廃止予定の定義：IDocは定義3で用語を使用しないでください。定義は「可用性」と「信頼性」とミックスします。これは異なる性質です。（信頼性を参照してください。）チュートリアル：空室状況要件は定量的なメトリックで指定できますが、次のように定性的に記載されています。停止は任務を危険にさらす可能性があります。 - 「遅延の最小許容範囲」は、ミッションの達成がシステムに要求されたサービスを短時間で提供することを要求することを意味します。
$ availability service (I) A security service that protects a system to ensure its availability.
$ 可用性サービス（i）可用性を確保するためにシステムを保護するセキュリティサービス。
Tutorial: This service addresses the security concerns raised by denial-of-service attacks. It depends on proper management and control of system resources, and thus depends on access control service and other security services.
チュートリアル：このサービスは、サービス拒否攻撃によって提起されたセキュリティ上の懸念に対処します。それはシステムリソースの適切な管理と制御に依存し、したがってアクセス制御サービスやその他のセキュリティサービスによって異なります。
$ avoidance (I) See: secondary definition under "security".
$ 回避（i）「セキュリティ」の下の二次定義を参照してください。
$ B1, B2, or B3 computer system (O) /TCSEC/ See: Tutorial under "Trusted Computer System Evaluation Criteria".
$ B1、B2、またはB3コンピュータシステム（O）/ TCSEC /参照：「信頼できるコンピュータシステム評価基準」の下のチュートリアル。
$ back door 1. (I) /COMPUSEC/ A computer system feature -- which may be (a) an unintentional flaw, (b) a mechanism deliberately installed by the system's creator, or (c) a mechanism surreptitiously installed by an intruder -- that provides access to a system resource by other than the usual procedure and usually is hidden or otherwise not well-known. (See: maintenance hook. Compare: Trojan Horse.)
$ バックドア1.（i）/ compusec /コンピュータシステム機能 - （a）システムの作成者によって意図的にインストールされたメカニズム、または（c）侵入者によって不条理的にインストールされたメカニズム - - 通常の手順以外のシステムリソースへのアクセスを提供し、通常は隠されているか、またはよく知られていません。（：メンテナンスフック。比較：トロイの木馬。）
Example: A way to access a computer other than through a normal login. Such an access path is not necessarily designed with malicious intent; operating systems sometimes are shipped by the manufacturer with hidden accounts intended for use by field service technicians or the vendor's maintenance programmers.
例：通常のログイン以外のコンピュータにアクセスする方法。そのようなアクセスパスは必ずしも悪意のある意図で設計されていません。オペレーティングシステムは、フィールドサービス技術者またはベンダーのメンテナンスプログラマによる使用を目的とした隠されたアカウントを持つ製造業者によって出荷されることがあります。
2. (I) /cryptography/ A feature of a cryptographic system that makes it easily possible to break or circumvent the protection that the system is designed to provide.
2. （i）/暗号化/システムが提供するように設計されている保護を破断または回避することを容易に可能にする暗号システムの特徴。
Example: A feature that makes it possible to decrypt cipher text much more quickly than by brute-force cryptanalysis, without having prior knowledge of the decryption key.
例：復号鍵の事前の知識を持たずに、ブルートフォース暗号解読よりもはるかに早く暗号テキストを復号化することを可能にする特徴。
$ back up (I) /verb/ Create a reserve copy of data or, more generally, provide alternate means to perform system functions despite loss of system resources. (See: contingency plan. Compare: archive.)
$ バックアップ（I）/動詞/登録データのリザーブコピー、またはより一般的には、システムリソースの損失にもかかわらず、システム機能を実行するための代替手段を提供します。（：偶然の計画を参照してください。比較：アーカイブ。）
$ backup (I) /noun or adjective/ Refers to alternate means of performing system functions despite loss of system resources. (See: contingency plan).
$ バックアップ（I）/名詞または形容詞/システムリソースの損失にもかかわらず、システム機能を実行するための代替手段を表します。（緊急プランを参照）。
Example: A reserve copy of data, preferably one that is stored separately from the original, for use if the original becomes lost or damaged. (Compare: archive.)
例：オリジナルが紛失または破損した場合に使用するために、データの予約コピー、好ましくは元のものとは別に保管されているものです。（比較：アーカイブ）
$ bagbiter (D) /slang/ "An entity, such as a program or a computer, that fails to work or that works in a remarkably clumsy manner. A person who has caused some trouble, inadvertently or otherwise, typically by failing to program the computer properly." [NCSSG] (See: flaw.)
$ バグビーター（D）/ Slang / "プログラムやコンピュータなどのエンティティ、または著しく不器用な方法で動作しています。誤って、またはそうでなければ、通常はプログラムできなかった人。正しくコンピュータ。」[NCSSG]（「欠陥」を参照してください。）
Deprecated Term: It is likely that other cultures use different metaphors for these concepts. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の期間：他の文化がこれらの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ baggage (O) /SET/ An "opaque encrypted tuple, which is included in a SET message but appended as external data to the PKCS encapsulated data. This avoids superencryption of the previously encrypted tuple, but guarantees linkage with the PKCS portion of the message." [SET2]
$ 手荷物（O）/ SET / Aの不透明な暗号化タプル。。」[SET2]
Deprecated Usage: IDOCs SHOULD NOT use this term to describe a data element, except in the form "SET(trademark) baggage" with the meaning given above.
廃止予定の使用法：IDOCは、「Set（登録商標）手荷物」を除き、上記の意味を除いて、データ要素を記述するようにこの用語を使用しないでください。
$ baked-in security (D) The inclusion of security mechanisms in an information system beginning at an early point in the system's lifecycle, i.e., during the design phase, or at least early in the implementation phase. (Compare: add-on security.)
$ システムのライフサイクルの初期の点で始まる情報システム内のセキュリティメカニズムを、すなわち設計段階の間、または実装段階の少なくとも早い段階でセキュリティメカニズムを含める。（比較：アドオンセキュリティ。）
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term (unless they also provide a definition like this one). (See: Deprecated Usage under "Green Book".)
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください（彼らにもこのような定義を提供しない限り）。（「グリーンブック」の「廃止予定の使用」。）
$ bandwidth (I) The total width of the frequency band that is available to or used by a communication channel; usually expressed in Hertz (Hz). (RFC 3753) (Compare: channel capacity.)
$ 帯域幅（I）通信チャネルで利用可能または使用可能な周波数帯域の全幅。通常はHertz（Hz）で表現されています。（RFC 3753）（比較：チャネル容量）
$ bank identification number (BIN) 1. (O) The digits of a credit card number that identify the issuing bank. (See: primary account number.)
$ 銀行識別番号（BIN）1.（O）発行銀行を識別するクレジットカード番号の数字。（以下を参照してください。プライマリアカウント番号）
2. (O) /SET/ The first six digits of a primary account number.
2. （o）/ set /プライマリアカウント番号の最初の6桁。
$ Basic Encoding Rules (BER) (I) A standard for representing ASN.1 data types as strings of octets. [X690] (See: Distinguished Encoding Rules.)
$ 基本エンコード規則（BER）（I）ASN.1データ型をオクテットの文字列として表現するための標準。[x690]（識別符号化規則を参照してください。）
Deprecated Usage: Sometimes incorrectly treated as part of ASN.1. However, ASN.1 properly refers only to a syntax description language, and not to the encoding rules for the language.
廃止予定の使用法：時には誤ってASN.1の一部として扱われます。ただし、ASN.1は正しくシンタックス記述言語のみを参照し、言語のエンコード規則はありません。
$ Basic Security Option (I) See: secondary definition under "IPSO".
$ 基本的なセキュリティオプション（i）「IPSO」の2次定義を参照してください。
$ bastion host (I) A strongly protected computer that is in a network protected by a firewall (or is part of a firewall) and is the only host (or one of only a few) in the network that can be directly accessed from networks on the other side of the firewall. (See: firewall.)
$ Bastion Host（i）ファイアウォールによって保護されているネットワーク内にある厳密に保護されたコンピュータ（またはファイアウォールの一部）で、ネットワークから直接アクセスできるネットワーク内の唯一のホスト（または数字のみ）です。ファイアウォールの反対側。（：ファイアウォールを参照してください。）
Tutorial: Filtering routers in a firewall typically restrict traffic from the outside network to reaching just one host, the bastion host, which usually is part of the firewall. Since only this one host can be directly attacked, only this one host needs to be very strongly protected, so security can be maintained more easily and less expensively. However, to allow legitimate internal and external users to access application resources through the firewall, higher-layer protocols and services need to be relayed and forwarded by the bastion host. Some services (e.g., DNS and SMTP) have forwarding built in; other services (e.g., TELNET and FTP) require a proxy server on the bastion host.
チュートリアル：ファイアウォール内のルータのフィルタリングは、通常、外部ネットワークからのトラフィックを制限して、通常はファイアウォールの一部であるバスティオンホストだけにアクセスします。この1つのホストのみを直接攻撃することができるので、この1つのホストのみが非常に強く保護される必要があるため、セキュリティをより簡単かつ安価に維持できます。ただし、正当な内部ユーザーと外部ユーザーがファイアウォールを介してアプリケーションリソースにアクセスできるようにするには、上位レイヤープロトコルとサービスをバスティオンホストによって中継および転送する必要があります。一部のサービス（たとえば、DNSとSMTP）には転送が組み込まれています。他のサービス（例えば、TelnetおよびFTP）は、バスティオンホスト上のプロキシサーバを必要とする。
$ BBN Technologies Corp. (BBN) (O) The research-and-development company (originally called Bolt Baranek and Newman, Inc.) that built the ARPANET.
$ BBN Technologies Corp.（BBN）（O）アルパネットを構築した研究開発会社（もともとBolt BaranekとNewman、Inc。という）。
$ BCA (O) See: brand certification authority.
$ BCA（o）参照：ブランド認証局。
$ BCR (O) See: BLACK/Crypto/RED.
$ BCR（O）参照：黒/暗号/赤。
$ BCI (O) See: brand CRL identifier.
$ BCI（O）参照：ブランドCRL識別子。
$ Bell-LaPadula model (N) A formal, mathematical, state-transition model of confidentiality policy for multilevel-secure computer systems [Bell]. (Compare: Biba model, Brewer-Nash model.)
$ Bell-Lapadula Model（n）マルチレベルセキュアコンピュータシステムの機密性ポリシーの形式的、数学的、状態遷移モデル[Bell]。（比較：Biba Model、Brewer-Nash Model。）
Tutorial: The model, devised by David Bell and Leonard LaPadula at The MITRE Corporation in 1973, characterizes computer system elements as subjects and objects. To determine whether or not a subject is authorized for a particular access mode on an object, the clearance of the subject is compared to the classification of the object. The model defines the notion of a "secure state", in which the only permitted access modes of subjects to objects are in accordance with a specified security policy. It is proven that each state transition preserves security by moving from secure state to secure state, thereby proving that the system is secure. In this model, a multilevel-secure system satisfies several rules, including the "confinement property" (a.k.a. the "*-property"), the "simple security property", and the "tranquility property".
チュートリアル：1973年にMiter CorporationのDavid BellとLeonard Lapadulaによって考案されたモデルは、被験者や物としてのコンピュータシステムの要素を特徴付けます。被写体がオブジェクト上の特定のアクセスモードに対して許可されているかどうかを判断するために、対象のクリアランスがオブジェクトの分類と比較される。このモデルは「セキュア状態」の概念を定義し、その中にオブジェクトへの対象の唯一の許可されたアクセスモードは指定されたセキュリティポリシーに従っています。各状態遷移は、安全な状態からセキュア状態に移動することによってセキュリティを保持し、それによってシステムが安全であることを証明することが証明されています。このモデルでは、マルチレベルセキュアシステムは、「閉じ込めプロパティ」（「* -property」）、「単純なセキュリティプロパティ」、および「TRANQULITIOL PROPLITIOR」を含む、いくつかの規則を満たしています。
$ benign 1. (N) /COMSEC/ "Condition of cryptographic data [such] that [the data] cannot be compromised by human access [to the data]." [C4009]
$ （N）/ COMSEC /「暗号データの条件[データのデータへのデータ）によって侵害されることはできません。」[C4009]
2. (O) /COMPUSEC/ See: secondary definition under "trust".
2. （O）/ compusec / see：「信頼」の下の2次定義。
$ benign fill (N) Process by which keying material is generated, distributed, and placed into an ECU without exposure to any human or other system entity, except the cryptographic module that consumes and uses the material. (See: benign.)
$ 材料を消費して使用する暗号モジュールを除いて、どのようなシステムエンティティを露出させることなく、キーイング材料が生成され、分散され、そしてECUに配置されるかどうかの良好な充填（n）プロセス。（参照：良意。）
$ BER (I) See: Basic Encoding Rules.
$ BER（I）参照：基本エンコード規則。
$ beyond A1 1. (O) /formal/ A level of security assurance that is beyond the highest level (level A1) of criteria specified by the TCSEC. (See: Tutorial under "Trusted Computer System Evaluation Criteria".) 2. (O) /informal/ A level of trust so high that it is beyond state-of-the-art technology; i.e., it cannot be provided or verified by currently available assurance methods, and especially not by currently available formal methods.
A1を超えて、TCSECで指定された基準の最高レベル（レベルA1）を超えているセキュリティ保証のレベル（O）/正式/セキュリティ保証のレベル。（「信頼できるコンピュータシステム評価基準」の「チュートリアル」。）2。（O）/非公式/信託レベルが最先端の技術を超えていることが高い。すなわち、現在利用可能な保証方法によって提供または検証することはできない、特に現在利用可能な正式な方法によるものではない。
$ Biba integrity (N) Synonym for "source integrity".
$ BIBA Integrity（N）「ソースの整合性」の同義語。
$ Biba model (N) A formal, mathematical, state-transition model of integrity policy for multilevel-secure computer systems [Biba]. (See: source integrity. Compare: Bell-LaPadula model.)
$ BIBAモデル（N）マルチレベルセキュアコンピュータシステムのための完全性ポリシーの形式的、数学的、状態遷移モデル[BIBA]。（Source Integrityを参照してください。比較：ベルララドゥラモデル）
Tutorial: This model for integrity control is analogous to the Bell-LaPadula model for confidentiality control. Each subject and object is assigned an integrity level and, to determine whether or not a subject is authorized for a particular access mode on an object, the integrity level of the subject is compared to that of the object. The model prohibits the changing of information in an object by a subject with a lesser or incomparable level. The rules of the Biba model are duals of the corresponding rules in the Bell-LaPadula model.
チュートリアル：完全性制御のためのこのモデルは、機密性制御のためのベルララドゥラモデルに似ています。各被写体とオブジェクトには、対象レベルが割り当てられ、被写体がオブジェクト上の特定のアクセスモードに対して承認されているかどうかを判断するために、対象の整合性レベルがオブジェクトの整合性レベルと比較される。モデルは、被写体による情報の変更をより低いまたは不適合なレベルで変更することを禁止します。BIBAモデルの規則は、ベルラップランドモデル内の対応する規則の二重です。
$ billet (N) "A personnel position or assignment that may be filled by one person." [JCP1] (Compare: principal, role, user.)
$ ビレット（N）「一人でいっぱいになる可能性がある人の立場や課題」。[JCP1]（比較：プリンシパル、役割、ユーザー。）
Tutorial: In an organization, a "billet" is a populational position, of which there is exactly one instance; but a "role" is functional position, of which there can be multiple instances. System entities are in one-to-one relationships with their billets, but may be in many-to-one and one-to-many relationships with their roles.
チュートリアル：組織では、「ビレット」は人口位置です。そのうち正確に1つのインスタンスがあります。しかし、「役割」は機能的な位置であり、そのうち複数のインスタンスがある可能性があります。システムエンティティは、ビレットと1対1の関係にありますが、その役割と多対1と1対多の関係にある可能性があります。
$ BIN (O) See: bank identification number.
$ BIN（O）参照：銀行識別番号。
$ bind (I) To inseparably associate by applying some security mechanism.
$ いくつかのセキュリティメカニズムを適用することで、（i）を不可分に関連付けるようにバインドします。
Example: A CA creates a public-key certificate by using a digital signature to bind together (a) a subject name, (b) a public key, and usually (c) some additional data items (e.g., "X.509 public-key certificate").
例：CAは、デジタル署名を使用して、（a）件名、（b）公開鍵、通常（c）いくつかの追加のデータ項目（例えば、X.509 Public-）を使用して、公開鍵証明書を作成します。鍵証明書」）。
$ biometric authentication (I) A method of generating authentication information for a person by digitizing measurements of a physical or behavioral characteristic, such as a fingerprint, hand shape, retina pattern, voiceprint, handwriting style, or face.
$バイオメトリック認証（i）指紋、手形状、網膜パターン、声紋、手書きスタイル、または顔など、物理的または行動特性の測定値をデジタル化することによって、人の認証情報を生成する方法。
$ birthday attack (I) A class of attacks against cryptographic functions, including both encryption functions and hash functions. The attacks take advantage of a statistical property: Given a cryptographic function having an N-bit output, the probability is greater than 1/2 that for 2**(N/2) randomly chosen inputs, the function will produce at least two outputs that are identical. (See: Tutorial under "hash function".)
$ 誕生日攻撃（i）暗号化機能とハッシュ関数の両方を含む暗号機能に対する攻撃のクラス。攻撃は統計的性質を利用しています.Nビット出力を持つ暗号機能が与えられると、確率は2 **（N / 2）のランダムに選択された入力では1/2より大きい、関数は少なくとも2つの出力を生成します。それは同じです。（「ハッシュ関数」の「チュートリアル」を参照）
Derivation: From the somewhat surprising fact (often called the "birthday paradox") that although there are 365 days in a year, the probability is greater than 1/2 that two of more people share the same birthday in any randomly chosen group of 23 people.
派生：一年で365日があるが、確率は1/2以上の23人よりも大きい2つの人々の2つの人々のランダムに選ばれたグループで同じ誕生日を共有するという確率は1/2より大きいことです。人。
Birthday attacks enable an adversary to find two inputs for which a cryptographic function produces the same cipher text (or find two inputs for which a hash functions produces the same hash result) much faster than a brute-force attack can; and a clever adversary can use such a capability to create considerable mischief. However, no birthday attack can enable an adversary to decrypt a given cipher text (or find a hash input that results in a given hash result) any faster than a brute-force attack can.
誕生日攻撃により、暗号機能が同じ暗号テキストを生成する2つの入力を見つけることができます（または、ハッシュ関数が同じハッシュ結果を生成する2つの入力を見つける）ブルートフォース攻撃よりもはるかに高速になります。そして賢い敵対者は、かなりのいたずらを生み出すためにそのような能力を使うことができます。しかしながら、誕生日攻撃は、敵対者が所与の暗号テキストを復号化することを可能にすることができる（または、所与のハッシュ結果をもたらすハッシュ入力を見つける）（ブルートフォース攻撃よりも早くすることができるハッシュ入力を見つけることができる。
$ bit (I) A contraction of the term "binary digit"; the smallest unit of information storage, which has two possible states or values. The values usually are represented by the symbols "0" (zero) and "1" (one). (See: block, byte, nibble, word.)
$ ビット（i）「2進数」という用語の縮小。2つの可能な状態または値を有する情報記憶装置の最小単位。値は通常「0」（ゼロ）と「1」（1）で表される。（参照：ブロック、バイチ、ニブル、ワード。）
$ bit string (I) A sequence of bits, each of which is either "0" or "1".
$ ビット文字列（i）ビットのシーケンスは、それぞれ "0"または "1"のいずれかです。
$ BLACK 1. (N) Designation for data that consists only of cipher text, and for information system equipment items or facilities that handle only cipher text. Example: "BLACK key". (See: BCR, color change, RED/BLACK separation. Compare: RED.)
$ Black 1.（n）暗号テキストのみ、および暗号テキストのみを処理するシステム機器の項目または機能のみで構成されたデータの指定。例：「黒キー」。（BCR、色の変更、赤/黒の分離。比較：赤）
2. (O) /U.S. Government/ "Designation applied to information systems, and to associated areas, circuits, components, and equipment, in which national security information is encrypted or is not processed." [C4009]
2. （O）/U.S。政府/「情報システムに適用された指定、および国家セキュリティ情報が暗号化されているか処理されていない関連分野、回路、コンポーネント、および機器に適用されます。[C4009]
3. (D) Any data that can be disclosed without harm.
3. （d）害なしに開示できるデータ。
Deprecated Definition: IDOCs SHOULD NOT use the term with definition 3 because the definition is ambiguous with regard to whether or not the data is protected.
定義廃止予定：データが保護されているかどうかに関して定義があいまいであるため、IDocは定義3で用語を使用しないでください。
$ BLACK/Crypto/RED (BCR) (N) An experimental, end-to-end, network packet encryption system developed in a working prototype form by BBN and the Collins Radio division of Rockwell Corporation in the 1975-1980 time frame for the U.S. DoD. BCR was the first network security system to support TCP/IP traffic, and it incorporated the first DES chips that were validated by the U.S. National Bureau of Standards (now called NIST). BCR also was the first to use a KDC and an ACC to manage connections.
$ ブラック/暗号/赤（BCR）（n）BBNによる作業用プロトタイプ形式で開発された実験的、エンドツーエンド、ネットワークパケット暗号化システムは、1975年から1980年の間のRockwell Corporationのコリンズラジオ部門で開発されました。ドッド。BCRは、TCP / IPトラフィックをサポートする最初のネットワークセキュリティシステムであり、米国国家局（現在はNISTと呼ばれる）によって検証された最初のDESチップを組み込んだ。BCRは、接続を管理するためにKDCとACCを使用する最初のものでした。
$ BLACK key (N) A key that is protected with a key-encrypting key and that must be decrypted before use. (See: BLACK. Compare: RED key.)
$ Blackキー（n）キー暗号化キーで保護されており、使用前に復号化する必要があります。（ブラックを参照してください。比較：Red Key。）
$ BLACKER (O) An end-to-end encryption system for computer data networks that was developed by the U.S. DoD in the 1980s to provide host-to-host data confidentiality service for datagrams at OSIRM Layer 3. [Weis] (Compare: CANEWARE, IPsec.)
$ Blacker（O）1980年代の米国のDODによって開発されたコンピュータデータネットワークのためのエンドツーエンド暗号化システム。[Weis]（比較：CANewareと比較します。、ipsec。）
Tutorial: Each user host connects to its own bump-in-the-wire encryption device called a BLACKER Front End (BFE, TSEC/KI-111), through which the host connects to the subnetwork. The system also includes two types of centralized devices: one or more KDCs connect to the subnetwork and communicate with assigned sets of BFEs, and one or more ACCs connect to the subnetwork and communicate with assigned KDCs. BLACKER uses only symmetric encryption. A KDC distributes session keys to BFE pairs as authorized by an ACC. Each ACC maintains a database for a set of BFEs, and the database determines which pairs from that set (i.e., which pairs of user hosts behind the BFEs) are authorized to communicate and at what security levels.
チュートリアル：各ユーザーホストは、ブラックフロントエンド（BFE、TSEC / KI-111）と呼ばれる独自のバンプインサイト暗号化デバイスに接続します。これを通過するホストはサブネットワークに接続します。このシステムには2種類の集中型デバイスも含まれています。1つ以上のKDCSはサブネットワークに接続し、割り当てられたBFESセットと通信し、1つ以上のACCはサブネットワークに接続し、割り当てられたKDCと通信します。Blackerは対称暗号化のみを使用します。KDCは、ACCによって許可されているように、セッションキーをBFEペアに分配します。各ACCはデータベースのセットを保持し、データベースはそのセットからの（すなわち、どのペアのユーザホストのペアがBFESの後ろにある）とが通信を許可され、どのセキュリティレベルであるかを決定します。
The BLACKER system is MLS in three ways: (a) The BFEs form a security perimeter around a subnetwork, separating user hosts from the subnetwork, so that the subnetwork can operate at a different security level (possibly a lower, less expensive level) than the hosts. (b) The BLACKER components are trusted to separate datagrams of different security levels, so that each datagram of a given security level can be received only by a host that is authorized for that security level; and thus BLACKER can separate host communities that operate at different security levels. (c) The host side of a BFE is itself MLS and can recognize a security label on each packet, so that an MLS user host can be authorized to successively transmit datagrams that are labeled with different security levels.
Blockerシステムは3つの方法でMLSです。（a）BFEはサブネットワークの周囲にセキュリティ周辺を形成し、サブネットワークからユーザーホストを区切って、サブネットワークは異なるセキュリティレベル（おそらくより低い、安価なレベル）で動作することができます。ホスト（b）黒いコンポーネントは、異なるセキュリティレベルのデータグラムを区切ると信頼されているので、特定のセキュリティレベルの各データグラムは、そのセキュリティレベルに対して許可されているホストによってのみ受信できます。したがって、黒人は、さまざまなセキュリティレベルで動作するホストコミュニティを分離できます。（c）BFEのホスト側はそれ自体MLSであり、各パケット上のセキュリティラベルを認識することができるので、MLSユーザホストは異なるセキュリティレベルでラベル付けされたデータグラムを連続的に送信することができます。
$ blind attack (I) A type of network-based attack method that does not require the attacking entity to receive data traffic from the attacked entity; i.e., the attacker does not need to "see" data packets sent by the victim. Example: SYN flood.
$ ブラインドアタック（i）攻撃したエンティティからデータトラフィックを受信する必要がないネットワークベースの攻撃方法の一種。すなわち、攻撃者は、被害者によって送信されたデータパケットを「見る」必要はない。例：Syn Flood。
Tutorial: If an attack method is blind, the attacker's packets can carry (a) a false IP source address (making it difficult for the victim to find the attacker) and (b) a different address on every packet (making it difficult for the victim to block the attack). If the attacker needs to receive traffic from the victim, the attacker must either (c) reveal its own IP address to the victim (which enables the victim to find the attacker or block the attack by filtering) or (d) provide a false address and also subvert network routing mechanisms to divert the returning packets to the attacker (which makes the attack more complex, more difficult, or more expensive). [R3552]
チュートリアル：攻撃方法が盲目である場合、攻撃者のパケットは誤ったIP送信元アドレスを持ち運ぶことができます（被害者が攻撃者が攻撃者を見つけるのは困難にする）、（b）あらゆるパケットのさまざまなアドレス（攻撃をブロックする犠牲者）。攻撃者が犠牲者からのトラフィックを受信する必要がある場合、攻撃者は（C）のいずれか（C）を被害者に明らかにしなければならない（被害者が攻撃者を見つけることができ、またはフィルタリングによる攻撃をブロックすることができます）、または（d）を提供するまた、ネットワークルーティングメカニズムを削除して、戻りパケットを攻撃者に転送する（攻撃をより複雑になり、より困難な、またはより高価にする）。[R3552]
$ block (I) A bit string or bit vector of finite length. (See: bit, block cipher. Compare: byte, word.)
$ ブロック（i）有限長のビット列またはビットベクトル。（：ビット、ブロック暗号。比較：バイト、ワード。）
Usage: An "N-bit block" contains N bits, which usually are numbered from left to right as 1, 2, 3, ..., N.
使用法：「Nビットブロック」にはNビットが含まれています。これは通常1,2,3、...、Nです。
$ block cipher (I) An encryption algorithm that breaks plain text into fixed-size segments and uses the same key to transform each plaintext segment into a fixed-size segment of cipher text. Examples: AES, Blowfish, DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream cipher.)
$ ブロック暗号（i）プレーンテキストを固定サイズのセグメントに分割し、各平文セグメントを暗号テキストの固定サイズのセグメントに変換するために同じキーを使用する暗号化アルゴリズム。例：AES、Blowfish、DEA、IDEA、RC2、およびSKIPJACK。（以下：ブロック、モード。比較：ストリーム暗号を比較します。）
Tutorial: A block cipher can be adapted to have a different external interface, such as that of a stream cipher, by using a mode of cryptographic operation to package the basic algorithm. (See: CBC, CCM, CFB, CMAC, CTR, DEA, ECB, OFB.)
チュートリアル：ブロック暗号は、基本アルゴリズムをパッケージするための暗号化操作のモードを使用することによって、ストリーム暗号のような異なる外部インタフェースを有するように適合させることができる。（CBC、CCM、CFB、CMAC、CTR、DEA、ECB、OFB。）
$ Blowfish (N) A symmetric block cipher with variable-length key (32 to 448 bits) designed in 1993 by Bruce Schneier as an unpatented, license-free, royalty-free replacement for DES or IDEA. [Schn] (See: Twofish.)
$ Blowfish（n）1993年に設計された可変長キー（32~448ビット）を持つ対称ブロック暗号（32~448ビット）は、Bruce Schneierによって、無意味な、ライセンスフリー、DESやアイデアのためのロイヤリティフリーの代替品です。[シュン]（：Twofish。）
$ brain-damaged (D) /slang/ "Obviously wrong: extremely poorly designed. Calling something brain-damaged is very extreme. The word implies that the thing is completely unusable, and that its failure to work is due to poor design, not accident." [NCSSG] (See: flaw.)
$ 脳損傷（D）/スラング/「明らかに間違っています。。」[NCSSG]（「欠陥」を参照してください。）
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ brand 1. (I) A distinctive mark or name that identifies a product or business entity.
$ ブランド1.（i）製品またはビジネスエンティティを識別する独特のマークまたは名前。
2. (O) /SET/ The name of a payment card. (See: BCA.)
2. （O）/セット/決済カードの名前。（参照：BCAを参照してください。）
Tutorial: Financial institutions and other companies have founded payment card brands, protect and advertise the brands, establish and enforce rules for use and acceptance of their payment cards, and provide networks to interconnect the financial institutions. These brands combine the roles of issuer and acquirer in interactions with cardholders and merchants. [SET1]
チュートリアル：金融機関やその他の会社は、支払いカードブランドを設立し、ブランドの保護、宣伝、支払いカードの使用と受け入れのための規則を確立し、執行し、金融機関を相互接続するためのネットワークを提供しました。これらのブランドは、発行者と買収者の役割と、カード保有者や商人との対話で組み合わせました。[SET1]
$ brand certification authority (BCA) (O) /SET/ A CA owned by a payment card brand, such as MasterCard, Visa, or American Express. [SET2] (See: certification hierarchy, SET.)
$ MasterCard、Visa、American Expressなどの支払いカードブランドが所有するブランド認証局（BCA）/セット/ A CA。[SET2]（SEE：CERTICATION階層、設定）
$ brand CRL identifier (BCI) (O) /SET/ A digitally signed list, issued by a BCA, of the names of CAs for which CRLs need to be processed when verifying signatures in SET messages. [SET2]
$ BCAの名前のBCAによって発行されたブランドCRL ID（BCI）/セット/セット/セット/セット/ CRLがセットされたメッセージ内の署名を検証するときに処理されるCASの名前。[SET2]
$ break (I) /cryptography/ To successfully perform cryptanalysis and thus succeed in decrypting data or performing some other cryptographic function, without initially having knowledge of the key that the function requires. (See: penetrate, strength, work factor.)
$ Break（I）/ Cryptography / CryptAnalysisを正常に実行し、したがってデータの復号化または他の暗号機能の実行に成功し、最初は機能が必要とする鍵の知識を持たない。（浸透し、強さ、仕事係数を参照してください。）
Usage: This term applies to encrypted data or, more generally, to a cryptographic algorithm or cryptographic system. Also, while the most common use is to refer to completely breaking an algorithm, the term is also used when a method is found that substantially reduces the work factor.
使用法：この用語は、暗号化されたデータ、またはより一般的には暗号化アルゴリズムまたは暗号化システムに適用されます。また、最も一般的な用途はアルゴリズムを完全に破壊することを指すことであるが、作業係数を実質的に減少させる方法が見つかった場合にも使用される。
$ Brewer-Nash model (N) A security model [BN89] to enforce the Chinese wall policy. (Compare: Bell-LaPadula model, Clark-Wilson model.)
$ Brewer-Nash Model（N）中国の壁ポリシーを強制するためのセキュリティモデル[BN89]。（比較：ベルララドゥラモデル、クラーク - ウィルソンモデル）
Tutorial: All proprietary information in the set of commercial firms F(1), F(2), ..., F(N) is categorized into mutually exclusive conflict-of-interest classes I(1), I(2), ..., I(M) that apply across all firms. Each firm belongs to exactly one class. The Brewer-Nash model has the following mandatory rules: - Brewer-Nash Read Rule: Subject S can read information object O from firm F(i) only if either (a) O is from the same firm as some object previously read by S *or* (b) O belongs to a class I(i) from which S has not previously read any object. (See: object, subject.) - Brewer-Nash Write Rule: Subject S can write information object O to firm F(i) only if (a) S can read O by the Brewer-Nash Read Rule *and* (b) no object can be read by S from a different firm F(j), no matter whether F(j) belongs to the same class as F(i) or to a different class.
チュートリアル：商業会社のセットのすべての所有権f（1）、f（2）、...、f（n）は、相互に排他的な金利クラスI（1）、i（2）に分類されます。...、すべての企業に適用されるi（m）。各会社は正確に1つのクラスに属します。BREWER-NASHモデルには、次の必須規則があります。*または*（b）oは、以前にオブジェクトを読み取っていないクラスI（i）に属します。（参照、件名。） - BREWER-NASH書き込みルール：サブジェクトSは、BREWER-NASH READ RULE *と*（B）でOを読み取ることができれば（a）の場合にのみ情報オブジェクトOを書くことができます。f（j）がf（i）と同じクラスまたは異なるクラスに属しているかどうかにかかわらず、異なる企業のf（j）からsによってオブジェクトを読み取ることはできません。
$ bridge (I) A gateway for traffic flowing at OSIRM Layer 2 between two networks (usually two LANs). (Compare: bridge CA, router.)
$ ブリッジ（i）2つのネットワーク間（通常2 LAN）の間でOSIRMレイヤ2を流れるトラフィックのゲートウェイ。（比較：ブリッジCA、ルーター。）
$ bridge CA (I) A PKI consisting of only a CA that cross-certifies with CAs of some other PKIs. (See: cross-certification. Compare: bridge.)
$ Bridge CA（i）他のPKIのキャストと交差したCAのみからなるPKI。（以下を参照してください。比較：ブリッジを比較してください。）
Tutorial: A bridge CA functions as a hub that enables a certificate user in any of the PKIs that attach to the bridge, to validate certificates issued in the other attached PKIs.
チュートリアル：Bridge CAは、ブリッジに接続されているPKIのいずれかの証明書ユーザーとして機能し、他の接続されたPKIで発行された証明書を検証することができます。
For example, a bridge CA (BCA) CA1
could cross-certify with four ^
PKIs that have the roots CA1, |
CA2, CA3, and CA4. The cross- v
certificates that the roots CA2 <-> BCA <-> CA3
exchange with the BCA enable an ^
end entity EE1 certified under |
under CA1 in PK1 to construct v
a certification path needed to CA4
validate the certificate of
end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2
or vice versa. CA2 -> BCA -> CA1 -> EE1
$ British Standard 7799 (N) Part 1 of the standard is a code of practice for how to secure an information system. Part 2 specifies the management framework, objectives, and control requirements for information security management systems. [BS7799] (See: ISO 17799.)
$ British Standard 7799（n）基準の第1部は、情報システムを保護する方法の標準コードです。パート2は、情報セキュリティ管理システムの管理フレームワーク、目標、および制御要件を指定します。[BS7799]（参照：ISO 17799.参照）
$ browser (I) A client computer program that can retrieve and display information from servers on the World Wide Web. Examples: Netscape Navigator and Microsoft Internet Explorer.
$ ブラウザ（i）ワールドワイドウェブ上のサーバから情報を取得して表示できるクライアントコンピュータプログラム。例：Netscape NavigatorとMicrosoft Internet Explorer。
$ brute force (I) A cryptanalysis technique or other kind of attack method involving an exhaustive procedure that tries a large number of possible solutions to the problem. (See: impossible, strength, work factor.)
$ ブルートフォース（i）問題に対して多数の可能な解決策を試みる徹底的な手順を含む、暗号化技術または他の種類の攻撃方法。（：不可能、強さ、仕事係数。）
Tutorial: In some cases, brute force involves trying all of the possibilities. For example, for cipher text where the analyst already knows the decryption algorithm, a brute-force technique for finding matching plain text is to decrypt the message with every possible key. In other cases, brute force involves trying a large number of possibilities but substantially fewer than all of them. For example, given a hash function that produces an N-bit hash result, the probability is greater than 1/2 that the analyst will find two inputs that have the same hash result after trying only 2**(N/2) randomly chosen inputs. (See: birthday attack.)
チュートリアル：場合によっては、ブルートフォースはすべての可能性を試みることを含みます。たとえば、アナリストが既に復号化アルゴリズムを知っている暗号テキストの場合、一致するプレーンテキストを見つけるためのブルートフォース技術は、すべての可能キーでメッセージを復号化することです。他の場合には、ブルートフォースは多数の可能性を試しているがそれらのすべてよりも実質的に少ない可能性を伴う。たとえば、Nビットハッシュ結果を生成するハッシュ関数を考えると、アナリストが2 **（N / 2）をランダムに選択した後に同じハッシュ結果を持つ2つの入力を見つける1/2より大きくなります。入力（参照：誕生日攻撃）
$ BS7799 (N) See: British Standard 7799.
$ BS7799（N）参照：イギリス標準7799。
$ buffer overflow (I) Any attack technique that exploits a vulnerability resulting from computer software or hardware that does not check for exceeding the bounds of a storage area when data is written into a sequence of storage locations beginning in that area.
$ バッファオーバーフロー（i）データがその領域で始まる一連のストレージ位置に書き込まれるときに、コンピュータソフトウェアまたはハードウェアから生じる脆弱性を悪用する攻撃技術。
Tutorial: By causing a normal system operation to write data beyond the bounds of a storage area, the attacker seeks to either disrupt system operation or cause the system to execute malicious software inserted by the attacker.
チュートリアル：通常のシステム操作を記憶領域の境界を超えてデータを書き込むことによって、攻撃者はシステム運用を中断したり、システムに攻撃者によって挿入された悪質なソフトウェアを実行させることを目指しています。
$ buffer zone (I) A neutral internetwork segment used to connect other segments that each operate under a different security policy.
$ バッファゾーン（i）それぞれが異なるセキュリティポリシーの下で動作する他のセグメントを接続するために使用される中立的なインターネットワークセグメント。
Tutorial: To connect a private network to the Internet or some other relatively public network, one could construct a small, separate, isolated LAN and connect it to both the private network and the public network; one or both of the connections would implement a firewall to limit the traffic that could pass through the buffer zone.
チュートリアル：プライベートネットワークをインターネットまたは他の何らかの比較的公衆ネットワークに接続することは、小さく、分離されたLANを構築し、それをプライベートネットワークと公衆ネットワークの両方に接続することができます。接続の一方または両方の接続は、バッファゾーンを通過する可能性があるトラフィックを制限するためにファイアウォールを実装するであろう。
$ bulk encryption 1. (I) Encryption of multiple channels by aggregating them into a single transfer path and then encrypting that path. (See: channel.)
$ バルク暗号化1.（i）それらを単一の転送パスに集約してからそのパスを暗号化することによって複数のチャネルの暗号化。（：チャンネルを参照してください。）
2. (O) "Simultaneous encryption of all channels of a multichannel telecommunications link." [C4009] (Compare: bulk keying material.)
2. （O）「マルチチャンネル電気通信リンクの全チャネルの同時暗号化」[C4009]（比較：バルクキーイング材料）
Usage: The use of "simultaneous" in definition 2 could be interpreted to mean that multiple channels are encrypted separately but at the same time. However, the common meaning of the term is that multiple data flows are combined into a single stream and then that stream is encrypted as a whole.
使用法：定義2の「同時」の使用は、複数のチャネルが別々に暗号化されているが同時に暗号化されることを意味すると解釈される可能性があります。しかしながら、この用語の一般的な意味は、複数のデータフローが単一のストリームに結合され、そのストリーム全体として暗号化されることである。
$ bulk key (D) In a few published descriptions of hybrid encryption for SSH, Windows 2000, and other applications, this term refers to a symmetric key that (a) is used to encrypt a relatively large amount of data and (b) is itself encrypted with a public key. (Compare: bulk keying material, session key.)
$ バルクキー（d）SSH、Windows 2000、およびその他のアプリケーションのハイブリッド暗号化のいくつかの公開された説明では、この用語は比較的大量のデータを暗号化するために（a）が使用され、（b）はそれ自体である対称鍵を指します。公開鍵で暗号化されています。（比較：バルクキーイング素材、セッションキー）
Example: To send a large file to Bob, Alice (a) generates a symmetric key and uses it to encrypt the file (i.e., encrypt the bulk of the information that is to be sent) and then (b) encrypts that symmetric key (the "bulk key") with Bob's public key.
例：大規模なファイルをBOBに送信するには、Alice（A）はSymmetricキーを生成し、それを使用してファイルを暗号化する（すなわち、送信される情報の大部分を暗号化されて）、その対称キーを暗号化します（B）。BOBの公開鍵付きの「バルクキー」）。
Deprecated Term: IDOCs SHOULD NOT use this term or definition; the term is not well-established and could be confused with the established term "bulk keying material". Instead, use "symmetric key" and carefully explain how the key is applied.
廃止予定語：IDocはこの用語または定義を使用しないでください。この用語は十分に確立されておらず、確立された用語「バルクキーイング材料」と混同することができます。代わりに、「対称鍵」を使用し、キーの適用方法について慎重に説明してください。
$ bulk keying material (N) Refers to handling keying material in large quantities, e.g., as a dataset that contains many items of keying material. (See: type 0. Compare: bulk key, bulk encryption.)
$ バルクキーイング材料（N）は、例えば、キーイング材料の多くの項目を含むデータセットとして、大量のキーイング材料を取扱うものを指す。（以下を参照してください。比較：バルクキー、バルク暗号化。）
$ bump-in-the-stack (I) An implementation approach that places a network security mechanism inside the system that is to be protected. (Compare: bump-in-the-wire.) Example: IPsec can be implemented inboard, in the protocol stack of an existing system or existing system design, by placing a new layer between the existing IP layer and the OSIRM Layer 3 drivers. Source code access for the existing stack is not required, but the system that contains the stack does need to be modified [R4301].
$ bump-in-the-stack（i）保護されるシステム内にネットワークセキュリティメカニズムを配置する実装方法。例：IPSecは、既存のIP層とOSIRR層3のドライバとの間に新しいレイヤーを配置することによって、既存のシステムまたは既存のシステム設計のプロトコルスタックでIPSECをインプロードすることができます。既存のスタックのソースコードアクセスは必須ではありませんが、スタックを含むシステムを変更する必要があります[R4301]。
$ bump-in-the-wire (I) An implementation approach that places a network security mechanism outside of the system that is to be protected. (Compare: bump-in-the-stack.)
$ バンプインワイヤ（i）保護されるべきシステムの外側にネットワークセキュリティメカニズムを配置する実装方法。（比較：バンプインスタック）
Example: IPsec can be implemented outboard, in a physically separate device, so that the system that receives the IPsec protection does not need to be modified at all [R4301]. Military-grade link encryption has mainly been implemented as bump-in-the-wire devices.
例：IPsecは、物理的に別々のデバイスで、IPSec保護を受け取るシステムをすべての[R4301]で変更する必要はありません。ミリタリーグレードのリンク暗号化は主にバンプインワイヤデバイスとして実装されています。
$ business-case analysis (N) An extended form of cost-benefit analysis that considers factors beyond financial metrics, including security factors such as the requirement for security services, their technical and programmatic feasibility, their qualitative benefits, and associated risks. (See: risk analysis.)
$ ビジネスケース分析（n）セキュリティサービスの要求、それらの技術的およびプログラム的な実現可能性、それらの定性的利益、および関連するリスクなどのセキュリティ要因を含む、財務計測基準を超えた要因を考慮した費用便益分析の長さの費用対効果分析。（リスク分析を参照してください。）
$ byte (I) A fundamental unit of computer storage; the smallest addressable unit in a computer's architecture. Usually holds one character of information and, today, usually means eight bits. (Compare: octet.)
$ バイト（i）コンピュータストレージの基本単位。コンピュータのアーキテクチャの中で最小のアドレス指定可能なユニット。通常、情報の1文字を保持し、今日は通常8ビットを意味します。（比較：オクテット）
Usage: Understood to be larger than a "bit", but smaller than a "word". Although "byte" almost always means "octet" today, some computer architectures have had bytes in other sizes (e.g., six bits, nine bits). Therefore, an STD SHOULD state the number of bits in a byte where the term is first used in the STD.
使用法：「ビット」よりも大きくなると理解されているが、「単語」よりも小さいと理解されている。「バイト」はほとんど常に「オクテット」を意味しますが、一部のコンピュータアーキテクチャは他のサイズ（例えば、6ビット、9ビット）のバイトを持っています。したがって、STDは、STDで最初に使用されるバイト内のビット数を述べるべきです。
$ C field (D) See: Compartments field.
$ Cフィールド（d）コンパートメントフィールドを参照してください。
$ C1 or C2 computer system (O) /TCSEC/ See: Tutorial under "Trusted Computer System Evaluation Criteria".
$ C1またはC2コンピュータシステム（O）/ TCSEC /参照：「信頼できるコンピュータシステム評価基準」の下のチュートリアル。
$ CA (I) See: certification authority.
$ （i）認証局を参照してください。
$ CA certificate (D) "A [digital] certificate for one CA issued by another CA." [X509]
$ CA証明書（D）「別のCAが発行した1つのCA用の[デジタル]証明書 "[X509]
Deprecated Definition: IDOCs SHOULD NOT use the term with this definition; the definition is ambiguous with regard to how the certificate is constructed and how it is intended to be used. IDOCs that use this term SHOULD provide a technical definition for it. (See: certificate profile.)
廃止予定の定義：IDocsはこの定義で用語を使用しないでください。証明書がどのように構築されているか、そしてそれがどのように使用されることを意図しているかに関して、定義はあいまいです。この用語を使用するIDocは、それに技術的な定義を提供する必要があります。（証明書プロファイルを参照してください。）
Tutorial: There is no single, obvious choice for a technical definition of this term. Different PKIs can use different certificate profiles, and X.509 provides several choices of how to issue certificates to CAs. For example, one possible definition is the following: A v3 X.509 public-key certificate that has a "basicConstraints" extension containing a "cA" value of "TRUE". That would specifically indicate that "the certified public key may be used to verify certificate signatures", i.e., that the private key may be used by a CA.
チュートリアル：この用語の技術的な定義には独身で明白な選択はありません。異なるPKIは異なる証明書プロファイルを使用することができ、X.509にはCASに証明書を発行する方法のいくつかの選択肢があります。たとえば、1つの可能な定義は次のとおりです。「True」の「CA」値を含む「基本情報」拡張子を持つv3 x.509公開鍵証明書。これは、「認証された公開鍵を使用して証明書署名を検証するために使用されてもよく、すなわち、秘密鍵を使用してCAで使用することができる。
However, there also are other ways to indicate such usage. The certificate may have a "key Usage" extension that indicates the purposes for which the public key may be used, and one of the values that X.509 defines for that extension is "keyCertSign", to indicate that the certificate may be used for verifying a CA's signature on certificates. If "keyCertSign" is present in a certificate that also has a "basicConstraints" extension, then "cA" is set to "TRUE" in that extension. Alternatively, a CA could be issued a certificate in which "keyCertSign" is asserted without "basicConstraints" being present; and an entity that acts as a CA could be issued a certificate with "keyUsage" set to other values, either with or without "keyCertSign".
ただし、そのような使用を示す他の方法もあります。証明書は、公開鍵を使用することができる目的を示す「鍵使用法」拡張子と、その拡張子を定義する値の1つが「keyCertSign」で、証明書を使用することができることを示します。証明書に対するCAの署名を検証します。"keyCertSign"が "BasicConstraints"拡張機能もある証明書に存在する場合は、その拡張子で "ca"が "true"に設定されます。あるいは、「BASICConstraints」が存在することなく、「keyCertSign」がアサートされている証明書を発行することもできます。CAとして機能するエンティティは、 "KeyUsage"を持つ証明書を "keycertsign"の有無にかかわらず、他の値に設定されている証明書を発行することができます。
$ CA domain (N) /PKI/ A security policy domain that "consists of a CA and its subjects [i.e., the entities named in the certificates issued by the CA]. Sometimes referred to as a PKI domain." [PAG] (See: domain.)
$ CAドメイン（N）/ PKI / Aセキュリティポリシードメインは、CAとその対象からなる[すなわち、CAによって発行された証明書に命名されたエンティティ]からなる。PKIドメインと呼ばれることもあります。」[PAG]（ドメインを参照）
$ Caesar cipher
(I) A cipher that is defined for an alphabet of N characters,
A(1), A(2), ..., A(N), and creates cipher text by replacing each
plaintext character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn]
Examples: (a) During the Gallic wars, Julius Caesar used a cipher with K=3. In a Caesar cipher with K=3 for the English alphabet, A is replaced by D, B by E, C by F, ..., W by Z, X by A, Y by B, Z by C. (b) UNIX systems sometimes include "ROT13" software that implements a Caesar cipher with K=13 (i.e., ROTate by 13).
例：（a）Gallic Warsの間に、Julius CaesarはK = 3の暗号を使用しました。英語のアルファベットのK = 3のCaesar暗号では、aは、z、...、wによってe、bによってd、bによって置き換えられます。UNIXシステムは、K = 13でシーザー暗号を実装する「ROT13」ソフトウェアを含む（すなわち、13回回転）。
$ call back (I) An authentication technique for terminals that remotely access a computer via telephone lines; the host system disconnects the caller and then reconnects on a telephone number that was previously authorized for that terminal.
$ コールバック（i）電話回線を介してコンピュータに遠隔アクセスする端末の認証技術。ホストシステムは発信者を切断してから、以前にその端末に対して承認された電話番号で再接続します。
$ CAM (O) See: Certificate Arbitrator Module.
$ CAM（O）証明書arbitratorモジュールを参照してください。
$ CANEWARE (O) An end-to-end encryption system for computer data networks that was developed by the U.S. DoD in the 1980s to provide host-to-host data confidentiality service for datagrams in OSIRM Layer 3. [Roge] (Compare: BLACKER, IPsec.)
$ CAAWARE（O）1980年代の米国のDODによって開発されたコンピュータデータネットワークのためのエンドツーエンド暗号化システム3. [Roge]（Roge]（Comport：Blacker）、ipsec。）
Tutorial: Each user host connects to its own bump-in-the-wire encryption device called a CANEWARE Front End (CFE), through which the host connects to the subnetwork. CANEWARE uses symmetric encryption for CFE-to-CFE traffic, but also uses FIREFLY to establish those session keys. The public-key certificates issued by the FIREFLY system include credentials for mandatory access control. For discretionary access control, the system also includes one or more centralized CANEWARE Control Processors (CCPs) that connect to the subnetwork, maintain a database for discretionary access control authorizations, and communicate those authorizations to assigned sets of CFEs.
チュートリアル：各ユーザホストは、自由野内フロントエンド（CFE）と呼ばれる独自のバンプインサイト暗号化装置に接続します。これを通してホストはサブネットワークに接続します。CAAWAREはCFEからCFEトラフィックの対称暗号化を使用しますが、Fireflyを使用してそれらのセッションキーを確立します。Fireflyシステムによって発行された公開鍵証明書には、必須アクセス制御のための資格情報が含まれています。任意アクセス制御のために、システムはサブネットワークに接続し、任意のアクセス制御権限のためのデータベースを維持し、それらの許可をCFEのセットに通信する1つまたは複数の集中型カヌワレ制御プロセッサ（CCP）も含まれています。
The CANEWARE system is MLS in only two of the three ways that BLACKER is MLS: (a) Like BLACKER BFEs, CFEs form a security perimeter around a subnetwork, separating user hosts from the subnetwork, so that the subnetwork can operate at a different security level than the hosts. (b) Like BLACKER, the CANEWARE components are trusted to separate datagrams of different security levels, so that each datagram of a given security level can be received only by a host that is authorized for that security level; and thus CANEWARE can separate host communities that operate at different security levels. (c) Unlike a BFE, the host side of a CFE is not MLS, and treats all packets received from a user host as being at the same mandatory security level.
CANewareシステムはMLSで、BlockerがMLSの3つの方法のうちの2つだけです。（a）Blacker BFEのように、CFEはサブネットワークの周囲にセキュリティ周辺を形成し、サブネットワークからユーザーホストを区切ってセキュリティを作成します。ホストよりもレベル。（b）Blockerと同様に、CANewareコンポーネントは、異なるセキュリティレベルのデータグラムを区切ると信頼されているため、特定のセキュリティレベルの各データグラムをそのセキュリティレベルに対して許可されているホストによってのみ受信できます。したがって、CAAWAREは、さまざまなセキュリティレベルで動作するホストコミュニティを分離できます。（c）BFEとは異なり、CFEのホスト側はMLSではなく、ユーザホストから受信したすべてのパケットを同じ必須セキュリティレベルにあると扱います。
$ capability list (I) /information system/ A mechanism that implements access control for a system entity by enumerating the system resources that the entity is permitted to access and, either implicitly or explicitly, the access modes granted for each resource. (Compare: access control list, access control matrix, access profile, capability token.)
$ Capability List（I）/情報システム/システムエンティティのアクセス制御を実装するメカニズムエンティティにアクセスが許可され、暗黙的または明示的に各リソースに対して付与されたアクセスモードを列挙すること。（Commart：アクセス制御リスト、アクセス制御行列、アクセスプロファイル、機能トークン）
$ capability token (I) A token (usually an unforgeable data object) that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource indicated by the token. (See: attribute certificate, capability list, credential, digital certificate, ticket, token.)
$ 能力トークン（i）システムリソースにアクセスする権利にベアラまたはホルダーを与えるトークン（通常は忘れられないデータオブジェクト）。トークンの所持は、ホルダーがトークンによって示されたリソースにアクセスする権限があるという証明としてシステムによって受け入れられます。（属性証明書、機能リスト、資格情報、デジタル証明書、チケット、トークン）を参照してください。
$ Capability Maturity Model (CMM) (N) Method for judging the maturity of software processes in an organization and for identifying crucial practices needed to increase process maturity. [Chris] (Compare: Common Criteria.)
$ 能力成熟度モデル（CMM）（N）組織内のソフトウェアプロセスの成熟度を判断し、プロセス成熟度を高めるために必要な重要な慣行を識別するための方法。[CHRIS]（比較：共通基準）
Tutorial: The CMM does not specify security evaluation criteria (see: assurance level), but its use may improve security assurance. The CMM describes principles and practices that can improve software processes in terms of evolving from ad hoc processes to disciplined processes. The CMM has five levels: - Initial: Software processes are ad hoc or chaotic, and few are well-defined. Success depends on individual effort and heroics. - Repeatable: Basic project management processes are established to track cost, schedule, and functionality. Necessary process discipline is in place to repeat earlier successes on projects with similar applications. - Defined: Software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. Each project uses an approved, tailored version of the organization's standard process for developing and maintaining software. - Managed: Detailed measures of software process and product quality are collected. Both software process and products are quantitatively understood and controlled. - Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
チュートリアル：CMMはセキュリティ評価基準を指定しません（保証レベルを参照）、その使用はセキュリティ保証を改善する可能性があります。 CMMは、アドホックプロセスから統制されたプロセスへ進化するという点でソフトウェアプロセスを改善することができる原則および慣行を説明しています。 CMMには5つのレベルがあります。 - 初期：ソフトウェアプロセスはアドホックまたはカオスであり、数は明確に定義されています。成功は個々の努力と英雄に依存しています。 - 繰り返し可能：基本プロジェクト管理プロセスは、コスト、スケジュール、および機能を追跡するために確立されています。必要なプロセスの規律は、同様のアプリケーションを持つプロジェクトのより早い成功を繰り返すためのものです。 - 定義された：管理とエンジニアリングの両方の活動のソフトウェアプロセスは、組織の標準的なソフトウェアプロセスに文書化、標準化され、統合されています。各プロジェクトは、ソフトウェアを開発および維持するための組織の標準プロセスの承認された調整版を使用しています。 - 管理：ソフトウェアプロセスの詳細な尺度と製品品質が収集されます。ソフトウェアプロセスと製品の両方が定量的に理解され制御されています。 - 最適化：継続的なプロセスの改善は、プロセスからの定量的なフィードバックと革新的なアイデアや技術の操縦を行います。
$ CAPI (I) See: cryptographic application programming interface.
$ CAPI（i）cryptographicアプリケーションプログラミングインタフェースを参照してください。
$ CAPSTONE (N) An integrated microcircuit (in MYK-8x series manufactured by Mykotronx, Inc.) that implements SKIPJACK, KEA, DSA, SHA, and basic mathematical functions needed to support asymmetric cryptography; has a non-deterministic random number generator; and supports key escrow. (See: FORTEZZA. Compare: CLIPPER.)
$ Capstone（N）Skipjack、Kea、DSA、SHA、および非対称暗号化をサポートするのに必要な基本的な数学関数を実装する統合されたマイクロ回路（Mykotronx、Inc。の中のMyk-8xシリーズ）。非決定論的乱数発生器を持っています。キーエスクローをサポートします。（参照：Fortezza。比較：クリッパー。）
$ card See: cryptographic card, FORTEZZA, payment card, PC card, smart card, token.
$ カード参照：暗号カード、フォルテッツァ、支払いカード、PCカード、スマートカード、トークン。
$ card backup See: token backup.
$ カードバックアップ：トークンバックアップ。
$ card copy See: token copy.
$ カードコピー参照：トークンコピー。
$ card restore See: token restore.
$ カードの復元：トークンの復元。
$ cardholder 1. (I) An entity to whom or to which a card has been issued.
$ カード所有者1.（i）どのカードが発行されたか
Usage: Usually refers to a living human being, but might refer (a) to a position (see: billet, role) in an organization or (b) to an automated process. (Compare: user.)
使用法：通常、人間の生活を指しますが、組織内の位置（a）を、組織または（B）の位置（B）に自動化されたプロセスに参照することがあります。（Compare：ユーザー。）
2. (O) /SET/ "The holder of a valid payment card account and user of software supporting electronic commerce." [SET2] A cardholder is issued a payment card by an issuer. SET ensures that in the cardholder's interactions with merchants, the payment card account information remains confidential. [SET1]
2. （O）/セット/「有効な決済カードアカウントの保有者は、電子商取引をサポートするソフトウェアのユーザー。」[set2]カード保有者は発行者によって決済カードを発行されます。SETは、カード保有者の商人との相互作用では、支払いカードアカウント情報が機密のままです。[SET1]
$ cardholder certificate (O) /SET/ A digital certificate that is issued to a cardholder upon approval of the cardholder's issuing financial institution and that is transmitted to merchants with purchase requests and encrypted payment instructions, carrying assurance that the account number has been validated by the issuing financial institution and cannot be altered by a third party. [SET1]
$ カード所有者証明書（O）/セット/セット/カード保有者の発行金融機関の承認を得て、購入要求および暗号化された支払い指示を伴う商人に送信され、アカウント番号が検証されたという保証を担当します。金融機関を発行し、第三者によって変更することはできません。[SET1]
$ cardholder certification authority (CCA) (O) /SET/ A CA responsible for issuing digital certificates to cardholders and operated on behalf of a payment card brand, an issuer, or another party according to brand rules. A CCA maintains relationships with card issuers to allow for the verification of cardholder accounts. A CCA does not issue a CRL but does distribute CRLs issued by root CAs, brand CAs, geopolitical CAs, and payment gateway CAs. [SET2]
$ カード会員証認証局（CCA）/セット/ CAは、カード保有者へのデジタル証明書発行を担当し、支払いカードブランド、発行者、または他の当事者に代わって運営されています。CCAはカード発行者との関係を維持して、カード保有者勘定の検証を可能にします。CCAはCRLを発行しませんが、ルートCAS、ブランドのCA、地域CAS、および支払いゲートウェイCAによって発行されたCRLを配布します。[SET2]
$ CAST (N) A design procedure for symmetric encryption algorithms, and a resulting family of algorithms, invented by Carlisle Adams (C.A.) and Stafford Tavares (S.T.). [R2144, R2612]
$ CAST（n）CARMMETRIC ENCRYPTIONアルゴリズムの設計手順、およびCarlisle ADAMS（C。）およびStafford Tavares（S.T.）によって発明された結果として生じるアルゴリズムのファミリー。[R2144、R2612]
$ category (I) A grouping of sensitive information items to which a non-hierarchical restrictive security label is applied to increase protection of the data. (See: formal access approval. Compare: compartment, classification.)
$ カテゴリ（i）非階層的な制限セキュリティラベルが適用され、データの保護を増やすために適用される機密情報のグループ化。（正式なアクセス承認を参照してください。比較：コンパートメント、分類。）
$ CAW (N) See: certification authority workstation.
$ CAW（N）認証局のワークステーションを参照してください。
$ CBC (N) See: cipher block chaining.
$ CBC（N）Cipher Block Chainingを参照してください。
$ CCA (O) See: cardholder certification authority.
$ CCA（O）カード所有者の認証局。
$ CCEP (O) See: Commercial COMSEC Endorsement Program.
$ CCEP（O）：商業COMSEC承認プログラムを参照してください。
$ CCI (O) See: Controlled Cryptographic Item.
$ CCI（O）参照：制御暗号化項目を参照してください。
$ CCITT (N) Acronym for French translation of International Telephone and Telegraph Consultative Committee. Now renamed ITU-T.
$ 国際電話と電信諮問委員会のフランス語翻訳のためのCCITT（N）頭字語。ITU-Tと名前を変更しました。
$ CCM (N) See: Counter with Cipher Block Chaining-Message Authentication Code.
$ CCM（N）参照：暗号ブロックチェーンメッセージ認証コードのカウンタ。
$ CERIAS (O) Purdue University's Center for Education and Research in Information Assurance and Security, which includes faculty from multiple schools and departments and takes a multidisciplinary approach to security problems ranging from technical to ethical, legal, educational, communicational, linguistic, and economic.
$ CERIAS（O）Purdue Universityの情報保証のための教育研究センターでは、複数の学校や部門からの教員を含み、技術的、法的、教育、コミュニケーション、言語学、経済的、経済的、経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的、そして経済的に及ぶ情報保証の研究センター。
$ CERT (I) See: computer emergency response team.
$ Cert（i）コンピュータ緊急対応チームを参照してください。
$ certificate 1. (I) /general English/ A document that attests to the truth of something or the ownership of something.
$ 証明書1.（i）/一般英語/何かの真実や何かの所有権に証明する文書。
2. (I) /general security/ See: capability token, digital certificate.
2. （i）/一般セキュリティ/参照：機能トークン、デジタル証明書。
3. (I) /PKI/ See: attribute certificate, public-key certificate.
3. （i）/ PKI /参照：属性証明書、公開鍵証明書。
$ Certificate Arbitrator Module (CAM) (O) An open-source software module that is designed to be integrated with an application for routing, replying to, and otherwise managing and meditating certificate validation requests between that application and the CAs in the ACES PKI.
$ Certificate Arbitrator Module（CAM）（O）そのアプリケーションとACES PKI内のCASの間の証明書検証要求をルーティング、およびその他の方法で管理し、瞑想するためのアプリケーションと統合されるように設計されたオープンソースソフトウェアモジュール。
$ certificate authority (D) Synonym for "certification authority".
$ 認証局（D）「証明機関」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of the term "certification authority", which is preferred in PKI standards (e.g., [X509, R3280]).
廃止予定語：IDocsはこの用語を使用しないでください。それはPKI規格（例えば、[X509、R3280]）において好ましい「認証局」という用語の不注意な使用を示唆している。
$ certificate chain (D) Synonym for "certification path". (See: trust chain.)
$ 証明書チェーン（D）「認証パス」の同義語。（：トラストチェーンを参照してください。）
Deprecated Term: IDOCs SHOULD NOT use this term; it duplicates the meaning of a standardized term. Instead, use "certification path".
廃止予定語：IDocsはこの用語を使用しないでください。標準化された用語の意味を複製します。代わりに、「認証パス」を使用してください。
$ certificate chain validation (D) Synonym for "certificate validation" or "path validation".
$ 証明書チェーン検証（D）「証明書検証」または「パス検証」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it duplicates the meaning of standardized terms and mixes concepts in a potentially misleading way. Instead, use "certificate validation" or "path validation", depending on what is meant. (See: validate vs. verify.)
廃止予定語：IDocsはこの用語を使用しないでください。標準化された用語の意味を複製し、潜在的に誤解を招くような方法で概念を混在させます。代わりに、何をしているものに応じて、「証明書検証」または「パス検証」を使用してください。（VS. Veriveを検証してください。）
$ certificate creation (I) The act or process by which a CA sets the values of a digital certificate's data fields and signs it. (See: issue.)
$ 証明書作成（in）CAがデジタル証明書データフィールドの値を設定してサインする行為またはプロセス。（発行を参照してください。）
$ certificate expiration (I) The event that occurs when a certificate ceases to be valid because its assigned lifetime has been exceeded. (See: certificate revocation, expire.)
$ 証明書の有効期限（i）割り当てられたライフタイムが超えているため、証明書が有効になったときに発生するイベント。（参照：証明書の失効、期限切れ）
Tutorial: The assigned lifetime of an X.509 certificate is stated in the certificate itself. (See: validity period.)
チュートリアル：X.509証明書の割り当てられた有効期間が証明書自体に記載されています。（有効期間参照）
$ certificate extension (I) See: extension.
$ 証明書拡張（i）拡張子：拡張子を参照してください。
$ certificate holder (D) Synonym for the "subject" of a digital certificate. (Compare: certificate owner, certificate user.) Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for the subject of a digital certificate; the term is potentially ambiguous. For example, the term could be misunderstood as referring to a system entity or component, such as a repository, that simply has possession of a copy of the certificate.
$ Certificate Holder（D）デジタル証明書の「件名」の同義語。（Compare：証明書の所有者、証明書ユーザー。）非推奨の定義：IDocは、この用語をデジタル証明書の件名の同義語として使用しないでください。この用語は潜在的にあいまいです。たとえば、この用語は、証明書のコピーを所有するだけで、リポジトリなどのシステムエンティティまたはコンポーネントを参照するものとして誤解された可能性があります。
$ certificate management (I) The functions that a CA may perform during the lifecycle of a digital certificate, including the following: - Acquire and verify data items to bind into the certificate. - Encode and sign the certificate. - Store the certificate in a directory or repository. - Renew, rekey, and update the certificate. - Revoke the certificate and issue a CRL. (See: archive management, certificate management, key management, security architecture, token management.)
$ 証明書管理（i）次のものを含む、デジタル証明書のライフサイクル中にCAが実行できる機能。 - 証明書にバインドするためのデータ項目を取得して検証します。 - 証明書にエンコードして署名します。 - 証明書をディレクトリまたはリポジトリに保存します。 - 証明書を更新、再生し、更新します。 - 証明書を取り消してCRLを発行します。（「アーカイブ管理、証明書管理、鍵管理、セキュリティアーキテクチャ、トークン管理」を参照してください。）
$ certificate management authority (CMA) (D) /U.S. DoD/ Used to mean either a CA or an RA. [DoD7, SP32]
$ 証明書管理局（CMA）（D）/U.S。DOD / CAまたはRAのいずれかを意味します。[DOD7、SP32]
Deprecated Term: IDOCs SHOULD NOT use this term because it is potentially ambiguous, such as in a context involving ICRLs. Instead, use CA, RA, or both, depending on what is meant.
廃止予定の用語：IDOCは、ICRLを含むコンテキストなど、潜在的にあいまいであるため、この用語を使用しないでください。代わりに、何を意味するのかによって、CA、RA、またはその両方を使用してください。
$ certificate owner (D) Synonym for the "subject" of a digital certificate. (Compare: certificate holder, certificate user.)
$ 証明書の所有者（D）デジタル証明書の「件名」の同義語。（Comperical Holder、証明書ユーザー。）
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for the subject of a digital certificate; the term is potentially ambiguous. For example, the term could refer to a system entity, such as a corporation, that has purchased a certificate to operate equipment, such as a Web server.
非推奨の定義：IDocは、この用語をデジタル証明書の件名の同義語として使用しないでください。この用語は潜在的にあいまいです。たとえば、この用語は、Webサーバーなどの機器を操作するための証明書を購入した企業などのシステムエンティティを指すことができます。
$ certificate path (D) Synonym for "certification path".
$ 証明書パス（D）「認証パス」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of "certification path", which is preferred in PKI standards (e.g., [X509, R3280]).
廃止予定語：IDocsはこの用語を使用しないでください。PKI規格（例えば、[X509、R3280]）が好ましい「認証パス」の不注意な使用を示唆しています。
$ certificate policy (I) "A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." [X509] (Compare: CPS, security policy.) Example: U.S. DoD's certificate policy [DoD7] defined four classes (i.e., assurance levels) for X.509 public-key certificates and defines the applicability of those classes. (See: class 2.)
$ Certificate Policy（i） "特定のコミュニティへの証明書の適用性および/または共通のセキュリティ要件を持つアプリケーションのクラスの適用可能性を示す名前付きの規則。[X509]（CPS、セキュリティポリシー。）例：米国のDODの証明書ポリシー[DOD7]は、X.509公開鍵証明書の4つのクラス（すなわち保証レベル）を定義し、それらのクラスの適用性を定義します。（参照：クラス2.）
Tutorial: A certificate policy can help a certificate user to decide whether a certificate should be trusted in a particular application. "For example, a particular certificate policy might indicate applicability of a type of certificate for the authentication of electronic data interchange transactions for the trading of goods within a given price range." [R3647]
チュートリアル：証明書ポリシーは、証明書ユーザーが特定のアプリケーションで証明書を信頼できるかどうかを決定するのに役立ちます。「たとえば、特定の証明書ポリシーは、特定の価格範囲内の商品取引のための電子データ交換取引の認証のための証明書の種類の適用性を示す場合があります。」[R3647]
A v3 X.509 public-key certificate may have a "certificatePolicies" extension that lists certificate policies, recognized by the issuing CA, that apply to the certificate and govern its use. Each policy is denoted by an object identifier and may optionally have certificate policy qualifiers. (See: certificate profile.)
v3 X.509公開鍵証明書には、発行されたCAによって認識された証明書ポリシーをリストし、証明書に適用され、その使用を管理する「CertificatePolicies」の拡張子があります。各ポリシーはオブジェクト識別子で表され、必要に応じて証明書ポリシーの修飾子を持つことができます。（証明書プロファイルを参照してください。）
Each SET certificate specifies at least one certificate policy, that of the SET root CA. SET uses certificate policy qualifiers to point to the actual policy statement and to add qualifying policies to the root policy. (See: SET qualifier.)
各セット証明書は少なくとも1つの証明書ポリシー、Set Root CAの証明書ポリシーを指定します。Setは証明書ポリシー修飾子を使用して実際のPolicyステートメントを指し、ルートポリシーに適格ポリシーを追加します。（：修飾子を設定してください。）
$ certificate policy qualifier (I) Information that pertains to a certificate policy and is included in a "certificatePolicies" extension in a v3 X.509 public-key certificate.
$ 証明書ポリシー修飾子（i）証明書ポリシーに関連し、v3 x.509公開鍵証明書の「CertificatePolicies」拡張子に含まれています。
$ certificate profile (I) A specification (e.g., [DoD7, R3280]) of the format and semantics of public-key certificates or attribute certificates, constructed for use in a specific application context by selecting from among options offered by a broader standard. (Compare: protection profile.)
$ 証明書プロファイル（i）より広い標準によって提供されるオプションの中から選択することによって、特定のアプリケーションコンテキストで使用するために構築された、公開鍵証明書または属性証明書のフォーマットおよびセマンティクスの指定（例えば、[DOD7、R3280]）。（比較：保護プロファイル）
$ certificate reactivation (I) The act or process by which a digital certificate, that a CA has designated for revocation but not yet listed on a CRL, is returned to the valid state.
$ 証明書の再起動（i）CAが失効のために指定されていないがまだCRLにリストされていないデジタル証明書が有効な状態に戻される、デジタル証明書（i）その動作またはプロセス。
$ certificate rekey 1. (I) The act or process by which an existing public-key certificate has its key value changed by issuing a new certificate with a different (usually new) public key. (See: certificate renewal, certificate update, rekey.)
$ 証明書再鍵1.（i）既存の公開鍵証明書に鍵の値が変更された行為またはプロセスは、異なる（通常は新しい）公開鍵で発行することによって変更されました。（証明書の更新、証明書の更新、リリーキー）を参照してください。
Tutorial: For an X.509 public-key certificate, the essence of rekey is that the subject stays the same and a new public key is bound to that subject. Other changes are made, and the old certificate is revoked, only as required by the PKI and CPS in support of the rekey. If changes go beyond that, the process is a "certificate update".
チュートリアル：X.509公開鍵証明書の場合、再スリーの本質は、被写体が同じままであり、新しい公開鍵がその主題にバインドされていることです。その他の変更が行われ、古い証明書は再生成をサポートしているPKIおよびCPSによって必要な限り、取り消されます。変更がそれ以上進むと、プロセスは「証明書の更新」です。
2. (O) /MISSI/ The act or process by which a MISSI CA creates a new X.509 public-key certificate that is identical to the old one, except the new one has (a) a new, different KEA key or (b) a new, different DSS key or (c) new, different KEA and DSS keys. The new certificate also has a different serial number and may have a different validity period. A new key creation date and maximum key lifetime period are assigned to each newly generated key. If a new KEA key is generated, that key is assigned a new KMID. The old certificate remains valid until it expires, but may not be further renewed, rekeyed, or updated.
2. （O）/ MISSI / Missi CAが古いものと同一の新しいX.509公開鍵証明書を作成する行為またはプロセスは、（a）新しい、異なるKEAキーまたは（B）を持っています。）新しい、異なるDSSキーまたは（C）新規、異なるKEAおよびDSSキー。新しい証明書は異なるシリアル番号を持ち、異なる有効期間を持つことがあります。新たな鍵作成日と最大鍵寿命期間が、新しく生成された各キーに割り当てられます。新しいKEAキーが生成された場合、そのキーに新しいKMIDが割り当てられます。古い証明書は、期限切れになるまで有効なままですが、さらに更新、再確認、または更新されていない可能性があります。
$ certificate renewal (I) The act or process by which the validity of the binding asserted by an existing public-key certificate is extended in time by issuing a new certificate. (See: certificate rekey, certificate update.)
$ 証明書更新（i）既存の公開鍵証明書によってアサートされたバインディングの妥当性が新しい証明書を発行することによって時間内に拡張される行為またはプロセス。（参照：証明書の再作成、証明書の更新。）
Tutorial: For an X.509 public-key certificate, this term means that the validity period is extended (and, of course, a new serial number is assigned) but the binding of the public key to the subject and to other data items stays the same. The other data items are changed, and the old certificate is revoked, only as required by the PKI and CPS to support the renewal. If changes go beyond that, the process is a "certificate rekey" or "certificate update".
チュートリアル：X.509公開鍵証明書の場合、この用語は、有効期間が拡張されていることを意味します（またはもちろん新しいシリアル番号が割り当てられています）が、その他のデータ項目とその他のデータ項目の維持同じ。他のデータ項目は変更され、古い証明書は、更新をサポートするためにPKIとCPSによって必要な限り取り消されます。変更がそれ以上進むと、プロセスは「証明書再聴取」または「証明書の更新」です。
$ certificate request (D) Synonym for "certification request".
$ 証明書要求（D）「認証要求」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of the term "certification request", which is preferred in PKI standards (e.g., see PKCS #10).
廃止予定語：IDocsはこの用語を使用しないでください。PKI規格（例えば、PKCS＃10を参照）が好ましい「認証要求」という用語の不注意な使用を示唆している。
$ certificate revocation (I) The event that occurs when a CA declares that a previously valid digital certificate issued by that CA has become invalid; usually stated with an effective date.
$ 証明書失効（i）CAが以前に有効なデジタル証明書がそのCAによって発行されたことを宣言したときに発生するイベントは無効になっています。通常発効日に記載されています。
Tutorial: In X.509, a revocation is announced to potential certificate users by issuing a CRL that mentions the certificate. Revocation and listing on a CRL is only necessary prior to the certificate's scheduled expiration.
チュートリアル：X.509では、証明書を説明するCRLを発行することで、潜在的な証明書ユーザーに失効が発表されます。CRL上の失効とリストは、証明書の予定された有効期限の前にのみ必要です。
$ certificate revocation list (CRL) 1. (I) A data structure that enumerates digital certificates that have been invalidated by their issuer prior to when they were scheduled to expire. (See: certificate expiration, delta CRL, X.509 certificate revocation list.)
$ 証明書失効リスト（CRL）1。（i）発行者によって無効化されたデジタル証明書を期限切れに予定されていたデータ構造を列挙するデータ構造。（証明書の有効期限、Delta CRL、X.509証明書失効リスト）
2. (O) "A signed list indicating a set of certificates that are no longer considered valid by the certificate issuer. In addition to the generic term CRL, some specific CRL types are defined for CRLs that cover particular scopes." [X509]
2. （O）「証明書発行者によって有効であると見なされなくなった1組の証明書を示す署名付きリスト。一般的な用語CRLに加えて、特定のスコープをカバーするCRLに対していくつかの特定のCRLタイプが定義されています。」[X509]
$ certificate revocation tree (N) A mechanism for distributing notices of certificate revocations; uses a tree of hash results that is signed by the tree's issuer. Offers an alternative to issuing a CRL, but is not supported in X.509. (See: certificate status responder.)
$ 証明書失効ツリー（N）証明書の失効の通知を配布するためのメカニズム。ツリーの発行者によって署名されたハッシュ結果のツリーを使用します。CRLを発行するための代替手段を提供しますが、X.509ではサポートされていません。（証明書ステータスレスポンダを参照）
$ certificate serial number 1. (I) An integer value that (a) is associated with, and may be carried in, a digital certificate; (b) is assigned to the certificate by the certificate's issuer; and (c) is unique among all the certificates produced by that issuer.
$ 証明書のシリアル番号1.（i）（a）が関連付けられている整数値、およびデジタル証明書に搭載されてもよい。（b）証明書の発行者によって証明書に割り当てられています。（c）はその発行者によって生成されたすべての証明書の中で一意である。
2. (O) "An integer value, unique within the issuing CA, [that] is unambiguously associated with a certificate issued by that CA." [X509]
2. （O） "発行されたCA内で一意である整数値は、そのCAによって発行された証明書に明確に関連付けられています。[X509]
$ certificate status authority (D) /U.S. DoD/ "A trusted entity that provides on-line verification to a Relying Party of a subject certificate's trustworthiness [should instead say 'validity'], and may also provide additional attribute information for the subject certificate." [DoD7]
$ 証明書ステータス局（D）/U.S。DOD /「対象の証明書の信頼性の信頼当事者にオンライン検証を提供する信頼できるエンティティは、代わりに「有効性」を言う必要があり、また件名証明書の追加の属性情報を提供することもできます。」[DOD7]
Deprecated Term: IDOCs SHOULD NOT use this term because it is not widely accepted; instead, use "certificate status responder" or "OCSP server", or otherwise explain what is meant.
廃止予定の用語：IDOCは、それが広く受け入れられていないため、この用語を使用しないでください。代わりに、「証明書ステータスレスポンダ」または「OCSPサーバー」を使用するか、あるいはその意味を説明するものを説明します。
$ certificate status responder (N) /FPKI/ A trusted online server that acts for a CA to provide authenticated certificate status information to certificate users [FPKI]. Offers an alternative to issuing a CR. (See: certificate revocation tree, OCSP.)
$ 証明書ステータスレスポンダ（N）/ FPKI / CAに機能する信頼できるオンラインサーバーは、認証された証明書ステータス情報を証明書ユーザーに提供する[FPKI]。CRを発行するための代替手段を提供します。（証明書失効ツリー、OCSP。）
$ certificate update (I) The act or process by which non-key data items bound in an existing public-key certificate, especially authorizations granted to the subject, are changed by issuing a new certificate. (See: certificate rekey, certificate renewal.)
$ Certificate Update（i）既存の公開鍵証明書、特に件名に付与された承認に拘束されている非鍵データ項目が新しい証明書を発行することで変更されます。（参照：証明書再生、証明書の更新。）
Usage: For an X.509 public-key certificate, the essence of this process is that fundamental changes are made in the data that is bound to the public key, such that it is necessary to revoke the old certificate. (Otherwise, the process is only a "certificate rekey" or "certificate renewal".)
使用法：X.509公開鍵証明書の場合、このプロセスの本質は、旧証明書を取り消す必要があるように、公開鍵にバインドされているデータに基本的な変更が加えられます。（それ以外の場合、プロセスは「証明書再生」または「証明書更新」です。）
$ certificate user 1. (I) A system entity that depends on the validity of information (such as another entity's public key value) provided by a digital certificate. (See: relying party. Compare: /digital certificate/ subject.)
$ Certificate User 1.（i）デジタル証明書によって提供される情報の有効性（別のエンティティの公開鍵の値など）に依存するシステムエンティティ。（rieling Party。比較：/デジタル証明書/件名を比較してください。）
Usage: The depending entity may be a human being or an organization, or a device or process controlled by a human or organization. (See: user.)
使用法：依存体企業は、人間または組織、または人間または組織によって制御される機器またはプロセスであり得る。（ユーザーを参照してください。）
2. (O) "An entity that needs to know, with certainty, the public key of another entity." [X509]
2. （o）「知る必要があるエンティティは、他のエンティティの公開鍵を持っている。」[X509]
3. (D) Synonym for "subject" of a digital certificate.
3. （d）デジタル証明書の「件名」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 3; the term could be confused with one of the other two definitions given above.
廃止予定の定義：IDocsはこの用語を定義3で使用しないでください。この用語は、上記の2つの定義のいずれかと混同することができます。
$ certificate validation 1. (I) An act or process by which a certificate user establishes that the assertions made by a digital certificate can be trusted. (See: valid certificate, validate vs. verify.)
$ 証明書の検証1.（i）証明書ユーザーがデジタル証明書によって行われたアサーションを信頼できるように確立する行為またはプロセス。（有効な証明書、VS. Veriveの検証を参照してください。）
2. (O) "The process of ensuring that a certificate was valid at a given time, including possibly the construction and processing of a certification path [R4158], and ensuring that all certificates in that path were valid (i.e. were not expired or revoked) at that given time." [X509]
2. （O）「証明書が所定の時間に有効であることを確認するプロセス[R4158]の構築と処理を含む[R4158]で、そのパスのすべての証明書が有効であることを確認している（すなわち期限切れまたは失効しなかった）。その予定時に。」[X509]
Tutorial: To validate a certificate, a certificate user checks that the certificate is properly formed and signed and is currently in force: - Checks the syntax and semantics: Parses the certificate's syntax and interprets its semantics, applying rules specified for and by its data fields, such as for critical extensions in an X.509 certificate.
チュートリアル：証明書を検証するために、証明書ユーザーが証明書が正しく形成され署名されていることを確認し、現在強制的に設定されています。 - 構文と意味論をチェックします。X.509証明書の重要な拡張機能など。
- Checks the signature: Uses the issuer's public key to verify the digital signature of the CA who issued the certificate in question. If the verifier obtains the issuer's public key from the issuer's own public-key certificate, that certificate should be validated, too. That validation may lead to yet another certificate to be validated, and so on. Thus, in general, certificate validation involves discovering and validating a certification path. - Checks currency and revocation: Verifies that the certificate is currently in force by checking that the current date and time are within the validity period (if that is specified in the certificate) and that the certificate is not listed on a CRL or otherwise announced as invalid. (The CRLs also must be checked by a similar validation process.)
- 署名を確認します。発行者の公開鍵を使用して、問題の証明書を発行したCAのデジタル署名を確認します。検証者が発行者自身の公開鍵証明書から発行者の公開鍵を取得した場合、その証明書も検証されるべきです。その検証は、さらに別の証明書を検証することにつながる可能性があります。したがって、一般に、証明書の検証は認証パスの発見と検証を含みます。 - 通貨と失効をチェックします。現在の日時が有効期間内（証明書に指定されている場合）で、証明書がCRLに表示されていないか、そのまま発表されていないことを確認して、証明書が現在強制的にあることを確認します。無効。（CRLSはまた、同様の検証プロセスによってチェックされなければなりません。）
$ certification 1. (I) /information system/ Comprehensive evaluation (usually made in support of an accreditation action) of an information system's technical security features and other safeguards to establish the extent to which the system's design and implementation meet a set of specified security requirements. [C4009, FP102, SP37] (See: accreditation. Compare: evaluation.)
$ 認証1.（I）/情報システム/包括的な評価（通常は認定措置を支援して）システムの設計と実装が一連のセキュリティ要件のセットを満たす範囲を確立するためのその他の保護措置。[C4009、FP102、SP37]（認定を参照してください。比較：評価。）
2. (I) /digital certificate/ The act or process of vouching for the truth and accuracy of the binding between data items in a certificate. (See: certify.)
2. （i）/デジタル証明書/証明書内のデータ項目間のバランスの真実と正確さのための贈収賄の行為またはプロセス。（証明書を参照してください。）
3. (I) /PKI/ The act or process of vouching for the ownership of a public key by issuing a public-key certificate that binds the key to the name of the entity that possesses the matching private key. Besides binding a key with a name, a public-key certificate may bind those items with other restrictive or explanatory data items. (See: X.509 public-key certificate.)
3. （i）/ pki /鍵を片付ける秘密鍵を有するエンティティの名前に鍵をバインドする公開鍵証明書を発行することによって、公開鍵の所有権のための告知の行為またはプロセス。キーを名前でバインドする以外に、公開鍵証明書はそれらのアイテムを他の制限的または説明データ項目でバインドすることができます。（X.509公開鍵証明書を参照してください。）
4. (O) /SET/ "The process of ascertaining that a set of requirements or criteria has been fulfilled and attesting to that fact to others, usually with some written instrument. A system that has been inspected and evaluated as fully compliant with the SET protocol by duly authorized parties and process would be said to have been certified compliant." [SET2]
4. （o）/ set / "通常、一連の要件または基準が満たされ、その事実を他の人に満たされていることを確認するプロセスは、通常、いくつかの書面による楽器を使用しています。設定されたプロトコルに完全に準拠していると評価されたシステム正式な承認締約国とプロセスによって、コンプライアンスが認定されていると言われます。」[SET2]
$ certification authority (CA) 1. (I) An entity that issues digital certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate.
$ 認証局（CA）1。（i）デジタル証明書（特にX.509証明書）および証明書内のデータ項目間のバインディングのためのvouchesを発行するエンティティ。
2. (O) "An authority trusted by one or more users to create and assign certificates. Optionally the certification authority may create the user's keys." [X509]
2. （O） "証明書を作成および割り当てるために1人以上のユーザーが信頼した権限。オプションで認証局はユーザーのキーを作成することがあります。」[X509]
Tutorial: Certificate users depend on the validity of information provided by a certificate. Thus, a CA should be someone that certificate users trust and that usually holds an official position created and granted power by a government, a corporation, or some other organization. A CA is responsible for managing the life cycle of certificates (see: certificate management) and, depending on the type of certificate and the CPS that applies, may be responsible for the lifecycle of key pairs associated with the certificates (see: key management).
チュートリアル：証明書ユーザーは証明書によって提供される情報の有効性によって異なります。したがって、CAは、証明書が信頼している人であり、通常は政府、企業、または他の組織によって創出され、権力を与えられた公式の立場を保有しているべきです。CAは、証明書のライフサイクルを管理する責任があります（証明書管理を参照）、証明書の種類と適用されるCPSに応じて、証明書に関連付けられているキーペアのライフサイクルを担当することがあります（鍵管理を参照）。。
$ certification authority workstation (CAW) (N) A computer system that enables a CA to issue digital certificates and supports other certificate management functions as required.
$ 認証局のワークステーション（CAW）（N）CAがデジタル証明書を発行することを可能にし、必要に応じて他の証明書管理機能をサポートできるようにするコンピュータシステム。
$ certification hierarchy 1. (I) A tree-structured (loop-free) topology of relationships between CAs and the entities to whom the CAs issue public-key certificates. (See: hierarchical PKI, hierarchy management.)
$ CERTICATION階層1.（i）CASとCASの発行者が公開鍵証明書を発行しているエンティティとの関係のツリー構造（ループフリー）トポロジ。（参照：階層PKI、階層管理。）
Tutorial: In this structure, one CA is the top CA, the highest level of the hierarchy. (See: root, top CA.) The top CA may issue public-key certificates to one or more additional CAs that form the second-highest level. Each of these CAs may issue certificates to more CAs at the third-highest level, and so on. The CAs at the second-lowest level issue certificates only to non-CA entities that form the lowest level (see: end entity). Thus, all certification paths begin at the top CA and descend through zero or more levels of other CAs. All certificate users base path validations on the top CA's public key.
チュートリアル：この構造では、1つのCAがトップCA、最高レベルの階層です。（参照：root、top ca.）トップCAは、2番目の最高レベルを形成する1つ以上の追加のCASへの公開鍵証明書を発行することがあります。これらのCAはそれぞれ、3番目の最高レベルでもっとCASに証明書を発行することができます。2番目に低いレベルのレベルのCASは、最低レベルを形成するCA以外のエンティティにのみ証明書を発行します（エンドエンティティを参照）。したがって、すべての認証パスはトップCAから始まり、0以上のレベルの他のCASを降ります。すべての証明書ユーザーは、Top CAの公開鍵の基本パス検証です。
2. (I) /PEM/ A certification hierarchy for PEM has three levels of CAs [R1422]: - The highest level is the "Internet Policy Registration Authority". - A CA at the second-highest level is a "policy certification authority". - A CA at the third-highest level is a "certification authority".
2. （I）/ PEM / PEM / PEMの認証階層には、3つのレベルのCAS [R1422]があります。 - 最高レベルは「インターネットポリシー登録局」です。 - 2番目に高いレベルのCAは「ポリシー認証局」です。 - 3番目に高いレベルのCAは「認証局」です。
3. (O) /MISSI/ A certification hierarchy for MISSI has three or four levels of CAs: - A CA at the highest level, the top CA, is a "policy approving authority".
3. （O）/ MISSI / MISSI用の認証階層のCAS： - 最高レベルのCA、TOP CAは「政策承認権限」です。
- A CA at the second-highest level is a "policy creation authority". - A CA at the third-highest level is a local authority called a "certification authority". - A CA at the fourth-highest (optional) level is a "subordinate certification authority".
- 2番目に高いレベルのCAは「ポリシー作成局」です。 - 3番目に高いレベルのCAは、「認証局」という地方自治体です。 - 4番目に高い（オプション）レベルのCAは「従属認証局」です。
4. (O) /SET/ A certification hierarchy for SET has three or four levels of CAs: - The highest level is a "SET root CA". - A CA at the second-highest level is a "brand certification authority". - A CA at the third-highest (optional) level is a "geopolitical certification authority". - A CA at the fourth-highest level is a "cardholder CA", a "merchant CA", or a "payment gateway CA".
4. （O）/ SET / A SETの認証階層には3つまたは4つのレベルのCAがあります。 - 最高レベルは「根本的なCA」です。 - 2番目に高いレベルのCAは「ブランド認証局」です。 - 3番目に高い（オプション）レベルのCAは「地政学的証明機関」です。 - 4番目のレベルのCAは、「カード保有者CA」、「マーチャントCA」、または「支払いゲートウェイCA」です。
$ certification path 1. (I) A linked sequence of one or more public-key certificates, or one or more public-key certificates and one attribute certificate, that enables a certificate user to verify the signature on the last certificate in the path, and thus enables the user to obtain (from that last certificate) a certified public key, or certified attributes, of the system entity that is the subject of that last certificate. (See: trust anchor, certificate validation, valid certificate.)
$ 認証パス1.（i）1つ以上の公開鍵証明書、または1つ以上の公開鍵証明書と1つ以上の公開鍵証明書と1つの属性証明書、およびパス内の最後の証明書の署名を確認することができます。したがって、ユーザーは、その最後の証明書の主題であるシステムエンティティの、認証された公開鍵、または認証属性を取得できます。（以下を参照してください.Ressut Anchor、証明書検証、有効な証明書。）
2. (O) "An ordered sequence of certificates of objects in the [X.500 Directory Information Tree] which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path." [R3647, X509]
2. （O）「パス内の初期オブジェクトの公開鍵とともに、パス内の最後のオブジェクトのそれを得るために処理することができる。""[R3647、X509]
Tutorial: The list is "linked" in the sense that the digital signature of each certificate (except possibly the first) is verified by the public key contained in the preceding certificate; i.e., the private key used to sign a certificate and the public key contained in the preceding certificate form a key pair that has previously been bound to the authority that signed.
チュートリアル：リストは、各証明書のデジタル署名（おそらく最初のものを除く）が、前の証明書に含まれている公開鍵によって検証されているという意味で「リンク」されています。すなわち、証明書に署名するために使用される秘密鍵および前述の証明書に含まれる公開鍵は、署名された権限に以前にバインドされている鍵ペアを形成する。
The path is the "list of certificates needed to [enable] a particular user to obtain the public key [or attributes] of another [user]." [X509] Here, the word "particular" points out that a certification path that can be validated by one certificate user might not be able to be validated by another. That is because either the first certificate needs to be a trusted certificate or the signature on the first certificate needs to be verifiable by a trusted key (e.g., a root key), but such trust is established only relative to a "particular" (i.e., specific) user, not absolutely for all users.
PATHは、別の[ユーザー]の公開鍵[または属性]を取得するために、特定のユーザーが特定のユーザーに必要な証明書のリストです。」[X509]ここで、「特に」という単語は、1つの証明書ユーザーによって検証可能な認証パスを別の証明書によって検証できない可能性があることを指摘しています。これは、最初の証明書のどちらかが信頼できる証明書である必要があるか、最初の証明書の署名を信頼できる鍵（例えば、ルートキー）によって検証可能である必要があるためですが、そのような信頼は「特定の」と比較してだけ確立されています（つまり、特定の）ユーザーは、すべてのユーザーのために絶対にはありません。
$ certification policy (D) Synonym for either "certificate policy" or "certification practice statement".
$ 認証ポリシー（D）「証明書ポリシー」または「認定習慣文」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for either of those terms; that would be duplicative and would mix concepts in a potentially misleading way. Instead, use either "certificate policy" or "certification practice statement", depending on what is meant.
廃止予定の用語：IDocは、この用語をそれらの条項の同義語として使用しないでください。それは複製され、潜在的に誤解を招くような方法で概念を混ぜるでしょう。代わりに、何をしているのかによって、「証明書ポリシー」または「認定練習文」を使用してください。
$ certification practice statement (CPS) (I) "A statement of the practices which a certification authority employs in issuing certificates." [DSG, R3647] (See: certificate policy.)
$ 認証慣行文（CPS）（I）「証明機関が証明書を発行する際に採用した慣行の声明」。[DSG、R3647]（証明書ポリシーを参照）
Tutorial: A CPS is a published security policy that can help a certificate user to decide whether a certificate issued by a particular CA can be trusted enough to use in a particular application. A CPS may be (a) a declaration by a CA of the details of the system and practices it uses in its certificate management operations, (b) part of a contract between the CA and an entity to whom a certificate is issued, (c) a statute or regulation applicable to the CA, or (d) a combination of these types involving multiple documents. [DSG]
チュートリアル：CPSは、証明書ユーザーが特定のCAによって発行された証明書が特定のアプリケーションで使用するのに十分に信頼できるかどうかを決定できるようにするための公開セキュリティポリシーです。CPSは、（a）システムの詳細のCAによる宣言、証明書管理業務で使用するプラクティス、（b）証明書が発行された契約の一部（C）（C）ca、または（d）複数の文書を含むこれらの型の組み合わせに適用可能な法令または規制。[DSG]
A CPS is usually more detailed and procedurally oriented than a certificate policy. A CPS applies to a particular CA or CA community, while a certificate policy applies across CAs or communities. A CA with its single CPS may support multiple certificate policies, which may be used for different application purposes or by different user communities. On the other hand, multiple CAs, each with a different CPS, may support the same certificate policy. [R3647]
CPSは通常、証明書ポリシーよりも詳細で手続き的に向けられています。CPSは特定のCAまたはCAコミュニティに適用されますが、証明書ポリシーはCASまたはコミュニティに適用されます。単一のCPを持つCAは、さまざまなアプリケーション目的に使用されてもよく、異なるユーザーコミュニティによって使用される可能性がある複数の証明書ポリシーをサポートできます。一方、複数のCAは異なるCPを持つ複数のCASが同じ証明書ポリシーをサポートする可能性があります。[R3647]
$ certification request (I) An algorithm-independent transaction format (e.g., PKCS #10, RFC 4211) that contains a DN, and a public key or, optionally, a set of attributes, collectively signed by the entity requesting certification, and sent to a CA, which transforms the request to an X.509 public-key certificate or another type of certificate.
$ 認証要求（i）DNを含むアルゴリズムに依存しないトランザクションフォーマット（例：PKCS＃10、RFC 4211）、および公開鍵、またはオプションで、属性の一組の属性は、認証を要求し、送信されて送信されます。X.509公開鍵証明書または別の種類の証明書に要求を変換するCA。
$ certify 1. (I) Issue a digital certificate and thus vouch for the truth, accuracy, and binding between data items in the certificate (e.g., "X.509 public-key certificate"), such as the identity of the certificate's subject and the ownership of a public key. (See: certification.)
$ CERTIFY 1.（i）証明書の身元など、証明書内のデータ項目（例えば、「X.509公開鍵証明書」）の間のデータ項目（例えば、「X.509公開鍵証明書」）の間のデータ項目（例えば、「X.509公開鍵証明書」）間のバウチャーを発行してください。公開鍵の所有権。（証明書を参照してください。）
Usage: To "certify a public key" means to issue a public-key certificate that vouches for the binding between the certificate's subject and the key.
使用法：「公開鍵を認証」することは、証明書の件名と鍵のバインディングのための保証を保つ公開鍵証明書を発行することを意味します。
2. (I) The act by which a CA uses measures to verify the truth, accuracy, and binding between data items in a digital certificate.
2. （i）デジタル証明書内のデータ項目間の真実、正確さ、およびバインドを検証するための対策を使用する法律。
Tutorial: A description of the measures used for verification should be included in the CA's CPS.
チュートリアル：検証に使用される対策の説明はCAのCPSに含める必要があります。
$ CFB (N) See: cipher feedback.
$ cfb（n）cipherフィードバックを参照してください。
$ chain (D) See: trust chain.
$ チェーン（D）：トラストチェーンを参照してください。
$ Challenge Handshake Authentication Protocol (CHAP) (I) A peer entity authentication method (employed by PPP and other protocols, e.g., RFC 3720) that uses a randomly generated challenge and requires a matching response that depends on a cryptographic hash of some combination of the challenge and a secret key. [R1994] (See: challenge-response, PAP.)
$ チャレンジハンドシェイク認証プロトコル（i）ランダムに生成されたチャレンジを使用し、何らかの組み合わせの暗号化ハッシュに依存する一致する応答を必要とするピアエンティティ認証方法（PPPおよび他のプロトコル、例えばRFC 3720）。チャレンジと秘密の鍵。[R1994]（参照：チャレンジレスポンス、PAP。）
$ challenge-response (I) An authentication process that verifies an identity by requiring correct authentication information to be provided in response to a challenge. In a computer system, the authentication information is usually a value that is required to be computed in response to an unpredictable challenge value, but it might be just a password.
$ チャレンジレスポンス（i）課題に応じて正しい認証情報を提供することを要求することによって身元を検証する認証プロセス。コンピュータシステムでは、認証情報は通常予測不可能なチャレンジ値に応答して計算する必要がある値であるが、それは単なるパスワードである可能性がある値である。
$ Challenge-Response Authentication Mechanism (CRAM) (I) /IMAP4/ A mechanism [R2195], intended for use with IMAP4 AUTHENTICATE, by which an IMAP4 client uses a keyed hash [R2104] to authenticate itself to an IMAP4 server. (See: POP3 APOP.)
$ IMAP4クライアントがIMAP4サーバーに認証するためにIMAP4クライアントを使用するIMAP4クライアントで使用することを目的とした、CRAM（I）/ IMAP4 / Aメカニズム[R2195]メカニズム[R2195]。（参照：POP3 APOP。）
Tutorial: The server includes a unique time stamp in its ready response to the client. The client replies with the client's name and the hash result of applying MD5 to a string formed from concatenating the time stamp with a shared secret that is known only to the client and the server.
チュートリアル：サーバーには、クライアントへの準備ができたレスポンスに一意のタイムスタンプが含まれています。クライアントは、クライアントの名前と、クライアントとサーバーのみが知られている共有秘密を持つタイムスタンプを連結された文字列に、クライアントの名前とハッシュ結果と返信します。
$ channel 1. (I) An information transfer path within a system. (See: covert channel.) 2. (O) "A subdivision of the physical medium allowing possibly shared independent uses of the medium." (RFC 3753)
$チャネル1.（i）システム内の情報転送パス。（添付のチャンネルを参照）。（O）「媒体の共有された独立使用を可能にする物理媒体の細分化」（RFC 3753）
$ channel capacity (I) The total capacity of a link to carry information; usually expressed in bits per second. (RFC 3753) (Compare: bandwidth.)
$ チャネル容量（i）情報を運ぶためのリンクの総容量。通常は毎秒ビットで表しています。（RFC 3753）（比較：帯域幅）
Tutorial: Within a given bandwidth, the theoretical maximum channel capacity is given by Shannon's Law. The actual channel capacity is determined by the bandwidth, the coding system used, and the signal-to-noise ratio.
チュートリアル：特定の帯域幅内では、理論的最大チャネル容量はシャノンの法律で与えられます。実際のチャネル容量は、帯域幅、使用される符号化システム、および信号対雑音比によって決定される。
$ CHAP (I) See: Challenge Handshake Authentication Protocol.
$ CHAP（I）参照：チャレンジハンドシェイク認証プロトコル。
$ checksum (I) A value that (a) is computed by a function that is dependent on the contents of a data object and (b) is stored or transmitted together with the object, for detecting changes in the data. (See: cyclic redundancy check, data integrity service, error detection code, hash, keyed hash, parity bit, protected checksum.)
$ チェックサム（i）データオブジェクトの内容に依存する関数によって（a）が計算される値は、データの変化を検出するために、そのオブジェクトとともに（b）を保存または送信される。（巡回冗長検査、データ整合性サービス、エラー検出コード、ハッシュ、キー付きハッシュ、パリティビット、保護チェックサム）
Tutorial: To gain confidence that a data object has not been changed, an entity that later uses the data can independently recompute the checksum value and compare the result with the value that was stored or transmitted with the object.
チュートリアル：データオブジェクトが変更されていないことを確認するために、後でデータを使用するエンティティは独立してチェックサム値を再計算し、その結果をオブジェクトと共に送信または送信した値と比較することができます。
Computer systems and networks use checksums (and other mechanisms) to detect accidental changes in data. However, active wiretapping that changes data could also change an accompanying checksum to match the changed data. Thus, some checksum functions by themselves are not good countermeasures for active attacks. To protect against active attacks, the checksum function needs to be well-chosen (see: cryptographic hash), and the checksum result needs to be cryptographically protected (see: digital signature, keyed hash).
コンピュータシステムとネットワークは、チェックサム（およびその他のメカニズム）を使用して、データの偶発的な変更を検出します。ただし、データを変更するアクティブなワイヤーキャッピングは、変更されたデータと一致するように付随するチェックサムを変更する可能性があります。したがって、自分自身によるいくつかのチェックサム関数は、能動的な攻撃に対する良好な対策ではありません。アクティブな攻撃から保護するためには、チェックサム関数をよく選択する必要があります（Cryptographic Hash）、チェックサム結果は暗号化的に保護される必要があります（デジタル署名、キー付きハッシュを参照）。
$ Chinese wall policy (I) A security policy to prevent conflict of interest caused by an entity (e.g., a consultant) interacting with competing firms. (See: Brewer-Nash model.)
$ 中国の壁政策（i）競合会社と対話する事業体（例えば、コンサルタント）によって引き起こされる興味の相反を防ぐためのセキュリティポリシー。（参照：BREWER-NASHモデル。）
Tutorial: All information is categorized into mutually exclusive conflict-of-interest classes I(1), I(2), ..., I(M), and each firm F(1), F(2), ..., F(N) belongs to exactly one class. The policy states that if a consultant has access to class I(i) information from a firm in that class, then the consultant may not access information from another firm in that same class, but may access information from another firm that is in a different class. Thus, the policy creates a barrier to communication between firms that are in the same conflict-of-interest class. Brewer and Nash modeled enforcement of this policy [BN89], including dealing with policy violations that could occur because two or more consultants work for the same firm.
チュートリアル：すべての情報は、相互に排他的な金利クラスI（1）、I（2）、...、I（M）、および各会社のF（1）、F（2）、...に分類されます。、f（n）は正確に1つのクラスに属します。このポリシーは、コンサルタントがそのクラスの会社からのClass I（i）情報にアクセスできる場合、コンサルタントはその同じクラスの別の会社からの情報にアクセスできないかもしれませんが、別の会社からの情報にアクセスすることができます。クラス。したがって、このポリシーは、同じ利益競反クラスにある企業間の通信に対する障壁を作成します。2人以上のコンサルタントが同じ会社に働くために発生する可能性がある政策違反を扱うことを含む、この政策違反を扱うことを含む、醸造者とNASHはこの政策[BN89]の執行を行いました。
$ chosen-ciphertext attack (I) A cryptanalysis technique in which the analyst tries to determine the key from knowledge of plain text that corresponds to cipher text selected (i.e., dictated) by the analyst.
$ Chipe-CipherText Attack（i）アナリストが、アナリストによって選択された暗号テキストに対応するプレーンテキストの知識から鍵を決定しようとしている暗号解析技術。
$ chosen-plaintext attack (I) A cryptanalysis technique in which the analyst tries to determine the key from knowledge of cipher text that corresponds to plain text selected (i.e., dictated) by the analyst.
$ 選択された平文攻撃（i）アナリストが選択されたプレーンテキストに対応する暗号テキシ（すなわち、決定された）に対応する（すなわち、決定された）暗号化テキストの知識（すなわち）に対応する暗号解析技術。
$ CIAC (O) See: Computer Incident Advisory Capability.
$ ciac（o）コンピュータのインシデントアドバイザリ機能を参照してください。
$ CIK (N) See: cryptographic ignition key.
$ CIK（N）参照：暗号化イグニッションキーを参照してください。
$ cipher (I) A cryptographic algorithm for encryption and decryption.
$ 暗号化（i）暗号化と復号化のための暗号化アルゴリズム
$ cipher block chaining (CBC) (N) A block cipher mode that enhances ECB mode by chaining together blocks of cipher text it produces. [FP081] (See: block cipher, [R1829], [R2405], [R2451], [SP38A].)
$ 暗号ブロック連鎖（CBC）（N）Cipher Textのブロックを連鎖させることでECBモードを強化するブロック暗号モード。[FP081]（「ブロック暗号」、[R2405]、[R2451]、[SP38A]。）
Tutorial: This mode operates by combining (exclusive OR-ing) the algorithm's ciphertext output block with the next plaintext block to form the next input block for the algorithm.
チュートリアル：このモードは、アルゴリズムの暗号文出力ブロックを次の平文ブロックで組み合わせて（排他的論理和）して、アルゴリズムの次の入力ブロックを形成します。
$ cipher feedback (CFB) (N) A block cipher mode that enhances ECB mode by chaining together the blocks of cipher text it produces and operating on plaintext segments of variable length less than or equal to the block length. [FP081] (See: block cipher, [SP38A].)
$ 暗号フィードバック（CFB）（N）暗号テキストのブロックを連鎖させることによってECBモードを強化するブロック暗号モードは、ブロック長以下の可変長の平文セグメントを生成および動作させる。[FP081]（[Chiper]を参照してください.Ciphers、[SP38A]）
Tutorial: This mode operates by using the previously generated ciphertext segment as the algorithm's input (i.e., by "feeding back" the cipher text) to generate an output block, and then combining (exclusive OR-ing) that output block with the next plaintext segment (block length or less) to form the next ciphertext segment.
チュートリアル：このモードは、アルゴリズムの入力として（すなわち、「暗号化テキスト」を送り返して出力ブロックを生成するために、次の平文で出力ブロックを組み合わせることで、以前に生成された暗号文セグメントを使用することによって動作します。次の暗号文セグメントを形成するためのセグメント（ブロック長以下）。
$ cipher text 1. (I) /noun/ Data that has been transformed by encryption so that its semantic information content (i.e., its meaning) is no longer intelligible or directly available. (See: ciphertext. Compare: clear text, plain text.)
$ 暗号化テキスト1.（i）/名詞/暗号化によって変換されたデータ（すなわち、その意味）がもはやわかりやすいか直接利用可能ではない。（CipherTextを参照してください。比較：テキストをクリア、プレーンテキスト）。
2. (O) "Data produced through the use of encipherment. The semantic content of the resulting data is not available." [I7498-2]
2. （O） "暗号化を通して生成されたデータ。結果のデータの意味内容は利用できません。」[I7498-2]
$ ciphertext 1. (O) /noun/ Synonym for "cipher text" [I7498-2].
$ 暗号文1.（O）/名詞/「暗号テキスト」の同義語[I7498-2]。
2. (I) /adjective/ Referring to cipher text. Usage: Commonly used instead of "cipher-text". (Compare: cleartext, plaintext.)
2. （i）/形容詞/暗号テキストの参照。使用法：「暗号テキスト」の代わりに一般的に使用されています。（比較：平文、平文）
$ ciphertext auto-key (CTAK) (D) "Cryptographic logic that uses previous cipher text to generate a key stream." [C4009, A1523] (See: KAK.)
$ CipherTextオートキー（CTAK）（D）「前の暗号テキストを使用してキーストリームを生成する暗号化ロジック」。[C4009、A1523]（カクスを参照）
Deprecated Term: IDOCs SHOULD NOT use this term; it is neither well-known nor precisely defined. Instead, use terms associated with modes that are defined in standards, such as CBC, CFB, and OFB.
廃止予定語：IDocsはこの用語を使用しないでください。それはよく知られていないことも正確に定義されていません。代わりに、CBC、CFB、OFBなどの標準で定義されているモードに関連付けられています。
$ ciphertext-only attack (I) A cryptanalysis technique in which the analyst tries to determine the key solely from knowledge of intercepted cipher text (although the analyst may also know other clues, such as the cryptographic algorithm, the language in which the plain text was written, the subject matter of the plain text, and some probable plaintext words.)
$ 暗号文のみの攻撃（i）アナリストが傍受された暗号テキストの知識のみから鍵を決定しようとする暗号解析技術（アナリストは、暗号化アルゴリズムなどの他の手がかり、無地のテキストがある言語でも知ることができる。書かれた、プレーンテキストの主題、そしていくつかの可能性のある平文の言葉。
$ ciphony (O) The process of encrypting audio information.
$ Ciphony（O）音声情報の暗号化のプロセス。
$ CIPSO (I) See: Common IP Security Option.
$ CIPSO（I）「共通IPセキュリティ」オプションを参照してください。
$ CKL (I) See: compromised key list.
$ ckl（i）妥協したキーリストを参照してください。
$ Clark-Wilson model (N) A security model [Clark] to maintain data integrity in the commercial world. (Compare: Bell-LaPadula model.)
$ Clark-Wilsonモデル（n）商業界でのデータの整合性を維持するためのセキュリティモデル[クラーク]。（比較：ベルララドゥラモデル）
$ class 2, 3, 4, 5 (O) /U.S. DoD/ Assurance levels for PKIs, and for X.509 public-key certificates issued by a PKI. [DoD7] (See: "first law" under "Courtney's laws".) - "Class 2": Intended for applications handling unclassified, low-value data in minimally or moderately protected environments. - "Class 3": Intended for applications handling unclassified, medium-value data in moderately protected environments, or handling unclassified or high-value data in highly protected environments, and for discretionary access control of classified data in highly protected environments. - "Class 4": Intended for applications handling unclassified, high-value data in minimally protected environments. - "Class 5": Intended for applications handling classified data in minimally protected environments, and for authentication of material that would affect the security of classified systems.
$ クラス2,3,4,5（O）/U。PKIのDOD /保証レベル、およびPKIによって発行されたX.509公開鍵証明書。[DOD7]（「Courtney's Laws」の下の「最初の法律」。 - 「クラス3」：適切な保護された環境での未分類、中価値データの処理、または高度に保護された環境での未分類または高価値のデータの処理、および高度に保護された環境での分類されたデータの任意アクセス制御のためのアプリケーションを対象としています。 - "クラス4"：最小限の保護された環境で、未分類の高価値のデータを処理するアプリケーションを対象としています。 - 「クラス5」：最小限の保護された環境での分類されたデータを処理し、分類されたシステムのセキュリティに影響を与える可能性のある材料の認証を目的としています。
The environments are defined as follows:
- "Highly protected environment": Networks that are protected
either with encryption devices approved by NSA for protection
of classified data or via physical isolation, and that are
certified for processing system-high classified data, where
exposure of unencrypted data is limited to U.S. citizens
holding appropriate security clearances.
- "Moderately protected environment":
-- Physically isolated unclassified, unencrypted networks in
which access is restricted based on legitimate need.
-- Networks protected by NSA-approved, type 1 encryption,
accessible by U.S.-authorized foreign nationals.
- "Minimally protected environments": Unencrypted networks
connected to either the Internet or NIPRNET, either directly or
via a firewall.
$ Class A1, B3, B2, B1, C2, or C1 computer system (O) /TCSEC/ See: Tutorial under "Trusted Computer System Evaluation Criteria".
$ クラスA1、B3、B2、B1、C2、またはC1コンピュータシステム（O）/ TCSEC / SEE：「信頼できるコンピュータシステム評価基準」の下のチュートリアル。
$ classification 1. (I) A grouping of classified information to which a hierarchical, restrictive security label is applied to increase protection of the data from unauthorized disclosure. (See: aggregation, classified, data confidentiality service. Compare: category, compartment.)
$ （i）不正開示からのデータの保護を増やすために、階層的な制限的なセキュリティラベルが適用される分類された情報のグループ化。（集約、分類されたデータ機密保持サービス。比較：カテゴリ、コンパートメント。）
2. (I) An authorized process by which information is determined to be classified and assigned to a security level. (Compare: declassification.) Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
（i）情報が分類され、セキュリティレベルに割り当てられていると判断される許可されたプロセス。（比較してください。）使用法：通常、データの機密性を伴うと理解されていましたが、データも他の方法で敏感である場合はこの明確にする必要があり、他の感度の概念に他の用語を使用する必要があります。（機密情報、データの整合性を参照してください。）
$ classification label (I) A security label that tells the degree of harm that will result from unauthorized disclosure of the labeled data, and may also tell what countermeasures are required to be applied to protect the data from unauthorized disclosure. Example: IPSO. (See: classified, data confidentiality service. Compare: integrity label.)
$ 分類ラベル（i）ラベル付きデータの不正開示から生じる害の程度を伝えるセキュリティラベルであり、不正な開示からデータを保護するためにどの対策が適用される必要があるかを知ることがあります。例：IPSO。（：分類されたデータ機密性サービス。比較：整合性ラベル。）
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
使用法：通常、データの機密性を伴うと理解されていましたが、IDocはデータも他の方法で敏感であり、他の感度の概念に他の用語を使用する必要があります。（機密情報、データの整合性を参照してください。）
$ classification level (I) A hierarchical level of protection (against unauthorized disclosure) that is required to be applied to certain classified data. (See: classified. Compare: security level.)
$ 分類レベル（i）特定の分類されたデータに適用する必要がある（不正な開示に対する）階層的な保護レベル（不正な開示に対する）。（分類された。比較：セキュリティレベルを比較してください。）
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
使用法：通常、データの機密性を伴うと理解されていましたが、IDocはデータも他の方法で敏感であり、他の感度の概念に他の用語を使用する必要があります。（機密情報、データの整合性を参照してください。）
$ classified 1. (I) Refers to information (stored or conveyed, in any form) that is formally required by a security policy to receive data confidentiality service and to be marked with a security label (which, in some cases, might be implicit) to indicate its protected status. (See: classify, collateral information, SAP, security level. Compare: unclassified.)
$ （i）データ機密性サービスを受信し、セキュリティラベルでマークされているセキュリティポリシーによって正式に必要とされる情報（i）は、セキュリティポリシーによって正式に必要とされ、セキュリティラベルでマークされる情報（任意の形式で保存または伝達されます）を指します（保護されたステータスを示すために。（参照：分類、担保情報、SAP、セキュリティレベル。比較：未分類）
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
使用法：通常、データの機密性を伴うと理解されていましたが、IDocはデータも他の方法で敏感であり、他の感度の概念に他の用語を使用する必要があります。（機密情報、データの整合性を参照してください。）
Mainly used by national governments, especially by the military, but the underlying concept also applies outside of governments.
主に国民政府、特に軍によって使用されていますが、基礎となる概念は政府の外でも当てはまります。
2. (O) /U.S. Government/ "Information that has been determined pursuant to Executive Order 12958 or any predecessor Order, or by the Atomic Energy Act of 1954, as amended, to require protection against unauthorized disclosure and is marked to indicate its classified status." [C4009]
（O）/U.S。政府/「執行命令12958または前任者の順序または1954年のアトミックエネルギー行為により決定された情報は、不正な開示に対する保護を必要とし、その分類された地位を示すためにマークされている。[C4009]
$ classify (I) To officially designate an information item or type of information as being classified and assigned to a specific security level. (See: classified, declassify, security level.)
$ Classify（i）には、クラシファイドや情報の種類を正式に指定し、特定のセキュリティレベルに割り当てられています。（分類された、分類、セキュリティレベル、セキュリティレベルを参照）
$ clean system (I) A computer system in which the operating system and application system software and files have been freshly installed from trusted software distribution media. (Compare: secure state.)
$ クリーンシステム（i）オペレーティングシステムとアプリケーションシステムソフトウェアとファイルが信頼できるソフトウェア配信メディアから新たにインストールされているコンピュータシステム。（比較：安全状態。）
$ clear (D) /verb/ Synonym for "erase". [C4009]
$ クリア（d）/動詞/同義語 "消去"。[C4009]
Deprecated Definition: IDOCs SHOULD NOT use the term with this definition; that could be confused with "clear text" in which information is directly recoverable.
廃止予定の定義：IDocsはこの定義で用語を使用しないでください。それは情報が直接回復可能な「クリアテキスト」と混同することができます。
$ clear text 1. (I) /noun/ Data in which the semantic information content (i.e., the meaning) is intelligible or is directly available, i.e., not encrypted. (See: cleartext, in the clear. Compare: cipher text, plain text.)
$ テキストをクリアする（i）/名詞/意味情報の内容（つまり、意味）が分かりやすい、または直接利用可能な、すなわち暗号化されていない。（以下を参照してください。クリアで。比較：暗号テキスト、プレーンテキスト）。
2. (O) /noun/ "Intelligible data, the semantic content of which is available." [I7498-2]
2. （O）/名詞/「理解できるデータ、その意味の意味は利用可能です」[I7498-2]
3. (D) /noun/ Synonym for "plain text".
3. （d）/名詞/「プレーンテキスト」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "plain text", because the plain text that is input to an encryption operation may itself be cipher text that was output from a previous encryption operation. (See: superencryption.)
廃止予定の定義：IDocは、暗号化操作に入力されるプレーンテキストが以前の暗号化操作から出力された暗号テキストである可能性があるため、IDOCは「プレーンテキスト」の同義語として使用しないでください。（SuperEncryptionを参照してください。）
$ clearance See: security clearance.
$ クリアランス参照：セキュリティクリアランス。
$ clearance level (I) The security level of information to which a security clearance authorizes a person to have access.
$ クリアランスレベル（i）セキュリティクリアランスがアクセス権を持つことを承認する情報のセキュリティレベル。
$ cleartext 1. (O) /noun/ Synonym for "clear text" [I7498-2].
$ クリアテキスト1.（O）/名詞/「クリアテキスト」の同義語[I7498-2]。
2. (I) /adjective/ Referring to clear text. Usage: Commonly used instead of "clear-text". (Compare: ciphertext, plaintext.) 3. (D) /adjective/ Synonym for "plaintext".
2.（i）/形容詞/クリアテキストの参照。使用法：「クリアテキスト」の代わりに一般的に使用されています。（ChiperText、Plaintext。）3。（d）/形容詞/「平文」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "plaintext", because the plaintext data that is input to an encryption operation may itself be ciphertext data that was output from a previous encryption operation. (See: superencryption.)
非推奨の定義：暗号化操作に入力される平文データが以前の暗号化操作から出力された暗号文データであるかもしれないので、IDOCは「平文文」の同義語として使用しないでください。（SuperEncryptionを参照してください。）
$ CLEF (N) See: commercially licensed evaluation facility.
$ CLEF（N）：市販の評価施設。
$ client (I) A system entity that requests and uses a service provided by another system entity, called a "server". (See: server.)
$ クライアント（i）「サーバー」と呼ばれる別のシステムエンティティによって提供されるサービスを要求して使用するシステムエンティティ。（参照：サーバー参照）
Tutorial: Usually, it is understood that the client and server are automated components of the system, and the client makes the request on behalf of a human user. In some cases, the server may itself be a client of some other server.
チュートリアル：通常、クライアントとサーバーはシステムの自動化されたコンポーネントであり、クライアントは人間のユーザーに代わって要求を行うことがわかります。場合によっては、サーバー自体が他のサーバーのクライアントである可能性があります。
$ client-server system (I) A distributed system in which one or more entities, called clients, request a specific service from one or more other entities, called servers, that provide the service to the clients.
$ クライアント - サーバシステム（i）クライアントと呼ばれる1つ以上のエンティティが、サービスをクライアントに提供するサーバと呼ばれる1つまたは複数の他のエンティティから特定のサービスを要求する分散システム。
Example: The Word Wide Web, in which component servers provide information that is requested by component clients called "browsers".
例：コンポーネントサーバーは、「ブラウザ」というコンポーネントクライアントから要求されている情報を提供するワードWebワイドWeb。
$ CLIPPER (N) An integrated microcircuit (in MYK-7x series manufactured by Mykotronx, Inc.) that implements SKIPJACK, has a non-deterministic random number generator, and supports key escrow. (See: Escrowed Encryption Standard. Compare: CLIPPER.)
$ Clipper（N）SkipJackを実装する統合されたマイクロ回路（MyKotronx、Inc。によって製造されたMYK-7Xシリーズ）は、決定的な乱数発生器を持ち、キーエスクローをサポートしています。（ESCLOWED暗号化標準を参照してください。比較：クリッパー。）
Tutorial: The chip was mainly intended for protecting telecommunications over the public switched network. The key escrow scheme for the chip involves a SKIPJACK key that is common to all chips and that protects the unique serial number of the chip, and a second SKIPJACK key unique to the chip that protects all data encrypted by the chip. The second key is escrowed as split key components held by NIST and the U.S. Treasury Department.
チュートリアル：チップは主に公衆交換ネットワーク上の電気通信を保護するためのものです。チップのキーエスクロー方式は、すべてのチップに共通のスキップキーを含み、チップの固有のシリアル番号を保護し、チップによって暗号化されたすべてのデータを保護するチップに固有の2番目のスキップアカックキーを含みます。2番目のキーは、NISTと米国財務部門が保有する分割キーコンポーネントとして保留されています。
$ closed security environment (O) /U.S. DoD/ A system environment that meets both of the following conditions: (a) Application developers (including maintainers) have sufficient clearances and authorizations to provide an acceptable presumption that they have not introduced malicious logic. (b) Configuration control provides sufficient assurance that system applications and the equipment they run on are protected against the introduction of malicious logic prior to and during the operation of applications. [NCS04] (See: "first law" under "Courtney's laws". Compare: open security environment.)
$閉じたセキュリティ環境（O）/U.S。DOD /以下の両方の条件を満たすシステム環境：（a）アプリケーション開発者（メンテナを含む）は、悪意のあるロジックが導入されていないと予測可能な推定を提供するのに十分なクリアランスと承認を得ています。（b）構成制御は、システムアプリケーションと実行されている機器との十分な保証を提供し、アプリケーションの動作の前およびその間に悪質なロジックの導入に対して保護されています。[NCS04]（「Courtney's Laws」の下の「最初の法律」。比較：オープンセキュリティ環境。）
$ CMA (D) See: certificate management authority.
$ CMA（D）証明書管理権限を参照してください。
$ CMAC (N) A message authentication code [SP38B] that is based on a symmetric block cipher. (See: block cipher.)
$ CMAC（N）対称ブロック暗号に基づくメッセージ認証コード[SP38B]。（以下を参照してください。
Derivation: Cipher-based MAC. (Compare: HMAC.)
派生：暗号ベースのMAC。（比較：HMAC。）
Tutorial: Because CMAC is based on approved, symmetric-key block ciphers, such as AES, CMAC can be considered a mode of operation for those block ciphers. (See: mode of operation.)
チュートリアル：CMACはAESなどの承認済みの対称キーブロック暗号に基づいているため、CMACはそれらのブロック暗号の動作モードと見なすことができます。（：操作モード。）
$ CMCS (O) See: COMSEC Material Control System.
$ CMCS（O）COMSEC資料制御システムを参照してください。
$ CMM (N) See: Capability Maturity Model.
$ CMM（N）能力成熟度モデルを参照してください。
$ CMS (I) See: Cryptographic Message Syntax.
$ CMS（i）暗号化メッセージ構文を参照してください。
$ code 1. (I) A system of symbols used to represent information, which might originally have some other representation. Examples: ASCII, BER, country code, Morse code. (See: encode, object code, source code.)
$ コード1.（i）情報を表すために使用されるシンボルのシステムは、もともと他の表現を持つ可能性がある。例：ASCII、BER、国コード、モールスコード。（以下を参照してください。エンコード、オブジェクトコード、ソースコード。）
Deprecated Abbreviation: To avoid confusion with definition 1, IDOCs SHOULD NOT use "code" as an abbreviation of "country code", "cyclic redundancy code", "Data Authentication Code", "error detection code", or "Message Authentication Code". To avoid misunderstanding, use the fully qualified term in these other cases, at least at the point of first usage.
非推奨の省略形：定義1との混乱を避けるために、IDocは「国コード」、「巡回冗長コード」、「データ認証コード」、「エラー検出コード」、「メッセージ認証コード」の略語として「コード」を使用しないでください。。誤解を避けるために、少なくとも最初の使用状況で、これらの他の場合に完全に適格な用語を使用してください。
2. (I) /cryptography/ An encryption algorithm based on substitution; i.e., a system for providing data confidentiality by using arbitrary groups (called "code groups") of letters, numbers, or symbols to represent units of plain text of varying length. (See: codebook, cryptography.) Deprecated Usage: To avoid confusion with definition 1, IDOCs SHOULD NOT use "code" as a synonym for any of the following terms: (a) "cipher", "hash", or other words that mean "a cryptographic algorithm"; (b) "cipher text"; or (c) "encrypt", "hash", or other words that refer to applying a cryptographic algorithm.
2.（i）/暗号化/代替に基づく暗号化アルゴリズムすなわち、さまざまな長さの平文の単位を表すために、文字、数字、またはシンボルの任意のグループ（「コードグループ」という）を使用することによってデータ機密性を提供するためのシステム。廃止予定の使用法：定義1との混乱を避けるために、IDocは以下の条件のいずれかの同義語として「コード」を使用しないでください。（a）「暗号」、「ハッシュ」、またはその他の単語「暗号化アルゴリズム」を意味する。（b）「暗号テキスト」;または（c）暗号化アルゴリズムの適用を指す他の単語を「暗号化」、「ハッシュ」、またはその他の単語。
3. (I) An algorithm based on substitution, but used to shorten messages rather than to conceal their content.
3. （i）代入に基づくアルゴリズムは、それらの内容を隠すのではなくメッセージを短くするために使用される。
4. (I) /computer programming/ To write computer software. (See: object code, source code.)
4. （i）/コンピュータプログラミング/コンピュータソフトウェアを書く。（：オブジェクトコード、ソースコード。）
Deprecated Abbreviation: To avoid confusion with definition 1, IDOCs SHOULD NOT use "code" as an abbreviation of "object code" or "source code". To avoid misunderstanding, use the fully qualified term in these other cases, at least at the point of first usage.
廃止予定の省略形：定義1との混乱を避けるために、IDocは「オブジェクトコード」または「ソースコード」の略語として「コード」を使用しないでください。誤解を避けるために、少なくとも最初の使用状況で、これらの他の場合に完全に適格な用語を使用してください。
$ code book 1. (I) Document containing a systematically arranged list of plaintext units and their ciphertext equivalents. [C4009]
$ コードブック1.（i）平文ユニットの体系的に配置されたリストとその暗号文の同等のリストを含む文書。[C4009]
2. (I) An encryption algorithm that uses a word substitution technique. [C4009] (See: code, ECB.)
2. （i）単語置換技術を用いた暗号化アルゴリズム。[C4009]（「コード、ECB」を参照）
$ code signing (I) A security mechanism that uses a digital signature to provide data integrity and data origin authentication for software that is being distributed for use. (See: mobile code, trusted distribution.)
$ コード署名（i）デジタル署名を使用して、配布されているソフトウェアのデータの整合性とデータの原点認証を提供するセキュリティメカニズム。（携帯コード、信頼できる配布を参照してください。）
Tutorial: In some cases, the signature on a software module may imply some assertion that the signer makes about the software. For example, a signature may imply that the software has been designed, developed, or tested according to some criterion.
チュートリアル：場合によっては、ソフトウェアモジュール上のシグネチャは、署名者がソフトウェアを作成するアサーションを意味します。たとえば、シグニチャは、ソフトウェアがいくつかの基準に従って設計、開発、またはテストされていることを意味します。
$ code word (O) /U.S. Government/ A single word that is used as a security label (usually applied to classified information) but which itself has a classified meaning. (See: classified, /U.S. Government/ security label.)
$ コードワード（O）/U.S。政府/セキュリティラベルとして使用される単語（通常は分類された情報に適用されます）が分類された意味があります。（：分類された、/u.s.政府/セキュリティラベル。）
$ COI (I) See: community of interest.
$ COI（I）は興味のあるコミュニティを参照してください。
$ cold start (N) /cryptographic module/ A procedure for initially keying cryptographic equipment. [C4009]
$ コールドスタート（N）/暗号化モジュール/最初にキーイング化するための手順。[C4009]
$ collateral information (O) /U.S. Government/ Information that is classified but is not required to be protected by an SAP. (See: /U.S. Government/ classified.)
$ 担保情報（on）/u.s。分類されているがSAPによって保護される必要はない政府/情報。（：/政府/分類されている。）
$ color change (I) In a system being operated in periods-processing mode, the act of purging all information from one processing period and then changing over to the next processing period. (See: BLACK, RED.)
$ 時期処理モードで動作しているシステムでは、1つの処理期間からすべての情報を消去し、次に次の処理期間に変更する行為を行う。（参照：黒、赤）
$ Commercial COMSEC Evaluation Program (CCEP) (O) "Relationship between NSA and industry in which NSA provides the COMSEC expertise (i.e., standards, algorithms, evaluations, and guidance) and industry provides design, development, and production capabilities to produce a type 1 or type 2 product." [C4009]
$ NSAがCOMSECの専門知識（すなわち、標準、アルゴリズム、評価、およびガイダンス）を提供するNSAと産業の間の商業COMSEC評価プログラム（O））と業界は、タイプ1を作成するための設計、開発、および生産能力を提供します。または2つの製品のタイプ。」[C4009]
$ commercially licensed evaluation facility (CLEF) (N) An organization that has official approval to evaluate the security of products and systems under the Common Criteria, ITSEC, or some other standard. (Compare: KLIF.)
$ 市販の評価施設（CLEF）（N）一般的な基準、ITSEC、またはその他の規格の下で製品やシステムのセキュリティを評価するための公式の承認を得ている組織。（比較：KLIF）
$ Committee on National Security Systems (CNSS) (O) /U.S. Government/ A Government, interagency, standing committee of the President's Critical Infrastructure Protection Board. The CNSS is chaired by the Secretary of Defense and provides a forum for the discussion of policy issues, sets national policy, and promulgates direction, operational procedures, and guidance for the security of national security systems. The Secretary of Defense and the Director of Central Intelligence are responsible for developing and overseeing the implementation of Government-wide policies, principles, standards, and guidelines for the security of systems that handle national security information.
$ 国家セキュリティシステム（CNSS）（O）/U.Sの委員会。政府/政府政府、企業の批判的インフラ保護委員会の常連委員会。CNSSは国防長官によって議長を務め、政策問題についての議論、国家政策を設定し、国家のセキュリティシステムのセキュリティのための指針を制定するためのフォーラムを提供しています。国防長官と中央知性のディレクターは、国内のセキュリティ情報を処理するシステムのセキュリティのための政府全体の政策、原則、標準、およびガイドラインの実施と監督を担当しています。
$ Common Criteria for Information Technology Security (N) A standard for evaluating information technology (IT) products and systems. It states requirements for security functions and for assurance measures. [CCIB] (See: CLEF, EAL, packages, protection profile, security target, TOE. Compare: CMM.)
$ 情報技術セキュリティ（N）情報技術（IT）製品およびシステムを評価するための規格。セキュリティ機能と保証対策の要件を述べています。[CCIB]（クレフ、EAL、パッケージ、保護プロファイル、セキュリティターゲット、つま先。比較：CMM。）
Tutorial: Canada, France, Germany, the Netherlands, the United Kingdom, and the United States (NIST and NSA) began developing this standard in 1993, based on the European ITSEC, the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), and the U.S. "Federal Criteria for Information Technology Security" and its precursor, the TCSEC. Work was done in cooperation with ISO/IEC Joint Technical Committee 1 (Information Technology), Subcommittee 27 (Security Techniques), Working Group 3 (Security Criteria). Version 2.0 of the Criteria has been issued as ISO's International Standard 15408. The U.S. Government intends this standard to supersede both the TCSEC and FIPS PUB 140. (See: NIAP.)
チュートリアル：カナダ、フランス、ドイツ、オランダ、イギリス、およびアメリカ（NSTとNSA）は、1993年にこの基準を開発し始めました。米国の「情報技術セキュリティのための連邦基準」とその前駆体、TCSEC。ISO / IEC共同技術委員会1（Information Technology）、小委員会27（セキュリティ技術）、作業グループ3（セキュリティ基準）と協力して作業が行われました。基準のバージョン2.0は、ISOの国際標準15408として発行されています。米国政府は、TCSECとFIPS PUB 140の両方を提供するようにこの規格を取り組んでいます。（NIAPを参照）。
The standard addresses data confidentiality, data integrity, and availability and may apply to other aspects of security. It focuses on threats to information arising from human activities, malicious or otherwise, but may apply to non-human threats. It applies to security measures implemented in hardware, firmware, or software. It does not apply to (a) administrative security not related directly to technical security, (b) technical physical aspects of security such as electromagnetic emanation control, (c) evaluation methodology or administrative and legal framework under which the criteria may be applied, (d) procedures for use of evaluation results, or (e) assessment of inherent qualities of cryptographic algorithms.
標準は、データの機密性、データの整合性、および可用性をアドレス指定し、セキュリティの他の側面に適用される場合があります。それは人間の活動、悪意のある、またはそうでなければ、人間の非脅威に適用されるかもしれない情報への脅威に焦点を当てています。ハードウェア、ファームウェア、またはソフトウェアで実装されているセキュリティ対策に適用されます。（a）管理セキュリティは直接技術的なセキュリティに関連しない、（b）電磁放置制御などのセキュリティの技術的な物理的側面、（C）基準が適用される可能性がある管理方法または管理および法的枠組みの技術的な態様です。d）評価結果を使用する手順、または（e）暗号化アルゴリズムの固有の品質の評価。
Part 1, Introduction and General Model, defines general concepts and principles of IT security evaluation; presents a general model of evaluation; and defines constructs for expressing IT security objectives, for selecting and defining IT security requirements, and for writing high-level specifications for products and systems.
第1部、紹介および一般モデルは、一般的な概念とITセキュリティ評価の原則を定義しています。評価の一般モデルを提示します。そして、ITセキュリティの要件を選択して定義するための、そして製品やシステムのための高レベル仕様書を作成するための、ITセキュリティ目標を表現するための構成要素を定義します。
Part 2, Security Functional Requirements, contains a catalog of well-defined and well-understood functional requirement statements that are intended to be used as a standard way of expressing the security requirements for IT products and systems.
第2部、セキュリティ機能要件には、IT製品およびシステムのセキュリティ要件を表現する標準的な方法として使用されることを意図した明確かつ適切な機能要件ステートメントのカタログが含まれています。
Part 3, Security Assurance Requirements, contains a catalog of assurance components for use as a standard way of expressing such requirements for IT products and systems, and defines evaluation criteria for protection profiles and security targets.
第3部、セキュリティ保証要件には、IT製品やシステムの要件を表現する標準的な方法として使用するための保証コンポーネントのカタログが含まれており、保護プロファイルとセキュリティターゲットの評価基準を定義しています。
$ Common IP Security Option (CIPSO) (I) See: secondary definition under "IPSO".
$ 共通IPセキュリティオプション（CIPSO）（i）「IPSO」の下の2次定義。
$ common name (N) A character string that (a) may be a part of the X.500 DN of a Directory object ("commonName" attribute), (b) is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization), and (c) conforms to the naming conventions of the country or culture with which it is associated. [X520] (See: "subject" and "issuer" under "X.509 public-key certificate".) Examples: "Dr. Albert Einstein", "The United Nations", and "12-th Floor Laser Printer".
$共通名（n）（a）がディレクトリオブジェクトのX.500 dnの一部である可能性がある文字列（ "commonname"属性）、（b）はオブジェクトが一般的なものである（おそらくあいまいな）名です。いくつかの限られた範囲（組織など）で知られており、（c）はそれが関連する国または文化の命名規則に準拠しています。[X520]（X.509公開鍵証明書 "の下にある「件名」と「発行者」を参照してください。）例：「Albert Einstein博士」、「国連」、「12階のレーザープリンター」。
$ communications cover (N) "Concealing or altering of characteristic communications patterns to hide information that could be of value to an adversary." [C4009] (See: operations security, traffic-flow confidentiality, TRANSEC.)
$ コミュニケーションカバー（n） "敵対者に価値がある可能性がある情報を隠すための特性通信パターンの隠蔽または変更。」[C4009]（「オペレーションセキュリティ、トラフィックフロー機密性、トランコン」を参照）
$ communication security (COMSEC) (I) Measures that implement and assure security services in a communication system, particularly those that provide data confidentiality and data integrity and that authenticate communicating entities.
$ 通信セキュリティ（COMSEC）（i）通信システム、特にデータの機密性とデータの整合性を提供し、通信エンティティを認証するものでセキュリティサービスを実装し保証する測定値。
Usage: COMSEC is usually understood to include (a) cryptography and its related algorithms and key management methods and processes, devices that implement those algorithms and processes, and the lifecycle management of the devices and keying material. Also, COMSEC is sometimes more broadly understood as further including (b) traffic-flow confidentiality, (c) TRANSEC, and (d) steganography [Kahn]. (See: cryptology, signal security.)
使用法：COMSECは通常、（a）暗号化およびその関連するアルゴリズムおよび鍵管理方法およびプロセス、それらのアルゴリズムおよびプロセスを実装するデバイス、およびデバイスおよびキーイング材料のライフサイクル管理を含むと理解されています。また、COMSECは、（B）トラフィックフロー機密性、（C）TranseC、（D）ステガノグラフィ[KAHN]を含むことがさらに広く理解されることがあります。（参照：暗号化、信号のセキュリティ。）
$ community of interest (COI) 1. (I) A set of entities that operate under a common security policy. (Compare: domain.)
$ 興味のあるコミュニティ（COI）1.（i）一般的なセキュリティポリシーで動作する一連のエンティティ。（比較：ドメイン。）
2. (I) A set of entities that exchange information collaboratively for some purpose.
2. （i）何らかの目的と共同で情報を交換する一連のエンティティ。
$ community risk (N) Probability that a particular vulnerability will be exploited within an interacting population and adversely affect some members of that population. [C4009] (See: Morris worm, risk.)
$ コミュニティリスク（n）特定の脆弱性が相互作用の人口内で悪用され、その人口の一部のメンバーに悪影響を及ぼす可能性があります。[C4009]（Morris Worm、リスクを参照）
$ community string (I) A community name in the form of an octet string that serves as a cleartext password in SNMP version 1 (RFC 1157) and version 2 (RFC 1901). (See: password, Simple Network Management Protocol.)
$ Community String（i）SNMPバージョン1（RFC 1157）およびバージョン2（RFC 1901）のクリアテキストパスワードとして機能するオクテット文字列の形式のコミュニティ名。（「パスワード、単純なネットワーク管理プロトコル」を参照）
Tutorial: The SNMPv1 and SNMPv2 protocols have been declared "historic" and have been replaced by the more secure SNMPv3 standard (RFCs 3410-3418), which does not use cleartext passwords.
チュートリアル：SNMPv1とSNMPv2プロトコルは "historic"宣言されており、ClearTextパスワードを使用しないより安全なSNMPv3規格（RFCS 3410-3418）に置き換えられました。
$ compartment 1. (I) A grouping of sensitive information items that require special access controls beyond those normally provided for the basic classification level of the information. (See: compartmented security mode. Compare: category, classification.)
$ コンパートメント1.（i）情報の基本的な分類レベルに対して通常提供されたものを超えて特別なアクセス制御を必要とする機密情報のグループ化。（コンパートメントセキュリティモード。比較：カテゴリ、分類。）
Usage: The term is usually understood to include the special handling procedures to be used for the information.
使用法：この用語は通常、情報に使用される特別な処理手順を含むと理解されます。
2. (I) Synonym for "category".
2. （i）「カテゴリ」の同義語。
Deprecated Usage: This Glossary defines "category" with a slightly narrower meaning than "compartment". That is, a security label is assigned to a category because the data owner needs to handle the data as a compartment. However, a compartment could receive special protection in a system without being assigned a category label.
廃止予定の使用法：この用語集は「コンパートメント」よりもわずかに狭い意味で「カテゴリ」を定義しています。つまり、データの所有者がデータをコンパートメントとして処理する必要があるため、セキュリティラベルがカテゴリに割り当てられます。しかしながら、コンパートメントは、カテゴリラベルを割り当てることなくシステム内で特別な保護を受けることができる。
$ compartmented security mode (N) A mode of system operation wherein all users having access to the system have the necessary security clearance for the single, hierarchical classification level of all data handled by the system, but some users do not have the clearance for a non-hierarchical category of some data handled by the system. (See: category, /system operation/ under "mode", protection level, security clearance.)
$ コンパートメントセキュリティモード（n）システムにアクセスできるすべてのユーザーは、システムによって処理されるすべてのデータのシングル、階層的な分類レベルに対して必要なセキュリティクリアランスを持ちますが、一部のユーザーは非以外のクリアランスを持っていません。システムによって処理されるデータのいくつかのデータの階層的なカテゴリ。（カテゴリ、/システムの操作/「モード」、保護レベル、セキュリティクリアランス。）
Usage: Usually abbreviated as "compartmented mode". This term was defined in U.S. Government policy on system accreditation. In this mode, a system may handle (a) a single hierarchical classification level and (b) multiple non-hierarchical categories within that level.
使用法：通常、「コンパートメントモード」と略記されています。この用語は、システム認定に関する米国政府政策で定義されていました。このモードでは、システムは、単一の階層分類レベルと（B）そのレベル内の複数の非階層カテゴリを処理することができます。
$ Compartments field (I) A 16-bit field (the "C field") that specifies compartment values in the security option (option type 130) of version 4 IP's datagram header format. The valid field values are assigned by the U.S. Government, as specified in RFC 791.
$ コンパートメントフィールド（i）バージョン4 IPのデータグラムヘッダーフォーマットのセキュリティオプション（オプションタイプ130）内のコンパートメント値（オプションタイプ130）を指定する16ビットフィールド（Cフィールド）。有効なフィールド値は、RFC 791で指定されているように、米国政府によって割り当てられています。
Deprecated Abbreviation: IDOCs SHOULD NOT use the abbreviation "C field"; the abbreviation is potentially ambiguous. Instead, use "Compartments field".
廃止予定の省略形：IDOCは省略形「Cフィールド」を使用しないでください。略語は潜在的にあいまいです。代わりに、「コンパートメントフィールド」を使用してください。
$ component See: system component.
$ コンポーネントSee：システムコンポーネント。
$ compression (I) A process that encodes information in a way that minimizes the number of resulting code symbols and thus reduces storage space or transmission time.
$ 圧縮（i）結果のコードシンボルの数を最小にし、したがって記憶スペースまたは送信時間を短縮するように情報をエンコードするプロセス。
Tutorial: A data compression algorithm may be "lossless", i.e., retain all information that was encoded in the data, so that decompression can recover all the information; or an algorithm may be "lossy". Text usually needs to be compressed losslessly, but images are often compressed with lossy schemes.
チュートリアル：データ圧縮アルゴリズムは「無損失」、すなわちデータ内に符号化された全ての情報を保持することができるので、解凍はすべての情報を回復することができる。またはアルゴリズムが「損失」である可能性があります。テキストは通常損耗に圧縮される必要がありますが、画像は損失のあるスキームで圧縮されることがよくあります。
Not all schemes that encode information losslessly for machine processing are efficient in terms of minimizing the number of output bits. For example, ASCII encoding is lossless, but ASCII data can often be losslessly reencoded in fewer bits with other schemes. These more efficient schemes take advantage of some sort of inherent imbalance, redundancy, or repetition in the data, such as by replacing a character string in which all characters are the same by a shorter string consisting of only the single character and a character count.
マシン処理のために情報を除外するすべての方式は、出力ビット数を最小限に抑えるという点で効率的ではありません。たとえば、ASCIIエンコーディングは無損失ですが、ASCIIデータは他の方式のビットより少ないビットで無限に再符号化することがよくあります。これらのより効率的なスキームは、すべての文字が同じ文字列と文字数のみからなる短い文字列によって同じ文字列と同じ文字列を置き換えることによって、データ内の一種の固有の不均衡、冗長性、または繰り返しを利用する。
Lossless compression schemes cannot effectively reduce the number of bits in cipher text produced by a strong encryption algorithm, because the cipher text is essentially a pseudorandom bit string that does not contain patterns susceptible to reencoding. Therefore, protocols that offer both encryption and compression services (e.g., SSL) need to perform the compression operation before the encryption operation.
暗号化アルゴリズムによって生成された暗号テキストのビット数を効果的に減らすことはできません。暗号化されたテキストは、基本的には再実行の影響を受けやすいパターンを含まない疑似乱数ビット列です。したがって、暗号化および圧縮サービス（例えば、SSL）の両方を提供するプロトコルは、暗号化操作の前に圧縮動作を実行する必要がある。
$ compromise See: data compromise, security compromise.
$ 妥協を参照してください：データの妥協、セキュリティの妥協。
$ compromise recovery (I) The process of regaining a secure state for a system after detecting that the system has experienced a security compromise.
$ 妥協回復（i）システムがセキュリティ妥協を経験したことを検出した後にシステムのための安全な状態を取り戻すプロセス。
$ compromised key list (CKL) (N) /MISSI/ A list that identifies keys for which unauthorized disclosure or alteration may have occurred. (See: compromise.)
$ 不正な開示または変更が発生した可能性があるキーを識別するキーリスト（CKL）（N）/ MISSI / Aリスト。（妥協を参照してください。）
Tutorial: A CKL is issued by a CA, like a CRL is issued. But a CKL lists only KMIDs, not subjects that hold the keys, and not certificates in which the keys are bound.
チュートリアル：CRLが発行されるように、CKLがCAによって発行されます。しかしCKLはKMIDだけをリストし、キーを保持する件名ではなく、キーがバインドされている証明書ではありません。
$ COMPUSEC (I) See: computer security.
$ compusec（i）コンピュータセキュリティ。
$ computer emergency response team (CERT) (I) An organization that studies computer and network INFOSEC in order to provide incident response services to victims of attacks, publish alerts concerning vulnerabilities and threats, and offer other information to help improve computer and network security. (See: CSIRT, security incident.)
$ コンピュータ緊急対応チーム（証明書）（i）攻撃の被害者にインシデント対応サービスを提供するために、コンピュータとネットワーク情報を調査し、脆弱性と脅威に関するアラートを発行し、コンピュータとネットワークのセキュリティを向上させるための他の情報を提供する組織。（参照：CSIRT、セキュリティ事件。）
Examples: CERT Coordination Center at Carnegie Mellon University (sometimes called "the" CERT); CIAC.
例：Carnegie Mellon University（「CERT」と呼ばれることもあります）のCERTコーディネーションセンター。シアク。
$ Computer Incident Advisory Capability (CIAC) (O) The centralized CSIRT of the U.S. Department of Energy; a member of FIRST.
$ コンピュータインシデント諮問能力（CIAC）（O）米国エネルギー省の集中型CSIRT。最初のメンバー。
$ computer network (I) A collection of host computers together with the subnetwork or internetwork through which they can exchange data.
$ コンピュータネットワーク（i）サブネットワークまたはインターネットワークとともにそれらがデータを交換することができるホストコンピュータのコレクション。
Usage: This definition is intended to cover systems of all sizes and types, ranging from the complex Internet to a simple system composed of a personal computer dialing in as a remote terminal of another computer.
使用法：この定義は、複雑なインターネットから他のコンピュータの遠隔端末としてダイヤルされたパーソナルコンピュータで構成される単純なシステムとの範囲の、すべてのサイズとタイプのシステムをカバーすることを目的としています。
$ computer platform (I) A combination of computer hardware and an operating system (which may consist of software, firmware, or both) for that hardware. (Compare: computer system.)
$ コンピュータプラットフォーム（i）コンピュータハードウェアとオペレーティングシステムの組み合わせ（これはソフトウェア、ファームウェア、またはその両方）のハードウェアの組み合わせです。（比較：コンピュータシステム。）
$ computer security (COMPUSEC) 1. (I) Measures to implement and assure security services in a computer system, particularly those that assure access control service.
$ コンピュータセキュリティ（CompUsec）1.（i）コンピュータシステムでのセキュリティサービスを実装し保証するための対策、特にアクセス制御サービスを保証するものです。
Usage: Usually refers to internal controls (functions, features, and technical characteristics) that are implemented in software (especially in operating systems); sometimes refers to internal controls implemented in hardware; rarely used to refer to external controls.
使用法：通常、ソフトウェア（特にオペレーティングシステムで）実装されている内部統制（機能、機能、および技術的特徴）を指します。時にはハードウェアで実装されている内部コントロールを指すことがあります。外部コントロールを指すのにめったに使用されません。
2. (O) "The protection afforded to an automated information system in order to attain the applicable objectives of preserving the integrity, availability and confidentiality of information system resources (includes hardware, software, firmware, information/data, and telecommunications)." [SP12]
2. （O）「情報システムリソースの整合性、可用性、および機密性を保持する適用可能な目的を達成するために、自動情報システムに付与された保護は、（ハードウェア、ソフトウェア、ファームウェア、情報/データ、および電気通信を含む）。[SP12]
$ computer security incident response team (CSIRT) (I) An organization "that coordinates and supports the response to security incidents that involve sites within a defined constituency." [R2350] (See: CERT, FIRST, security incident.)
$ コンピュータセキュリティインシデント応答チーム（I）定義された構成要素内のサイトを含むセキュリティインシデントへの対応を調整してサポートする組織。」[R2350]（See：CERT、最初にセキュリティインシデント。）
Tutorial: To be considered a CSIRT, an organization must do as follows: (a) Provide a (secure) channel for receiving reports about suspected security incidents. (b) Provide assistance to members of its constituency in handling the incidents. (c) Disseminate incident-related information to its constituency and other involved parties.
チュートリアル：CSIRTと見なすためには、組織は次のようにしてください。（b）事件の取り扱いにおいてその構成要素のメンバーに支援を提供する。（c）インシデント関連情報をその構成業者およびその他の関与当事者に広める。
$ computer security object (I) The definition or representation of a resource, tool, or mechanism used to maintain a condition of security in computerized environments. Includes many items referred to in standards that are either selected or defined by separate user communities. [CSOR] (See: object identifier, Computer Security Objects Register.)
$ コンピュータセキュリティオブジェクト（i）コンピュータ化された環境におけるセキュリティの状態を維持するために使用されるリソース、ツール、またはメカニズムの定義または表現。別々のユーザーコミュニティによって選択または定義されている標準で言及されている多くの項目が含まれています。[CSOR]（「オブジェクト識別子、コンピュータセキュリティオブジェクト登録」を参照）
$ Computer Security Objects Register (CSOR) (N) A service operated by NIST is establishing a catalog for computer security objects to provide stable object definitions identified by unique names. The use of this register will enable the unambiguous specification of security parameters and algorithms to be used in secure data exchanges. (See: object identifier.)
$ コンピュータセキュリティオブジェクトレジスタ（CSOR）（N）NISTが操作するサービスは、コンピュータセキュリティオブジェクトのカタログを確立して、固有の名前で識別される安定したオブジェクト定義を提供します。このレジスタを使用すると、セキュリティパラメータとアルゴリズムを安全なデータ交換で使用することが明確に指定されます。（参照：オブジェクト識別子。）
Tutorial: The CSOR follows registration guidelines established by the international standards community and ANSI. Those guidelines establish minimum responsibilities for registration authorities and assign the top branches of an international registration hierarchy. Under that international registration hierarchy, the CSOR is responsible for the allocation of unique identifiers under the branch: {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3)}.
チュートリアル：CSORは、国際標準コミュニティとANSIによって確立された登録ガイドラインに従います。これらのガイドラインは、登録当局に対する最小責任を確立し、国際登録階層のトップブランチを割り当てます。その国際登録階層の下では、CSORはブランチの下での固有の識別子の割り当てを担当します。{共同ISO-CCITT（2）国（16）US（840）組織（1）GOV（3）}。
$ computer system (I) Synonym for "information system", or a component thereof. (Compare: computer platform.)
$ コンピュータシステム（i）「情報システム」の同義語、またはその構成要素。（比較：コンピュータプラットフォーム。）
$ Computers At Risk (O) The 1991 report [NRC91] of the System Security Study Committee, sponsored by the U.S. National Academy of Sciences and supported by the Defense Advanced Research Projects Agency of the U.S. DoD. It made many recommendations for industry and governments to improve computer security and trustworthiness. Some of the most important recommendations (e.g., establishing an Information Security Foundation chartered by the U.S. Government) have not been implemented at all, and others (e.g., codifying Generally Accepted System Security Principles similar to accounting principles) have been implemented but not widely adopted [SP14, SP27].
米国国立科学アカデミーと米国の国防科学アカデミーによって支援され、システムセキュリティスタディ委員会のリスクの$コンピュータ（O）システムセキュリティスタディ委員会の「NRC91」。それは産業や政府にコンピュータの安全性と信頼性を向上させるための多くの勧告をしました。最も重要な推奨事項のいくつか（例えば、米国政府が傭した情報セキュリティ基盤を確立する）は全く実装されていない（例えば、会計原則に似た一般的に承認されたシステムセキュリティの原則）が実施されていますが、広く採用されていません。[SP14、SP27]。
$ COMSEC (I) See: communication security.
$ COMSEC（i）コミュニケーションセキュリティを参照してください。
$ COMSEC account (O) /U.S. Government/ "Administrative entity, identified by an account number, used to maintain accountability, custody, and control of COMSEC material." [C4009] (See: COMSEC custodian.)
$ COMSECアカウント（O）/U.S。政府/「説明責任者、説明責任、監護権、およびCOMSEC資料の管理を維持するために使用される管理業者。」[C4009]（参照：Comsec Custodian。）
$ COMSEC accounting (O) /U.S. Government/ The process of creating, collecting, and maintaining data records that describe the status and custody of designated items of COMSEC material. (See: accounting legend code.)
$ COMSEC会計（O）/U.S。政府/ COMSEC資料の指定品目の状況と管理を記述するデータレコードの作成、収集、および維持のプロセス。（：会計の凡例コードを参照してください。）
Tutorial: Almost any secure information system needs to record a security audit trail, but a system that manages COMSEC material needs to record additional data about the status and custody of COMSEC items. - COMSEC tracking: The process of automatically collecting, recording, and managing information that describes the status of designated items of COMSEC material at all times during each product's lifecycle. - COMSEC controlling: The process of supplementing tracking data with custody data, which consists of explicit acknowledgements of system entities that they (a) have received specific COMSEC items and (b) are responsible for preventing exposure of those items.
チュートリアル：安全な情報システムはセキュリティ監査証跡を記録する必要がありますが、COMSECの資料を管理するシステムは、COMSEC項目のステータスと管理に関する追加のデータを記録する必要があります。 - COMSEC追跡：各製品のライフサイクルの間に、常にCOMSEC資料の指定項目のステータスを自動的に収集、記録、および管理するプロセス。 - COMSEC制御：COSTODYデータを持つトラッキングデータを補足するプロセス（A）が特定のCOMSEC項目を受信し、（B）を受信しているシステムエンティティの明示的な承認からなるプロセスは、それらのアイテムのエクスポージャーを防ぐ責任があります。
For example, a key management system that serves a large customer base needs to record tracking data for the same reasons that a national parcel delivery system does, i.e., to answer the question "Where is that thing now?". If keys are encrypted immediately upon generation and handled only in BLACK form between the point of generation and the point of use, then tracking may be all that is needed. However, in cases where keys are handled at least partly in RED form and are potentially subject to exposure, then tracking needs to be supplemented by controlling.
例えば、大規模な顧客ベースを提供する鍵管理システムは、国内区画配信システムが実行するのと同じ理由で追跡データを記録する必要がある、すなわち「今はそのことはどこであるのか」と答える必要がある。鍵が生成時に直ちに暗号化され、生成点と使用箇所との間でのみ黒の形でのみ扱われる場合、追跡は必要なすべてであり得る。しかしながら、鍵が少なくとも部分的に赤色の形で扱われ、潜在的に曝露の対象となる場合には、追跡は制御によって補足される必要がある。
Data that is used purely for tracking need be retained only temporarily, until an item's status changes. Data that is used for controlling is retained indefinitely to ensure accountability and support compromise recovery.
トラッキングのために純粋に使用されるデータは、アイテムのステータスが変わるまで一時的にのみ保持される必要があります。制御に使用されるデータは、説明責任を保証し、妥協の妥協を確実にするために無期限に保持されます。
$ COMSEC boundary (N) "Definable perimeter encompassing all hardware, firmware, and software components performing critical COMSEC functions, such as key generation and key handling and storage." [C4009] (Compare: cryptographic boundary.)
$ COMSEC境界（N） "すべてのハードウェア、ファームウェア、およびソフトウェアコンポーネントを包含する定義可能な境界は、キー生成とキー処理やストレージなどの重要なCOMSEC関数を実行します。"[C4009]（比較：暗号境界線）
$ COMSEC custodian (O) /U.S. Government/ "Individual designated by proper authority to be responsible for the receipt, transfer, accounting, safeguarding, and destruction of COMSEC material assigned to a COMSEC account." [C4009]
$ Comsec Custodian（O）/U.S。政府/「COMSECアカウントに割り当てられたCOMSEC資料の領収書、振替、会計、保護、および破壊の責任を負う権限が適切に指定された個人。」[C4009]
$ COMSEC material (N) /U.S. Government/ Items designed to secure or authenticate communications or information in general; these items include (but are not limited to) keys; equipment, devices, documents, firmware, and software that embodies or describes cryptographic logic; and other items that perform COMSEC functions. [C4009] (Compare: keying material.)
$ COMSECマテリアル（N）/ U.S。一般に通信や情報を保護または認証するように設計された政府/項目。これらの項目には（ただし、）キーが含まれます。暗号化ロジックを具体化または説明する機器、装置、文書、ファームウェア、およびソフトウェア。そしてCOMSEC機能を実行するその他の項目。[C4009]（Compare：Keying Material。）
$ COMSEC Material Control System (CMCS) (O) /U.S. Government/ "Logistics and accounting system through which COMSEC material marked 'CRYPTO' is distributed, controlled, and safeguarded." [C4009] (See: COMSEC account, COMSEC custodian.)
$ COMSEC資料制御システム（CMCS）/U.S。政府/「COMSEC資料を「暗号」とマークされている物流と会計システムは、管理されている。[C4009]（COMSECアカウント、ComSec Custodian。）
$ confidentiality See: data confidentiality.
$ 機密性の詳細：データ機密性。
$ concealment system (O) "A method of achieving confidentiality in which sensitive information is hidden by embedding it in irrelevant data." [NCS04] (Compare: steganography.)
$ 隠蔽システム（O）「機密情報が無関係なデータに埋め込むことによって隠されている機密性を達成する方法。」[NCS04]（比較：ステガノグラフィ。）
$ configuration control (I) The process of regulating changes to hardware, firmware, software, and documentation throughout the development and operational life of a system. (See: administrative security, harden, trusted distribution.)
$ 構成制御（i）システムの開発と運用上の寿命を通じて、ハードウェア、ファームウェア、ソフトウェア、および文書への変更を調整するプロセス。（管理セキュリティ、強化、信頼できる配布。）
Tutorial: Configuration control helps protect against unauthorized or malicious alteration of a system and thus provides assurance of system integrity. (See: malicious logic.)
チュートリアル：Configuration Controlは、システムの不正または悪意のある変更から保護するのに役立ち、システムの整合性の保証を提供します。（悪意のある論理を参照してください。）
$ confinement property (N) /formal model/ Property of a system whereby a subject has write access to an object only if the classification of the object dominates the clearance of the subject. (See: *-property, Bell-LaPadula model.)
$ 閉じ込めプロパティ（N）/正式なモデル/システムのクラス化が被写体のクリアランスを支配している場合にのみ、被験者がオブジェクトへの書き込みアクセス権を持っています。（参照：*プロパティ、ベルラップラドゥラモデル）
$ constraint (I) /access control/ A limitation on the function of an identity, role, or privilege. (See: rule-based access control.)
$ 制約（I）/アクセス制御/ ID、役割、または特権の機能に対する制限。（参照：ルールベースのアクセス制御）
Tutorial: In effect, a constraint is a form of security policy and may be either static or dynamic: - "Static constraint": A constraint that must be satisfied at the time the policy is defined, and then continues to be satisfied until the constraint is removed. - "Dynamic constraint": A constraint that may be defined to apply at various times that the identity, role, or other object of the constraint is active in the system.
チュートリアルでは、制約はセキュリティポリシーの一種であり、静的または動的でもあります。 - 「静的制約」：ポリシーが定義されているときに満たされなければならず、その後制約が満たされ続けます。削除されます。 - 「動的制約」：識別、役割、またはその他の拘束のオブジェクトがシステム内でアクティブになっている様々な時に適用するように定義されている制約。
$ content filter (I) /World Wide Web/ Application software used to prevent access to certain Web servers, such as by parents who do not want their children to access pornography. (See: filter, guard.)
$ コンテンツフィルタ（I）/ World Wide Web /アプリケーションソフトウェアは、子供たちがポルノにアクセスしたくない両親からの特定のWebサーバーへのアクセスを防ぐために使用されます。（以下を参照してください。
Tutorial: The filter is usually browser-based, but could be part of an intermediate cache server. The two basic content filtering techniques are (a) to block a specified list of URLs and (b) to block material that contains specified words and phrases.
チュートリアル：フィルタは通常ブラウザベースですが、中間キャッシュサーバーの一部になる可能性があります。2つの基本コンテンツフィルタリング手法は、（a）、指定された単語と句を含む材料をブロックするためのURLのリストリストをブロックするための（a）です。
$ contingency plan (I) A plan for emergency response, backup operations, and post-disaster recovery in a system as part of a security program to ensure availability of critical system resources and facilitate continuity of operations in a crisis. [NCS04] (See: availability.)
$ 緊急時刻計画（i）重要なシステムリソースの可用性を確保し、危機の継続性を促進するためのセキュリティプログラムの一環として、システム内の緊急対応、バックアップ事業、および災害後回復の計画。[NCS04]（availabilityを参照してください。）
$ control zone (O) "The space, expressed in feet of radius, surrounding equipment processing sensitive information, that is under sufficient physical and technical control to preclude an unauthorized entry or compromise." [NCSSG] (Compare: inspectable space, TEMPEST zone.)
$ コントロールゾーン（O）「半径の足で表されるスペースは、機器を囲む機器の処理に敏感な情報を処理し、それは不正なエントリまたは妥協を排除するための十分な物理的および技術的制御下にあります。」[NCSSG]（比較：検査可能なスペース、温度帯。）
$ controlled access protection (O) /TCSEC/ The level of evaluation criteria for a C2 computer system.
$ C2 / TCSEC / C2コンピュータシステムの評価基準のレベル。
Tutorial: The major features of the C2 level are individual accountability, audit, access control, and object reuse.
チュートリアル：C2レベルの主な機能は、個別の説明責任、監査、アクセス制御、およびオブジェクトの再利用です。
$ controlled cryptographic item (CCI) (O) /U.S. Government/ "Secure telecommunications or information handling equipment, or associated cryptographic component, that is unclassified but governed by a special set of control requirements." [C4009] (Compare: EUCI.)
$ 制御された暗号化項目（CCI）（O）/U.S。政府/「電気通信または情報処理機器、または関連する暗号構成要素、特別な制御要件のセットによって支配されている関連する暗号化コンポーネント」。[C4009]（Compare：Euci。）
Tutorial: This category of equipment was established in 1985 to promote broad use of secure equipment for protecting both classified and unclassified information in the national interest. CCI equipment uses a classified cryptographic logic, but the hardware or firmware embodiment of that logic is unclassified. Drawings, software implementations, and other descriptions of that logic remain classified. [N4001]
チュートリアル：この機器のこのカテゴリーは1985年に設立され、分類された情報と非分類の両方の情報の両方の国家興味の両方を保護するための安全な機器の幅広い使用を促進しました。CCI機器は分類された暗号化ロジックを使用していますが、そのロジックのハードウェアまたはファームウェアの実施形態は解除されていません。その論理の描画、ソフトウェアの実装、およびその他の説明は分類されたままです。[N4001]
$ controlled interface (I) A mechanism that facilitates the adjudication of the different security policies of interconnected systems. (See: domain, guard.)
$ 制御されたインタフェース（i）相互接続されたシステムの異なるセキュリティポリシーの判決を容易にするメカニズム。（参照：ドメイン、ガード。）
$ controlled security mode (D) /U.S. DoD/ A mode of system operation wherein (a) two or more security levels of information are allowed to be handled concurrently within the same system when some users having access to the system have neither a security clearance nor need-to-know for some of the data handled by the system, but (b) separation of the users and the classified material on the basis, respectively, of clearance and classification level are not dependent only on operating system control (like they are in multilevel security mode). (See: /system operation/ under "mode", protection level.)
$ 制御されたセキュリティモード（d）/u.s。DOD /システム操作のモードでは、システムにアクセスできるユーザーがセキュリティのクリアランスも知らない場合にも、同じシステム内で2つ以上のセキュリティレベルの情報を同時に処理することができます。システムによって処理されるデータ。（：/システム操作/「モード」、保護レベル。）
Deprecated Term: IDOCs SHOULD NOT use this term. It was defined in a U.S. Government policy regarding system accreditation and was subsumed by "partitioned security mode" in a later policy. Both terms were dropped in still later policies.
廃止予定語：IDocsはこの用語を使用しないでください。システム認定に関する米国政府の方針で定義され、後のポリシーで「分割セキュリティモード」と添付されました。どちらの用語はまだ後のポリシーでドロップされました。
Tutorial: Controlled mode was intended to encourage ingenuity in meeting data confidentiality requirements in ways less restrictive than "dedicated security mode" and "system-high security mode", but at a level of risk lower than that generally associated with true "multilevel security mode". This was intended to be accomplished by implementation of explicit augmenting measures to reduce or remove a substantial measure of system software vulnerability together with specific limitation of the security clearance levels of users having concurrent access to the system.
チュートリアル：制御モードは、「専用セキュリティモード」および「システム - 高セキュリティモード」よりも制限が少ない方法でデータ機密性の要件を満たすことを奨励することを目的としていましたが、一般的には真の「マルチレベルセキュリティモード」に関連しています。"。これは、システムへの同時アクセスを有するユーザのセキュリティクリアランスレベルの特定の制限と共に、システムソフトウェアの脆弱性の実質的な範囲を軽減または削除するための明示的な増強措置の実施によって達成されることを意図していた。
$ controlling authority (O) /U.S. Government/ "Official responsible for directing the operation of a cryptonet and for managing the operational use and control of keying material assigned to the cryptonet." [C4009, N4006]
$ 制御権限（O）/U.S。政府/「暗号設定の操作を指示し、運用上の使用を管理し、暗号設定に割り当てられているキーイング資料の管理を担当します。」[C4009、N4006]
$ cookie 1. (I) /HTTP/ Data exchanged between an HTTP server and a browser (a client of the server) to store state information on the client side and retrieve it later for server use.
$ Cookie 1.（i）/ http /データは、HTTPサーバとブラウザ（サーバのクライアント）との間で交換し、クライアント側に状態情報を格納し、後でサーバ使用するために検索する。
Tutorial: An HTTP server, when sending data to a client, may send along a cookie, which the client retains after the HTTP connection closes. A server can use this mechanism to maintain persistent client-side state information for HTTP-based applications, retrieving the state information in later connections. A cookie may include a description of the range of URLs for which the state is valid. Future requests made by the client in that range will also send the current value of the cookie to the server. Cookies can be used to generate profiles of web usage habits, and thus may infringe on personal privacy.
チュートリアル：クライアントにデータを送信するときに、Cookieに沿って送信することができます。これは、HTTP接続が閉じた後にクライアントが保持するCookieに沿って送信できます。サーバーは、このメカニズムを使用して、HTTPベースのアプリケーションの永続的なクライアント側の状態情報を維持し、後の接続で状態情報を取得できます。クッキーは、状態が有効であるURLの範囲の説明を含み得る。その範囲内のクライアントによって行われた将来の要求も、Cookieの現在の値をサーバーに送信します。クッキーを使用してWeb使用習慣のプロファイルを生成することができ、したがって個人的なプライバシーを侵害することができます。
2. (I) /IPsec/ Data objects exchanged by ISAKMP to prevent certain denial-of-service attacks during the establishment of a security association.
2. （i）/ IPSEC /データオブジェクトは、セキュリティアソシエーションの確立中に特定のサービス拒否攻撃を防ぐためにISAKMPによって交換されます。
3. (D) /access control/ Synonym for "capability token" or "ticket".
3. （D）/アクセス制御/「機能トークン」または「チケット」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 3; that would duplicate the meaning of better-established terms and mix concepts in a potentially misleading way.
廃止予定の定義：IDocsはこの用語を定義3で使用しないでください。それは、潜在的に誤解を招くような方法で、より良い確立された用語と混合の概念の意味を複製します。
$ Coordinated Universal Time (UTC) (N) UTC is derived from International Atomic Time (TAI) by adding a number of leap seconds. The International Bureau of Weights and Measures computes TAI once each month by averaging data from many laboratories. (See: GeneralizedTime, UTCTime.)
$ 協定ユニバーサルタイム（UTC）（N）UTCは、LEAP秒数を追加することによって国際アトミックタイム（TAI）から導き出されます。国際的な重み局と対策は、多くの研究室からのデータを平均化することによって毎月一回TAIを計算します。（：一般化時間、utctime。）
$ correction (I) /security/ A system change made to eliminate or reduce the risk of reoccurrence of a security violation or threat consequence. (See: secondary definition under "security".)
$ 補正（I）/セキュリティ/セキュリティ違反または脅威の結果の再発のリスクを排除または軽減するために行われたシステム変更。（「セキュリティ」の下の2次定義を参照してください。）
$ correctness (I) "The property of a system that is guaranteed as the result of formal verification activities." [Huff] (See: correctness proof, verification.)
$ 正当性（i）「正式な検証活動の結果として保証されているシステムの財産」。[huff]（参照：正確性証明、検証。）
$ correctness integrity (I) The property that the information represented by data is accurate and consistent. (Compare: data integrity, source integrity.)
$ 正当性の整合性（i）データによって表される情報が正確かつ一貫性のあるプロパティ。（比較：データの整合性、ソースの整合性。）
Tutorial: IDOCs SHOULD NOT use this term without providing a definition; the term is neither well-known nor precisely defined. Data integrity refers to the constancy of data values, and source integrity refers to confidence in data values. However, correctness integrity refers to confidence in the underlying information that data values represent, and this property is closely related to issues of accountability and error handling.
チュートリアル：IDocは定義を提供せずにこの用語を使用しないでください。この用語はよく知られていないことも正確に定義されていません。データの整合性はデータ値の恒常性を表し、ソースの整合性はデータ値への信頼性を表します。しかしながら、正確性の整合性は、データ値が表す基礎となる情報への信頼性を表し、この性質は説明責任とエラー処理の問題と密接に関係しています。
$ correctness proof (I) A mathematical proof of consistency between a specification for system security and the implementation of that specification. (See: correctness, formal specification.)
$ 正当性証明（i）システムセキュリティのための仕様とその仕様の実装との間の一貫性の数学的証明。（正確さ、正式な仕様を参照してください。）
$ corruption (I) A type of threat action that undesirably alters system operation by adversely modifying system functions or data. (See: disruption.)
$ 破損（i）システム機能やデータを悪用することでシステム操作を望ましくないほど変化する一種の脅威行動。（混乱を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Tampering": /corruption/ Deliberately altering a system's logic, data, or control information to interrupt or prevent correct operation of system functions. (See: misuse, main entry for "tampering".) - "Malicious logic": /corruption/ Any hardware, firmware, or software (e.g., a computer virus) intentionally introduced into a system to modify system functions or data. (See: incapacitation, main entry for "malicious logic", masquerade, misuse.) - "Human error": /corruption/ Human action or inaction that unintentionally results in the alteration of system functions or data. - "Hardware or software error": /corruption/ Error that results in the alteration of system functions or data. - "Natural disaster": /corruption/ Any "act of God" (e.g., power surge caused by lightning) that alters system functions or data. [FP031 Section 2]
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「改ざん」：/破損/意図的にシステムのロジック、データ、または制御情報を変更して、システム機能の正しい動作を中断または防止します。（誤用、「改ざん」の主なエントリー） - 「悪意のある論理」：/破損/システム機能またはデータを修正するためのシステムに故意に導入されたシステムに任意に導入されたハードウェア、ファームウェア、またはソフトウェア（例えば、コンピュータウイルス）。（無能さ、「悪意のある論理」の主なエントリー、マスカレード、誤用。） - 「ヒューマンエラー」：/破損/人間の行動や不作為では意図せずにシステム機能やデータの変更をもたらす。 - 「ハードウェアまたはソフトウェアのエラー」：/破損/エラーシステム機能やデータの変更をもたらす。 - 「自然災害」：/汚職/「神の行為」（例えば、雷による電力サージ）システム機能やデータを変更する。[FP031セクション2]
$ counter 1. (N) /noun/ See: counter mode.
$ カウンタ1.（n）/名詞/参照：カウンタモード。
2. (I) /verb/ See: countermeasure.
2. （i）/動詞/見る対策。
$ counter-countermeasure (I) An action, device, procedure, or technique used by an attacker to offset a defensive countermeasure.
$ 対抗対策（i）防御対策を相殺するための攻撃者が使用する行動、装置、手順、または技術。
Tutorial: For every countermeasure devised to protect computers and networks, some cracker probably will be able to devise a counter-countermeasure. Thus, systems must use "defense in depth".
チュートリアル：コンピュータやネットワークを保護するために考案されたすべての対策のために、いくつかのクラッカーは対策を考案することができるでしょう。したがって、システムは「深さの防御」を使用する必要があります。
$ counter mode (CTR) (N) A block cipher mode that enhances ECB mode by ensuring that each encrypted block is different from every other block encrypted under the same key. [SP38A] (See: block cipher.)
$ カウンタモード（CTR）（N）各暗号化ブロックが、同じキーで暗号化された他のすべてのブロックとは異なるように、ECBモードを強化するブロック暗号モード。[SP38A]（[暗号化]を参照）
Tutorial: This mode operates by first encrypting a generated sequence of blocks, called "counters", that are separate from the input sequence of plaintext blocks which the mode is intended to protect. The resulting sequence of encrypted counters is exclusive-ORed with the sequence of plaintext blocks to produce the final ciphertext output blocks. The sequence of counters must have the property that each counter is different from every other counter for all of the plain text that is encrypted under the same key.
チュートリアル：このモードは、最初に「カウンタ」と呼ばれる、「カウンタ」と呼ばれる、「カウンタ」と呼ばれるブロックのシーケンスのシーケンスを暗号化します。これは、モードが保護することを意図している平文ブロックの入力シーケンスとは別のものです。結果として得られる暗号化カウンタのシーケンスは、最終暗号文出力ブロックを生成するための平文ブロックのシーケンスと排他的論理和をしています。カウンタのシーケンスは、同じキーの下で暗号化されているすべてのプレーンテキストに対して、各カウンタが他のすべてのカウンタとは異なるプロパティを持つ必要があります。
$ Counter with Cipher Block Chaining-Message Authentication Code (CCM) (N) A block cipher mode [SP38C] that provides both data confidentiality and data origin authentication, by combining the techniques of CTR and a CBC-based message authentication code. (See: block cipher.)
$ 暗号ブロックChaining-Message認証コード（CCM）（N）CTRのテクニックとCBCベースのメッセージ認証コードの組み合わせを組み合わせることで、データ機密性とデータ原点認証の両方を提供するブロック暗号モード[SP38C]。（以下を参照してください。
$ countermeasure (I) An action, device, procedure, or technique that meets or opposes (i.e., counters) a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken.
$ 対策（i）脅威、脆弱性、または攻撃を排除したり防止したりすることで、または発見して報告することによって、脅威、脆弱性、または攻撃を満たす行動、装置、手順、またはテクニック是正措置を講じることができるように。
Tutorial: In an Internet protocol, a countermeasure may take the form of a protocol feature, a component function, or a usage constraint.
チュートリアル：インターネットプロトコルでは、対策はプロトコル機能、コンポーネント機能、または使用制約の形をとることがあります。
$ country code (I) An identifier that is defined for a nation by ISO. [I3166]
$ 国コード（i）ISOによって国で定義されている識別子。[I3166]
Tutorial: For each nation, ISO Standard 3166 defines a unique two-character alphabetic code, a unique three-character alphabetic code, and a three-digit code. Among many uses of these codes, the two-character codes are used as top-level domain names.
チュートリアル：各国の場合、ISO標準3166は、一意の2文字のアルファベットコード、一意の3文字のアルファベットコード、および3桁のコードを定義します。これらのコードの多くの用途の中で、2文字のコードは最上位のドメイン名として使用されます。
$ Courtney's laws (N) Principles for managing system security that were stated by Robert H. Courtney, Jr.
$ Robert H. Courtney、Jr。
Tutorial: Bill Murray codified Courtney's laws as follows: [Murr]
- Courtney's first law: You cannot say anything interesting
(i.e., significant) about the security of a system except in
the context of a particular application and environment.
- Courtney's second law: Never spend more money eliminating a
security exposure than tolerating it will cost you. (See:
acceptable risk, risk analysis.)
-- First corollary: Perfect security has infinite cost.
-- Second corollary: There is no such thing as zero risk.
- Courtney's third law: There are no technical solutions to
management problems, but there are management solutions to
technical problems.
$ covert action (I) An operation that is planned and executed in a way that conceals the identity of the operator.
$ Covert Action（i）オペレータの身元を隠す方法で計画され実行される操作。
$ covert channel 1. (I) An unintended or unauthorized intra-system channel that enables two cooperating entities to transfer information in a way that violates the system's security policy but does not exceed the entities' access authorizations. (See: covert storage channel, covert timing channel, out-of-band, tunnel.)
$ Covert Channel 1.（i）2つの協力したエンティティがシステムのセキュリティポリシーに違反するがエンティティのアクセス権限を超えない方法で情報を転送することを可能にする意図しないまたは不正なシステム内チャネル。（以下を参照してください.Cover Storage Channel、Covert Timing Channel、Oun-of-Bander、Tunnel。）
2. (O) "A communications channel that allows two cooperating processes to transfer information in a manner that violates the system's security policy." [NCS04]
2. （O）「システムのセキュリティポリシーに違反する方法で2つの協力プロセスを転送することを可能にする通信チャネル。」[NCS04]
Tutorial: The cooperating entities can be either two insiders or an insider and an outsider. Of course, an outsider has no access authorization at all. A covert channel is a system feature that the system architects neither designed nor intended for information transfer.
チュートリアル：協力したエンティティは、2つのインサイダーまたはインサイダー、および部外者のどちらかです。もちろん、部外者にはアクセス許可がありません。CoverT Channelは、システムアーキテクトが設計されていないことも情報転送を目的としていないシステム機能です。
$ covert storage channel (I) A system feature that enables one system entity to signal information to another entity by directly or indirectly writing a storage location that is later directly or indirectly read by the second entity. (See: covert channel.)
$ Covert Storage Channel（i）1つのシステムエンティティが、直接または間接的に第2のエンティティによって直接読み取られる格納場所を直接的または間接的に書き込むことによって、1つのシステムエンティティが他のエンティティへの情報を送信することを可能にするシステム機能。（参照してください。
$ covert timing channel (I) A system feature that enables one system entity to signal information to another by modulating its own use of a system resource in such a way as to affect system response time observed by the second entity. (See: covert channel.)
$ Covert Timing Channel（i）システムリソースの自身の使用を変調することによって、システムリソースの自身の使用を変調することによって、システムリソースの独自の使用を変調することを可能にするシステム機能が、第2のエンティティによって観察されるシステムの応答時間に影響を与えることを可能にする。（参照してください。
$ CPS (I) See: certification practice statement.
$ CPS（I）認証慣行ステートメントを参照してください。
$ cracker (I) Someone who tries to break the security of, and gain unauthorized access to, someone else's system, often with malicious intent. (See: adversary, intruder, packet monkey, script kiddy. Compare: hacker.)
$ クラッカー（i）のセキュリティを壊して、他の人のシステムへの不正アクセスを壊そうとし、悪意のある意図を持つことが多い人。（敵対者、侵入者、パケット猿、スクリプトキディ。比較：ハッカー。）
Usage: Was sometimes spelled "kracker". [NCSSG]
使用法：時々「KRACKER」を綴った。[NCSSG]
$ CRAM (I) See: Challenge-Response Authentication Mechanism.
$ CRAM（i）チャレンジ対応認証メカニズムを参照してください。
$ CRC (I) See: cyclic redundancy check.
$ CRC（I）巡回冗長検査を参照してください。
$ credential 1. (I) /authentication/ "identifier credential": A data object that is a portable representation of the association between an identifier and a unit of authentication information, and that can be presented for use in verifying an identity claimed by an entity that attempts to access a system. Example: X.509 public-key certificate. (See: anonymous credential.)
$ 信任状1.（i）/認証/「識別子信任状」：識別子と認証情報の単位との間の関連性の携帯表現であるデータオブジェクト、およびエンティティが主張したアイデンティティの検証に使用することができるデータオブジェクトそれはシステムにアクセスしようとします。例：X.509公開鍵証明書。（匿名の資格情報を参照してください。）
2. (I) /access control/ "authorization credential": A data object that is a portable representation of the association between an identifier and one or more access authorizations, and that can be presented for use in verifying those authorizations for an entity that attempts such access. Example: X.509 attribute certificate. (See: capability token, ticket.)
2. （i）/アクセス制御/「承認信任状」：識別子と1つ以上のアクセス許可との間の関連性の携帯型表現であり、そのような試みを試みるエンティティの承認の検証に使用するために提示することができるデータオブジェクト。アクセス。例：X.509属性証明書。（：能力トークン、チケット。）
3. (D) /OSIRM/ "Data that is transferred to establish the claimed identity of an entity." [I7498-2]
3. （d）/ osirm /「請求された企業の識別情報を確立するために転送されるデータ」[I7498-2]
Deprecated Definition: IDOCs SHOULD NOT use the term with definition 3. As explained in the tutorial below, an authentication process can involve the transfer of multiple data objects, and not all of those are credentials.
廃止予定の定義：IDocは定義3で用語を使用しないでください。以下のチュートリアルで説明されているように、認証プロセスは複数のデータオブジェクトの転送を含めることができ、それらのすべてが資格情報ではありません。
4. (D) /U.S. Government/ "An object that is verified when presented to the verifier in an authentication transaction." [M0404]
4. （d）/u.S。政府/「認証トランザクションの検証者に提示されたときに検証されたオブジェクト」[M0404]
Deprecated Definition: IDOCs SHOULD NOT use the term with definition 4; it mixes concepts in a potentially misleading way. For example, in an authentication process, it is the identity that is "verified", not the credential; the credential is "validated". (See: validate vs. verify.) Tutorial: In general English, "credentials" are evidence or testimonials that (a) support a claim of identity or authorization and (b) usually are intended to be used more than once (i.e., a credential's life is long compared to the time needed for one use). Some examples are a policeman's badge, an automobile driver's license, and a national passport. An authentication or access control process that uses a badge, license, or passport is outwardly simple: the holder just shows the thing.
廃止予定の定義：IDocは定義4で用語を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。たとえば、認証プロセスでは、信任状ではなく「検証済み」の識別情報です。資格情報は「検証」されています。チュートリアル：一般英語では、「認証情報」は、（A）IDまたは認可の主張をサポートし、（B）は通常複数回使用されることを意図している証拠または推薦者です（つまり、信任状の人生は、1つの使用に必要な時間と比較して長いです。いくつかの例は、警官のバッジ、自動車の運転免許証、および国内のパスポートです。バッジ、ライセンス、またはパスポートを使用する認証またはアクセス制御プロセスは外側に簡単です。ホルダーはただのことを示しています。
The problem with adopting this term in Internet security is that an automated process for authentication or access control usually requires multiple steps using multiple data objects, and it might not be immediately obvious which of those objects should get the name "credential".
インターネットセキュリティでこの用語を採用するという問題は、認証またはアクセス制御のための自動化されたプロセスで、通常複数のデータオブジェクトを使用して複数のステップを必要とし、すぐに明らかではないかもしれません。
For example, if the verification step in a user authentication process employs public-key technology, then the process involves at least three data items: (a) the user's private key, (b) a signed value -- signed with that private key and passed to the system, perhaps in response to a challenge from the system -- and (c) the user's public-key certificate, which is validated by the system and provides the public key needed to verify the signature. - Private key: The private key is *not* a credential, because it is never transferred or presented. Instead, the private key is "authentication information", which is associated with the user's identifier for a specified period of time and can be used in multiple authentications during that time. - Signed value: The signed value is *not* a credential; the signed value is only ephemeral, not long lasting. The OSIRM definition could be interpreted to call the signed value a credential, but that would conflict with general English. - Certificate: The user's certificate *is* a credential. It can be "transferred" or "presented" to any person or process that needs it at any time. A public-key certificate may be used as an "identity credential", and an attribute certificate may be used as an "authorization credential".
たとえば、ユーザー認証プロセスの検証ステップが公開鍵テクノロジを採用している場合、プロセスには少なくとも3つのデータ項目が含まれます。（a）ユーザーの秘密鍵、（b）署名付きの値（B）署名された秘密キーとシステムから課題に応答してシステムに渡され、システムによって検証されているユーザーの公開鍵証明書がシステムから検証され、署名を検証するために必要な公開鍵を提供します。 - 秘密鍵：秘密鍵は*返金または提示されることはありませんので、*ではありません。代わりに、秘密鍵は、指定された期間のユーザーの識別子に関連付けられている「認証情報」であり、その間に複数の認証で使用できます。 - 符号付き値：符号付き値は*ではありません*クレデンシャルです。符号付きの値は、長期的ではなく、一時的なものです。 OSIRR定義は、署名付きの値を信任状に呼び出すことを解釈することができますが、一般的な英語と競合する可能性があります。 - 証明書：ユーザーの証明書*は*信任状です。それはいつでもそれを必要とする人やプロセスに「転送」または「提示」することができます。公開鍵証明書を「ID認証情報」として使用することができ、属性証明書を「許可信任状」として使用することができます。
$ critical 1. (I) /system resource/ A condition of a system resource such that denial of access to, or lack of availability of, that resource would jeopardize a system user's ability to perform a primary function or would result in other serious consequences, such as human injury or loss of life. (See: availability, precedence. Compare: sensitive.)
$ クリティカル1.（i）/システムリソース/アクセス権の拒否、またはそのリソースがシステムユーザーの主な関数を実行するシステムユーザーの能力を危うくするか、またはその他の深刻な結果をもたらすようなシステムリソースの状態人間の傷害や人生の喪失など。（待機可能性、優先順位。比較：敏感な。）
2. (N) /extension/ An indication that an application is not permitted to ignore an extension. [X509]
2. （n）/拡張子/アプリケーションが拡張子を無視することが許可されていないことを指示します。[X509]
Tutorial: Each extension of an X.509 certificate or CRL is flagged as either "critical" or "non-critical". In a certificate, if a computer program does not recognize an extension's type (i.e., does not implement its semantics), then if the extension is critical, the program is required to treat the certificate as invalid; but if the extension is non-critical, the program is permitted to ignore the extension.
チュートリアル：X.509証明書またはCRLの各拡張子は、「クリティカル」または「非クリティカル」としてフラグが立てられています。証明書では、コンピュータプログラムが拡張子の種類を認識しない場合（すなわち、その意味論を実装していない）、拡張子が重要である場合、そのプログラムは証明書を無効として扱うために必要である。しかし、拡張子が重要でない場合、プログラムは拡張機能を無視することが許可されています。
In a CRL, if a program does not recognize a critical extension that is associated with a specific certificate, the program is required to assume that the listed certificate has been revoked and is no longer valid, and then take whatever action is required by local policy.
CRLでは、プログラムが特定の証明書に関連付けられている重要な拡張機能を認識しない場合、プログラムはリストされている証明書が取り消され、無効になっていないと想定し、その後ローカルポリシーで必要なアクションを実行する必要があります。。
When a program does not recognize a critical extension that is associated with the CRL as a whole, the program is required to assume that all listed certificates have been revoked and are no longer valid. However, since failing to process the extension may mean that the list has not been completed, the program cannot assume that other certificates are valid, and the program needs to take whatever action is therefore required by local policy.
プログラムがCRL全体に関連付けられている重要な拡張機能を認識しない場合、プログラムはリストされているすべての証明書が取り消され、無効になっていると仮定するために必要です。ただし、拡張機能の処理に失敗することは、リストが完了していないことを意味している可能性があるため、プログラムは他の証明書が有効であると仮定することはできず、したがってローカルポリシーによって必要とされるアクションを実行する必要があります。
$ critical information infrastructure (I) Those systems that are so vital to a nation that their incapacity or destruction would have a debilitating effect on national security, the economy, or public health and safety.
$ 重要な情報インフラストラクチャ（i）彼らの不安定または破壊が国家安全保障、経済、または公衆衛生および安全性に衰弱させる効果を持つことになるシステム。
$ CRL (I) See: certificate revocation list.
$ CRL（i）証明書失効リストを参照してください。
$ CRL distribution point (I) See: distribution point.
$ CRL配布ポイント（i）配布ポイントを参照してください。
$ CRL extension (I) See: extension.
$ CRL拡張子（i）拡張子を参照してください。
$ cross-certificate (I) A public-key certificate issued by a CA in one PKI to a CA in another PKI. (See: cross-certification.)
$ 相互証明書（i）PKIのCAが別のPKIのCAにCAによって発行された公開鍵証明書。（以下を参照してください。）
$ cross-certification (I) The act or process by which a CA in one PKI issues a public-key certificate to a CA in another PKI. [X509] (See: bridge CA.)
$ クロス認証（I）1つのPKIのCAが別のPKIのCAに公開鍵証明書を発行する行為またはプロセス。[X509]（参照：ブリッジCAを参照）
Tutorial: X.509 says that a CA (say, CA1) may issue a "cross-certificate" in which the subject is another CA (say, CA2). X.509 calls CA2 the "subject CA" and calls CA1 an "intermediate CA", but this Glossary deprecates those terms. (See: intermediate CA, subject CA).
チュートリアル：X.509は、CA（Say、CA1）が、被写体が別のCAである「証明書」を発行することができると述べています（Say、CA2）。X.509 CA2を呼び出し、CA1を「中間CA」に呼び出しますが、この用語集はそれらの条項を排除します。（：中間CA、件名CA）。
Cross-certification of CA2 by CA1 appears similar to certification of a subordinate CA by a superior CA, but cross-certification involves a different concept. The "subordinate CA" concept applies when both CAs are in the same PKI, i.e., when either (a) CA1 and CA2 are under the same root or (b) CA1 is itself a root. The "cross-certification" concept applies in other cases:
CA1によるCA2のクロス認証は、優れたCAによる従属CAの認証と同様に見えますが、クロス認証は異なる概念を含みます。「下位CA」の概念は、両方のCAが同じPKI内にあるとき、すなわち（a）CA1およびCA2が同じルートまたは（B）CA1の下にあるときに適用されるか（B）CA1はそれ自体である。「クロス認証」の概念は他の場合に適用されます。
First, cross-certification applies when two CAs are in different PKIs, i.e., when CA1 and CA2 are under different roots, or perhaps are both roots themselves. Issuing the cross-certificate enables end entities certified under CA1 in PK1 to construct the certification paths needed to validate the certificates of end entities certified under CA2 in PKI2. Sometimes, a pair of cross-certificates is issued -- by CA1 to CA2, and by CA2 to CA1 -- so that an end entity in either PKI can validate certificates issued in the other PKI.
第一に、2つのCAが異なるPKI、すなわちCA1およびCA2が異なる根の下にあるとき、またはおそらく根自体であるときには、クロス認証が適用される。相互証明書を発行することで、PK1のCA1で認定されたエンティティが認定されたエンティティは、PKI2のCA2で認定されたエンドエンティティの証明書を検証するために必要な認証パスを構築できます。時々、一対の相互証明書がCA1からCA2によって、CA2からCA1まで発行されるため、PKIのいずれのPKIで発行された証明書を検証することができます。
Second, X.509 says that two CAs in some complex, multi-CA PKI can cross-certify one another to shorten the certification paths constructed by end entities. Whether or not a CA may perform this or any other form of cross-certification, and how such certificates may be used by end entities, should be addressed by the local certificate policy and CPS.
第二に、X.509では、いくつかの複雑で、Multi-CA PKIが互いに互いに交差することができ、エンドエンティティによって構築された認証パスを短縮することができます。CAがこれまたは他のどのような形式のクロス認証を実行するかどうか、およびそのような証明書がエンドエンティティによってどのように使用され得るかは、ローカル証明書ポリシーおよびCPSによってアドレス指定されるべきである。
$ cross-domain solution 1. (D) Synonym for "guard".
$ クロスドメインソリューション1.（d） "Guard"の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for "guard"; this term unnecessarily (and verbosely) duplicates the meaning of the long-established "guard".
廃止予定の用語：IDOCは、この用語を「Guard」の同義語として使用しないでください。この用語は不必要に（そして冗長的に）長い「警備員」の意味を複製します。
2. (O) /U.S. Government/ A process or subsystem that provides a capability (which could be either manual or automated) to access two or more differing security domains in a system, or to transfer information between such domains. (See: domain, guard.)
2. （O）/U.S。政府/システム内の2つ以上の異なるセキュリティドメインにアクセスするため、またはそのようなドメイン間で情報を転送する機能（手動または自動化された）を提供するプロセスまたはサブシステム。（参照：ドメイン、ガード。）
$ cryptanalysis 1. (I) The mathematical science that deals with analysis of a cryptographic system to gain knowledge needed to break or circumvent the protection that the system is designed to provide. (See: cryptology, secondary definition under "intrusion".)
$ Cryptanalysis 1.（i）システムが提供するように設計されている保護を破るか回避するために必要な知識を得るための暗号システムの分析を扱う数学的科学。（「侵入」の下の二次定義、暗号化、二次定義を参照してください。）
2. (O) "The analysis of a cryptographic system and/or its inputs and outputs to derive confidential variables and/or sensitive data including cleartext." [I7498-2]
2. （O） "暗号システムの分析および/またはその入力およびその入力および出力および/またはClearTextを含む機密変数および/または機密データを導出する。[I7498-2]
Tutorial: Definition 2 states the traditional goal of cryptanalysis, i.e., convert cipher text to plain text (which usually is clear text) without knowing the key; but that definition applies only to encryption systems. Today, the term is used with reference to all kinds of cryptographic algorithms and key management, and definition 1 reflects that. In all cases, however, a cryptanalyst tries to uncover or reproduce someone else's sensitive data, such as clear text, a key, or an algorithm. The basic cryptanalytic attacks on encryption systems are ciphertext-only, known-plaintext, chosen-plaintext, and chosen-ciphertext; and these generalize to the other kinds of cryptography.
チュートリアル：定義2は、暗号化の伝統的な目標、すなわちキーを知らずに暗号テキストをプレーンテキスト（通常はクリアテキストである）に変換します。しかし、その定義は暗号化システムにのみ適用されます。今日、この用語は、あらゆる種類の暗号化アルゴリズムと鍵管理を参照して使用され、定義1はそれを反映しています。ただし、すべての場合において、暗号輪は、クリアテキスト、キー、またはアルゴリズムなど、他の人の機密データを明らかにまたは再現しようとします。暗号化システムに対する基本的な暗号分析攻撃は、暗号文のみ、既知の平文、選択された平文、および選択暗号文です。そしてこれらは他の種類の暗号化に一般化します。
$ crypto, CRYPTO 1. (N) A prefix ("crypto-") that means "cryptographic".
$ 暗号、暗号1.（n）「暗号化」を意味するプレフィックス（「暗号化」）。
Usage: IDOCs MAY use this prefix when it is part of a term listed in this Glossary. Otherwise, IDOCs SHOULD NOT use this prefix; instead, use the unabbreviated adjective, "cryptographic".
使用法：IDOCは、この用語集に記載されている用語の一部である場合、このプレフィックスを使用することがあります。それ以外の場合は、IDocsはこの接頭辞を使用しないでください。代わりに、非abbraified形容詞「暗号化」を使用してください。
2. (D) In lower case, "crypto" is an abbreviation for the adjective "cryptographic", or for the nouns "cryptography" or "cryptographic component".
2. （d）小文字では、「暗号」は形容詞「暗号化」、または名詞「暗号化」または「暗号構成要素」の略語である。
Deprecated Abbreviation: IDOCs SHOULD NOT use this abbreviation because it could easily be misunderstood in some technical sense.
廃止予定の略語：IDocは、この略語を使用することはできません。
3. (O) /U.S. Government/ In upper case, "CRYPTO" is a marking or designator that identifies "COMSEC keying material used to secure or authenticate telecommunications carrying classified or sensitive U.S. Government or U.S. Government-derived information." [C4009] (See: security label, security marking.)
3. （O）/U.S。政府/大文字で、「暗号」は、「分類されたまたは敏感な米国政府または米国政府の派生情報を運ぶ電気通信を保護または認証するために使用されるCOMSECキーイング材料」を識別するマーキングまたは指定者です。[C4009]（セキュリティラベル、セキュリティマーキングを参照）
$ cryptographic (I) An adjective that refers to cryptography.
$ 暗号化（i）暗号化を指す形容詞。
$ cryptographic algorithm (I) An algorithm that uses the science of cryptography, including (a) encryption algorithms, (b) cryptographic hash algorithms, (c) digital signature algorithms, and (d) key-agreement algorithms.
$ 暗号化アルゴリズム（i）（a）暗号化アルゴリズム、（b）暗号化ハッシュアルゴリズム、（c）デジタル署名アルゴリズム、および（d）鍵合意アルゴリズムを含む暗号化の科学を使用するアルゴリズム。
$ cryptographic application programming interface (CAPI) (I) The source code formats and procedures through which an application program accesses cryptographic services, which are defined abstractly compared to their actual implementation. Example, see: PKCS #11, [R2628].
$ 暗号化アプリケーションプログラミングインタフェース（CAPI）（i）アプリケーションプログラムが暗号化サービスにアクセスするソースコードフォーマットと手順は、実際の実装と比較されます。例、PKCS＃11、[R2628]を参照してください。
$ cryptographic association (I) A security association that involves the use of cryptography to provide security services for data exchanged by the associated entities. (See: ISAKMP.)
$ 暗号化協会（i）関連するエンティティによって交換されるデータのためにセキュリティサービスを提供するための暗号化の使用を含むセキュリティ協会。（参照：ISAKMP）
$ cryptographic boundary (I) See: secondary definition under "cryptographic module".
$ 暗号化境界（i）「暗号化モジュール」の下の二次定義。
$ cryptographic card (I) A cryptographic token in the form of a smart card or a PC card.
$ 暗号化カード（i）スマートカードまたはPCカードの形式の暗号化トークン。
$ cryptographic component (I) A generic term for any system component that involves cryptography. (See: cryptographic module.)
$ 暗号化コンポーネント（i）暗号化を含むシステムコンポーネントの一般的な用語。（暗号モジュールを参照してください。）
$ cryptographic hash (I) See: secondary definition under "hash function".
$ 暗号化ハッシュ（I）「ハッシュ関数」の下のセカンダリ定義。
$ cryptographic ignition key (CIK) 1. (N) A physical (usually electronic) token used to store, transport, and protect cryptographic keys and activation data. (Compare: dongle, fill device.)
$ 暗号化イグニッションキー（CIK）1.（n）暗号鍵と起動データを保存、転送、保護するために使用される物理的（通常は電子）トークン。（比較：ドングル、塗りつぶし装置）
Tutorial: A key-encrypting key could be divided (see: split key) between a CIK and a cryptographic module, so that it would be necessary to combine the two to regenerate the key, use it to decrypt other keys and data contained in the module, and thus activate the module.
チュートリアル：キー暗号化キーをCIKと暗号化モジュールの間で分割することができます（スプリットキーを参照）、キーを再生成するために2つを組み合わせることが必要です。モジュール、したがってモジュールを有効にします。
2. (O) "Device or electronic key used to unlock the secure mode of cryptographic equipment." [C4009] Usage: Abbreviated as "crypto-ignition key".
2. （o）「セキュアモードの解除装置のロックを解除するための装置または電子キー」[C4009]使用法：「暗号イグニッションキー」と省略されています。
$ cryptographic key (I) See: key. Usage: Usually shortened to just "key".
$ 暗号化キー（i）キー：キーを参照してください。使用法：通常「キー」だけ短縮されています。
$ Cryptographic Message Syntax (CMS) (I) An encapsulation syntax (RFC 3852) for digital signatures, hashes, and encryption of arbitrary messages.
$ 暗号化メッセージ構文（CMS）（i）任意のメッセージのデジタル署名、ハッシュ、および暗号化のためのカプセル化構文（RFC 3852）。
Tutorial: CMS derives from PKCS #7. CMS values are specified with ASN.1 and use BER encoding. The syntax permits multiple encapsulation with nesting, permits arbitrary attributes to be signed along with message content, and supports a variety of architectures for digital certificate-based key management.
チュートリアル：CMSはPKCS＃7から派生します。CMS値はASN.1で指定され、BERエンコーディングを使用します。構文は、ネスト付きの複数のカプセル化を許可し、任意の属性をメッセージコンテンツと一緒に署名することを許可し、デジタル証明書ベースの鍵管理のためのさまざまなアーキテクチャをサポートします。
$ cryptographic module (I) A set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the module's "cryptographic boundary", which is an explicitly defined contiguous perimeter that establishes the physical bounds of the module. [FP140]
$ 暗号化モジュール（i）暗号化アルゴリズムを含む暗号化ロジックまたはプロセスを実装するモジュールの「暗号境界」内に含まれるハードウェア、ソフトウェア、ファームウェア、またはそのいくつかの組み合わせのセット。モジュールの物理的境界[FP140]
$ cryptographic system 1. (I) A set of cryptographic algorithms together with the key management processes that support use of the algorithms in some application context.
$ 暗号化システム1.（i）一部のアプリケーションコンテキストにおけるアルゴリズムの使用をサポートする鍵管理プロセスとともに、一連の暗号化アルゴリズム。
Usage: IDOCs SHOULD use definition 1 because it covers a wider range of algorithms than definition 2.
使用法：IDOCは定義2よりも広い範囲のアルゴリズムをカバーするため、定義1を使用する必要があります。
2. (O) "A collection of transformations from plain text into cipher text and vice versa [which would exclude digital signature, cryptographic hash, and key-agreement algorithms], the particular transformation(s) to be used being selected by keys. The transformations are normally defined by a mathematical algorithm." [X509]
2. （O） "プレーンテキストから暗号テキストへの変換の集まり、およびその逆の間で、デジタル署名、暗号化ハッシュ、およびキー契約アルゴリズムを除外することができ、使用される特定の変換はキーによって選択されます。変換通常、数学的アルゴリズムによって定義されます。」[X509]
$ cryptographic token 1. (I) A portable, user-controlled, physical device (e.g., smart card or PCMCIA card) used to store cryptographic information and possibly also perform cryptographic functions. (See: cryptographic card, token.)
$ 暗号化トークン1.（i）暗号情報を格納し、おそらく暗号機能を実行するために使用されるポータブル、ユーザ制御、物理デバイス（例えばスマートカードまたはPCMCIAカード）。（参照：暗号カード、トークン。）
Tutorial: A smart token might implement some set of cryptographic algorithms and might incorporate related key management functions, such as a random number generator. A smart cryptographic token may contain a cryptographic module or may not be explicitly designed that way.
チュートリアル：スマートトークンはいくつかの暗号化アルゴリズムを実装し、乱数発生器などの関連キー管理機能を組み込んでいる可能性があります。Smart暗号化トークンには暗号化モジュールを含めることができ、あるいは明示的にその方法で設計されていない可能性があります。
$ cryptography 1. (I) The mathematical science that deals with transforming data to render its meaning unintelligible (i.e., to hide its semantic content), prevent its undetected alteration, or prevent its unauthorized use. If the transformation is reversible, cryptography also deals with restoring encrypted data to intelligible form. (See: cryptology, steganography.)
$ 暗号化1.（i）その意味を意味することを意味する（すなわち、その意味コンテンツを隠すために）、データを変換するための数学的科学（すなわち、その意味コンテンツを隠すために）、検出されない変更を防止するか、またはその不正な使用を防止する。変換が可逆的である場合、暗号化データの復元にかなりの暗号化されたデータの復元にも対処します。（：クリプトロジー、ステガノグラフィ。）
2. (O) "The discipline which embodies principles, means, and
methods for the transformation of data in order to hide its
information content, prevent its undetected modification and/or
prevent its unauthorized use.... Cryptography determines the
methods used in encipherment and decipherment." [I7498-2]
Tutorial: Comprehensive coverage of applied cryptographic protocols and algorithms is provided by Schneier [Schn]. Businesses and governments use cryptography to make data incomprehensible to outsiders; to make data incomprehensible to both outsiders and insiders, the data is sent to lawyers for a rewrite.
チュートリアル：適用された暗号プロトコルとアルゴリズムの包括的なカバレッジは、シュナエのSchnier [Schn]によって提供されています。企業と政府は、暗号化を使用して、データを部外者に理解できないようにします。データを部外者とインサイダーの両方に理解できるようにするために、データは書き換えのための弁護士に送られます。
$ Cryptoki (N) A CAPI defined in PKCS #11. Pronunciation: "CRYPTO-key". Derivation: Abbreviation of "cryptographic token interface".
$ Cryptoki（n）PKCS＃11で定義されているCAPI。発音： "crypto-key"。派生：「暗号トークンインタフェース」の略語。
$ cryptology (I) The science of secret communication, which includes both cryptography and cryptanalysis.
$ 暗号学（i）暗号化と暗号解読の両方を含む秘密通信の科学。
Tutorial: Sometimes the term is used more broadly to denote activity that includes both rendering signals secure (see: signal security) and extracting information from signals (see: signal intelligence) [Kahn].
チュートリアル：レンダリングシグナルをセキュリティ（シグナルセキュリティを参照）を含むアクティビティを表し、シグナルから情報を抽出するアクティビティを示すために、用語はより広く使用され、シグナルからの情報を抽出する（SEMORD Intelligence）[KAHN]。
$ cryptonet (I) A network (i.e., a communicating set) of system entities that share a secret cryptographic key for a symmetric algorithm. (See: controlling authority.)
$ 暗号設定（i）対称アルゴリズムのための秘密暗号鍵を共有するシステムエンティティのネットワーク（すなわち通信セット）。（官能管理を参照してください。）
(O) "Stations holding a common key." [C4009]
（O）「共通のキーを保持しているステーション」[C4009]
$ cryptoperiod (I) The time span during which a particular key value is authorized to be used in a cryptographic system. (See: key management.)
$ cryptoperiod（i）特定のキー値が暗号システムで使用されることを許可されている期間。（：鍵管理を参照してください。）
Usage: This term is long-established in COMPUSEC usage. In the context of certificates and public keys, "key lifetime" and "validity period" are often used instead.
使用法：この用語はCompusecの使用法で長く確立されています。証明書と公開鍵の文脈では、代わりに「鍵の有効期間」と「有効期間」がよく使用されます。
Tutorial: A cryptoperiod is usually stated in terms of calendar or clock time, but sometimes is stated in terms of the maximum amount of data permitted to be processed by a cryptographic algorithm using the key. Specifying a cryptoperiod involves a tradeoff between the cost of rekeying and the risk of successful cryptoanalysis.
チュートリアル：Cryptoperiodは通常、カレンダーまたは時刻の観点から述べられていますが、キーを使用して暗号化アルゴリズムによって処理されることが許可されている最大データ量の観点から述べられています。暗号化合理を指定することは、生後のコストと暗号分析が成功したリスクとの間のトレードオフを含みます。
$ cryptosystem (I) Contraction of "cryptographic system".
$ 暗号システム（I）「暗号システム」の縮小。
$ cryptovariable (D) Synonym for "key".
$ cryptovariable（d）「キー」の同義語。
Deprecated Usage: In contemporary COMSEC usage, the term "key" has replaced the term "cryptovariable".
廃止予定の使用法：現代的なCOMSECの使用法では、「キー」という用語は「暗号可否」という用語を置き換えました。
$ CSIRT (I) See: computer security incident response team.
$ CSIRT（i）コンピュータセキュリティインシデント応答チームを参照してください。
$ CSOR (N) See: Computer Security Objects Register.
$ CSOR（N）：コンピュータセキュリティオブジェクトレジスタを参照してください。
$ CTAK (D) See: ciphertext auto-key.
$ CTAK（D）CipherTextオートキーを参照してください。
$ CTR (N) See: counter mode.
$ CTR（N）カウンタモードを参照してください。
$ cut-and-paste attack (I) An active attack on the data integrity of cipher text, effected by replacing sections of cipher text with other cipher text, such that the result appears to decrypt correctly but actually decrypts to plain text that is forged to the satisfaction of the attacker.
$ カットアンドペースト攻撃（i）暗号テキストのセクションを他の暗号テキストと置き換えることによって実行される暗号テキストのデータ整合性に対する積極的な攻撃は、結果が正しく復号化されているが実際には偽造されたプレーンテキストに復号化されるように行われる。攻撃者の満足度
$ cyclic redundancy check (CRC) (I) A type of checksum algorithm that is not a cryptographic hash but is used to implement data integrity service where accidental changes to data are expected. Sometimes called "cyclic redundancy code".
$ 巡回冗長検査（CRC）（i）暗号化ハッシュではないが、データへの誤った変更が予想されるデータ整合性サービスを実装するために使用されるチェックサムアルゴリズムの一種。「巡回冗長コード」と呼ばれることもあります。
$ DAC (N) See: Data Authentication Code, discretionary access control.
$ DAC（N）データ認証コード、任意アクセス制御を参照してください。
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because this abbreviation is ambiguous.
廃止予定の使用法：この用語を使用するIDocは、この略語があいまいであるため、定義を定義します。
$ daemon (I) A computer program that is not invoked explicitly but waits until a specified condition occurs, and then runs with no associated user (principal), usually for an administrative purpose. (See: zombie.)
$ デーモン（i）明示的に呼び出されないが、指定された状態が発生するまで待機してから、通常管理目的のために、関連付けられていないユーザ（プリンシパル）で実行されます。（ゾンビを参照してください。）
$ dangling threat (O) A threat to a system for which there is no corresponding vulnerability and, therefore, no implied risk.
$ Dangling Threat（o）対応する脆弱性がないシステムへの脅威、したがって、黙示的なリスクはありません。
$ dangling vulnerability (O) A vulnerability of a system for which there is no corresponding threat and, therefore, no implied risk.
$ ダングリングの脆弱性（O）対応する脅威がないシステムの脆弱性、したがって、暗黙のリスクはありません。
$ DASS (I) See: Distributed Authentication Security Service.
$ Dass（i）分散認証セキュリティサービスを参照してください。
$ data (I) Information in a specific representation, usually as a sequence of symbols that have meaning.
$ データ（i）特定の表現内の情報は、通常意味を持つシンボルのシンボルとしての情報です。
Usage: Refers to both (a) representations that can be recognized, processed, or produced by a computer or other type of machine, and (b) representations that can be handled by a human.
使用法：コンピュータまたは他の種類の機械によって認識、処理、または製造することができる両方の表現、および（B）人間によって処理することができる表現を指す。
$ Data Authentication Algorithm, data authentication algorithm 1. (N) /capitalized/ The ANSI standard for a keyed hash function that is equivalent to DES cipher block chaining with IV = 0. [A9009]
$ データ認証アルゴリズム、データ認証アルゴリズム1.（N）/大文字/ ANSI規格IV = 0でのDES暗号ブロック連鎖と同等のキー付きハッシュ関数のANSI規格。[A9009]
2. (D) /not capitalized/ Synonym for some kind of "checksum".
2. （d）/資本化/匿名のある種の「チェックサム」に。
Deprecated Term: IDOCs SHOULD NOT use the uncapitalized form "data authentication algorithm" as a synonym for any kind of checksum, regardless of whether or not the checksum is based on a hash. Instead, use "checksum", "Data Authentication Code", "error detection code", "hash", "keyed hash", "Message Authentication Code", "protected checksum", or some other specific term, depending on what is meant.
廃止予定語：チェックサムがハッシュに基づいているかどうかにかかわらず、IDOCは、あらゆる種類のチェックサムの同義語として、あらゆる種類のチェックサムの同義語として使用しないでください。代わりに、「チェックサム」、「データ認証コード」、「エラー検出コード」、「HASH」、「キー付きハッシュ」、「メッセージ認証コード」、「保護チェックサム」、またはその他の特定の用語を使用しています。。
The uncapitalized term can be confused with the Data Authentication Code and also mixes concepts in a potentially misleading way. The word "authentication" is misleading because the checksum may be used to perform a data integrity function rather than a data origin authentication function.
不安定な用語はデータ認証コードと混同することができ、潜在的に誤解を招くような方法で概念を混合することもできます。チェックサムを使用してデータの原点認証機能ではなくデータ整合性機能を実行できるため、「認証」という単語が誤解を招くことです。
$ Data Authentication Code, data authentication code 1. (N) /capitalized/ A specific U.S. Government standard [FP113] for a checksum that is computed by the Data Authentication Algorithm. Usage: a.k.a. Message Authentication Code [A9009].) (See: DAC.)
$ データ認証アルゴリズムによって計算されるチェックサムのためのデータ認証コード、データ認証コード1.（N）/資本/政府標準[FP113]。使用法：a.k.a.メッセージ認証コード[A9009]。）（参照：DAC参照）
2. (D) /not capitalized/ Synonym for some kind of "checksum".
2. （d）/資本化/匿名のある種の「チェックサム」に。
Deprecated Term: IDOCs SHOULD NOT use the uncapitalized form "data authentication code" as a synonym for any kind of checksum, regardless of whether or not the checksum is based on the Data Authentication Algorithm. The uncapitalized term can be confused with the Data Authentication Code and also mixes concepts in a potentially misleading way (see: authentication code).
廃止予定語：IDOCは、チェックサムがデータ認証アルゴリズムに基づくかどうかにかかわらず、あらゆる種類のチェックサムの同義語として、あらゆる種類のチェックサムの同義語として使用しないでください。不安定な用語はデータ認証コードと混同することができ、また潜在的に誤解を招くような方法で概念を混合する（認証コードを参照）。
$ data compromise 1. (I) A security incident in which information is exposed to potential unauthorized access, such that unauthorized disclosure, alteration, or use of the information might have occurred. (Compare: security compromise, security incident.)
$ データ妥協点1.（i）情報の不正な開示、変更、または使用が発生した可能性があるように、情報の潜在的な不正アクセスに情報が曝されるセキュリティ事件。（比較：セキュリティ妥協、セキュリティインシデント）
2. (O) /U.S. DoD/ A "compromise" is a "communication or physical transfer of information to an unauthorized recipient." [DoD5]
2. （O）/U.S。DOD /「妥協」は、「不正受信者への情報の通信または物理的な転送」です。[DOD5]
3. (O) /U.S. Government/ "Type of [security] incident where information is disclosed to unauthorized individuals or a violation of the security policy of a system in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object may have occurred." [C4009]
3. （O）/U.S。政府/「セキュリティの種類のタイプ」情報が不正な個人に開示されているか、不正な意図的または意図しない開示、修正、破壊、またはオブジェクトの喪失が発生したシステムのセキュリティポリシーの違反が発生した可能性がある。」[C4009]
$ data confidentiality 1. (I) The property that data is not disclosed to system entities unless they have been authorized to know the data. (See: Bell-LaPadula model, classification, data confidentiality service, secret. Compare: privacy.)
$ データ機密性1.（i）データを知る権限がない限り、データがシステムエンティティに開示されていないプロパティ。（鐘ラパドゥラモデル、分類、データ機密保持サービス、秘密。比較：プライバシーを比較してください。）
2. (D) "The property that information is not made available or disclosed to unauthorized individuals, entities, or processes [i.e., to any unauthorized system entity]." [I7498-2].
2. （d） "情報が許可されていない個人、エンティティ、またはプロセス[すなわち許可されていないシステムエンティティ]に開示されていないプロパティ。」[I7498-2]。
Deprecated Definition: The phrase "made available" might be interpreted to mean that the data could be altered, and that would confuse this term with the concept of "data integrity".
廃止予定の定義：「使用可能な」というフレーズは、データが変更される可能性があることを意味すると解釈される可能性があり、それはこの用語を「データ整合性」の概念で混同します。
$ data confidentiality service (I) A security service that protects data against unauthorized disclosure. (See: access control, data confidentiality, datagram confidentiality service, flow control, inference control.)
$ データ機密保持サービス（i）不正な開示からデータを保護するセキュリティサービス。（アクセス制御、データ機密性、データグラム機密保持サービス、フロー制御、推論制御）
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for "privacy", which is a different concept.
廃止予定の使用法：IDOCは、この用語を「プライバシー」の同義語として使用しないでください。これは異なる概念です。
$ Data Encryption Algorithm (DEA) (N) A symmetric block cipher, defined in the U.S. Government's DES. DEA uses a 64-bit key, of which 56 bits are independently chosen and 8 are parity bits, and maps a 64-bit block into another 64-bit block. [FP046] (See: AES, symmetric cryptography.)
$ データ暗号化アルゴリズム（DEA）（n）米国政府のDESで定義された対称ブロック暗号。DEAは64ビット鍵を使用し、そのうち56ビットが独立して選択され、8はパリティビットであり、64ビットブロックを別の64ビットブロックにマッピングします。[FP046]（AES、対称暗号化を参照）
Usage: This algorithm is usually referred to as "DES". The algorithm has also been adopted in standards outside the Government (e.g., [A3092]).
使用法：このアルゴリズムは通常「DES」と呼ばれます。アルゴリズムは政府外の規格にも採用されています（例えば、[A3092]）。
$ data encryption key (DEK) (I) A cryptographic key that is used to encipher application data. (Compare: key-encrypting key.)
$ データ暗号化キー（DEK）（i）アプリケーションデータを暗号化するために使用される暗号鍵。（Compare：キー暗号化キー。）
$ Data Encryption Standard (DES) (N) A U.S. Government standard [FP046] that specifies the DEA and states policy for using the algorithm to protect unclassified, sensitive data. (See: AES.)
$ データ暗号化標準（DES）（N）us.政府標準[FP046]は、未分類の機密データを保護するためのアルゴリズムを使用するためのDEAと状態のポリシーを指定します。（参照：AES。）
$ data integrity 1. (I) The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. (See: data integrity service. Compare: correctness integrity, source integrity.)
$ データの整合性1.（i）不正または偶発的な方法でデータが変更されていない、破壊された、または失われたプロパティ。（Data Integrity Serviceを参照してください。比較：正当性の整合性、ソースの整合性。）
2. (O) "The property that information has not been modified or destroyed in an unauthorized manner." [I7498-2]
2. （O）「情報が不正な方法で変更または破壊されていないという財産」[I7498-2]
Usage: Deals with (a) constancy of and confidence in data values, and not with either (b) information that the values represent (see: correctness integrity) or (c) the trustworthiness of the source of the values (see: source integrity).
使用法：（a）データ値の確信と自信を扱い、値が表す（正確性の整合性を参照）、または値の原因の信頼性を表す（b）情報ではありません（SOUEM INTERITITYを参照）。）。
$ data integrity service (I) A security service that protects against unauthorized changes to data, including both intentional change or destruction and accidental change or loss, by ensuring that changes to data are detectable. (See: data integrity, checksum, datagram integrity service.)
$ データ整合性サービス（i）データへの変更が検出されることを確実にすることで、意図的な変更や破壊や破壊や損失の両方を含め、データへの不正な変更から保護するセキュリティサービス。（Data Integrity、CheckSum、データグラムの整合性サービスを参照してください。）
Tutorial: A data integrity service can only detect a change and report it to an appropriate system entity; changes cannot be prevented unless the system is perfect (error-free) and no malicious user has access. However, a system that offers data integrity service might also attempt to correct and recover from changes.
チュートリアル：Data Integrityサービスは変更を検出し、それを適切なシステムエンティティに報告することしかできません。システムが完全でない限り、変更を防ぐことはできず、悪意のあるユーザーがアクセスできません。ただし、Data Integrityサービスを提供するシステムは、変更から修正および回復を試みる可能性があります。
The ability of this service to detect changes is limited by the technology of the mechanisms used to implement the service. For example, if the mechanism were a one-bit parity check across each entire SDU, then changes to an odd number of bits in an SDU would be detected, but changes to an even number of bits would not.
このサービスの変更を検出する能力は、サービスを実装するために使用されるメカニズムの技術によって制限されます。たとえば、メカニズムが各SDU全体にわたって1ビットパリティチェックである場合、SDU内の奇数ビット数の変更が検出されますが、偶数ビットに変更されません。
Relationship between data integrity service and authentication services: Although data integrity service is defined separately from data origin authentication service and peer entity authentication service, it is closely related to them. Authentication services depend, by definition, on companion data integrity services. Data origin authentication service provides verification that the identity of the original source of a received data unit is as claimed; there can be no such verification if the data unit has been altered. Peer entity authentication service provides verification that the identity of a peer entity in a current association is as claimed; there can be no such verification if the claimed identity has been altered.
データインテグリティサービスと認証サービスの関係：Data Integrity Serviceはデータオリジナル認証サービスとピアエンティティ認証サービスとは別に定義されていますが、それはそれらに密接に関連しています。認証サービスは、定義によってCompanion Data Integrity Servicesで依存します。データオリジナル認証サービスは、受信データユニットの元のソースの識別情報が主張されていることを確認する。データユニットが変更された場合、そのような検証はできません。ピアエンティティ認証サービスは、現在の関連付けにおけるピアエンティティの識別情報が主張されているという検証を提供する。クレームされたアイデンティティが変更されている場合は、そのような検証はできません。
$ data origin authentication (I) "The corroboration that the source of data received is as claimed." [I7498-2] (See: authentication.)
$ データ発信元認証（i）「受信元のデータのソースがクレームされたところであるというコラボレーション」[I7498-2]（認証を参照）
$ data origin authentication service (I) A security service that verifies the identity of a system entity that is claimed to be the original source of received data. (See: authentication, authentication service.)
$ データ発信認証サービス（i）受信データの元のソースであると主張されているシステムエンティティの識別情報を検証するセキュリティサービス。（検知、認証サービスを参照してください。）
Tutorial: This service is provided to any system entity that receives or holds the data. Unlike peer entity authentication service, this service is independent of any association between the originator and the recipient, and the data in question may have originated at any time in the past.
チュートリアル：このサービスは、データを受信または保持するシステムエンティティに提供されています。ピアエンティティ認証サービスとは異なり、このサービスは発信者と受信者との間の関連付けとは無関係であり、問題のデータは過去にいつでも発信された可能性があります。
A digital signature mechanism can be used to provide this service, because someone who does not know the private key cannot forge the correct signature. However, by using the signer's public key, anyone can verify the origin of correctly signed data.
秘密鍵が正しい署名を築くことができない誰かがこのサービスを提供するためにデジタル署名メカニズムを使用することができます。ただし、署名者の公開鍵を使用することで、誰でも正しく署名されたデータの原点を検証できます。
This service is usually bundled with connectionless data integrity service. (See: "relationship between data integrity service and authentication services" under "data integrity service".
このサービスは通常、ConnectionLess Data Integrityサービスにバンドルされています。（Data Integrity Serviceの「データ整合性サービスと認証サービスの関係」を参照してください。
$ data owner (N) The organization that has the final statutory and operational authority for specified information.
$ データ所有者（n）指定された情報に対して最終的な法定および運用上の権限を持つ組織。
$ data privacy (D) Synonym for "data confidentiality".
$ データのプライバシー（D）「データ機密性」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts in a potentially misleading way. Instead, use either "data confidentiality" or "privacy" or both, depending on what is meant.
廃止予定語：IDocsはこの用語を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。代わりに、何をしているものに応じて、「データ機密性」または「プライバシー」またはその両方を使用してください。
$ data recovery 1. (I) /cryptanalysis/ A process for learning, from some cipher text, the plain text that was previously encrypted to produce the cipher text. (See: recovery.) 2. (I) /system integrity/ The process of restoring information following damage or destruction.
$ Data Recovery 1.（i）/暗号解読/学習のためのプロセス、いくつかの暗号テキストから、以前暗号化されたプレーンテキストは暗号テキストを生成しました。（回復を参照してください。）2。（i）/システムの整合性/損傷や破壊後の情報を復元するプロセス。
$ data security (I) The protection of data from disclosure, alteration, destruction, or loss that either is accidental or is intentional but unauthorized.
$ データセキュリティ（i）偶発的であるか意図的ではないが不正である、開示、変更、破壊、または損失からのデータの保護。
Tutorial: Both data confidentiality service and data integrity service are needed to achieve data security.
チュートリアル：データのセキュリティを実現するために、データ機密保持サービスとデータ整合性サービスの両方が必要です。
$ datagram (I) "A self-contained, independent entity of data [i.e., a packet] carrying sufficient information to be routed from the source [computer] to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network." [R1983] Example: A PDU of IP.
$ データグラム（i） "は、この送信元と宛先コンピュータと輸送との間の以前の交換に頼ることなく、ソース[コンピュータ]から宛先コンピュータにルーティングするのに十分な情報を運ぶことで、自己完結型の独立したデータ[すなわちパケット]通信網。"[R1983]例：IPのPDU。
$ datagram confidentiality service (I) A data confidentiality service that preserves the confidentiality of data in a single, independent, packet; i.e., the service applies to datagrams one-at-a-time. Example: ESP. (See: data confidentiality.)
$ データグラム機密保持サービス（i）単一の独立したパケットでデータの機密性を保持するデータ機密保持サービス。すなわち、サービスはデータグラムを1回ずつ時間に適用する。例：ESP。（データ機密性を参照してください。）
Usage: When a protocol is said to provide data confidentiality service, this is usually understood to mean that only the SDU is protected in each packet. IDOCs that use the term to mean that the entire PDU is protected should include a highlighted definition.
使用法：プロトコルがデータ機密保持サービスを提供すると言われると、これは通常、SDUのみが各パケットで保護されていることを意味すると理解されます。PDU全体が保護されていることを意味するという用語を使用するIDocは、強調表示された定義を含むべきです。
Tutorial: This basic form of network confidentiality service suffices for protecting the data in a stream of packets in both connectionless and connection-oriented protocols. Except perhaps for traffic flow confidentiality, nothing further is needed to protect the confidentiality of data carried by a packet stream. The OSIRM distinguishes between connection confidentiality and connectionless confidentiality. The IPS need not make that distinction, because those services are just instances of the same service (i.e., datagram confidentiality) being offered in two different protocol contexts. (For data integrity service, however, additional effort is needed to protect a stream, and the IPS does need to distinguish between "datagram integrity service" and "stream integrity service".)
チュートリアル：ネットワーク機密保持サービスのこの基本的な形式は、コネクションレスおよび接続指向プロトコルの両方のパケットのストリーム内のデータを保護するのに十分です。おそらく、トラフィックフロー機密性のために、パケットストリームによって運ばれるデータの機密性を保護するためにさらに必要とされない。OSERRは接続機密性とコネクションのない機密性を区別します。これらのサービスは、2つの異なるプロトコルコンテキストで提供されているのと同じサービスのインスタンス（すなわち、データグラム機密性）のインスタンスであるため、IPSはその区別を行う必要はありません。（Data Integrityサービスの場合、ストリームを保護するために追加の努力が必要であり、IPは「データグラム整合性サービス」と「Stream Integrity Service」を区別する必要があります。）
$ datagram integrity service (I) A data integrity service that preserves the integrity of data in a single, independent, packet; i.e., the service applies to datagrams one-at-a-time. (See: data integrity. Compare: stream integrity service.) Tutorial: The ability to provide appropriate data integrity is important in many Internet security situations, and so there are different kinds of data integrity services suited to different applications. This service is the simplest kind; it is suitable for connectionless data transfers.
$ Datagram Integrity Service（i）単一の独立したパケット内のデータの整合性を保持するData Integrityサービス。すなわち、サービスはデータグラムを1回ずつ時間に適用する。（Compare：Stream Integrity Service。）チュートリアル：多くのインターネットセキュリティの状況では、適切なデータの整合性を提供する機能が重要です。したがって、さまざまなアプリケーションに適したさまざまな種類のデータ整合性サービスがあります。このサービスは最も簡単な種類です。コネクションレスデータ転送に適しています。
Datagram integrity service usually is designed only to attempt to detect changes to the SDU in each packet, but it might also attempt to detect changes to some or all of the PCI in each packet (see: selective field integrity). In contrast to this simple, one-at-a-time service, some security situations demand a more complex service that also attempts to detect deleted, inserted, or reordered datagrams within a stream of datagrams (see: stream integrity service).
データグラムIntegrity Serviceは通常、各パケットのSDUへの変更を検出するのにのみ設計されていますが、各パケットのPCIの一部または全部に対する変更を検出しようとする可能性があります（Selective Field Integrityを参照）。この単純で1回の時間のあるサービスとは対照的に、いくつかのセキュリティ状況は、データグラムのストリーム内の削除、挿入、または並べ替えられたデータグラムを検出しようとするより複雑なサービスを要求します（Stream Integrity Serviceを参照）。
$ DEA (N) See: Data Encryption Algorithm.
$ DEA（N）データ暗号化アルゴリズムを参照してください。
$ deception (I) A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. (See: authentication.)
$ 詐欺（i）誤った企業が誤ったデータを受信し、それを真実であると信じることがある状況またはイベント。（認証を参照してください。）
Tutorial: This is a type of threat consequence, and it can be caused by the following types of threat actions: masquerade, falsification, and repudiation.
チュートリアル：これは脅威の影響の一種であり、それは以下の種類の脅威の行動によって引き起こされる可能性があります：不振、改ざん
$ decipher (D) Synonym for "decrypt".
$ 「復号化」の辞書（D）の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "decrypt". However, see usage note under "encryption".
非推奨の定義：IDocは、この用語を「復号化」の同義語として使用しないでください。ただし、「暗号化」の「使用上の注意」を参照してください。
$ decipherment (D) Synonym for "decryption".
$ 解読（d）「復号化」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "decryption". However, see the Usage note under "encryption".
非推奨の定義：IDocは、この用語を「復号化」の同義語として使用しないでください。ただし、「暗号化」の「使用上の注意」を参照してください。
$ declassification (I) An authorized process by which information is declassified. (Compare: classification.)
$ 分離解析（i）情報が分析される許可されたプロセス。（比較：分類。）
$ declassify (I) To officially remove the security level designation of a classified information item or information type, such that the information is no longer classified (i.e., becomes unclassified). (See: classified, classify, security level. Compare: downgrade.)
$ （i）、クラシファイされた情報項目または情報タイプのセキュリティレベルの指定を正式に削除すること（すなわち、すなわち、除外されていない）。（分類された、分類、セキュリティレベル。比較：ダウングレード。）
$ decode 1. (I) Convert encoded data back to its original form of representation. (Compare: decrypt.)
$ （i）エンコードされたデータを元の形式の表現に変換します。（比較：復号化。）
2. (D) Synonym for "decrypt".
2. （d）「復号化」の同義語。
Deprecated Definition: Encoding is not usually meant to conceal meaning. Therefore, IDOCs SHOULD NOT use this term as a synonym for "decrypt", because that would mix concepts in a potentially misleading way.
非推奨の定義：エンコードは通常意味を隠すことを意味していません。したがって、IDocは「復号化」の同義語としてこの用語を使用しないでください。
$ decrypt (I) Cryptographically restore cipher text to the plaintext form it had before encryption.
$ 復号化（i）暗号化前に暗号化された文書を暗号化したフォームに暗号化させて暗号化します。
$ decryption (I) See: secondary definition under "encryption".
$ 復号化（i）「暗号化」の下の2次定義を参照してください。
$ dedicated security mode (I) A mode of system operation wherein all users having access to the system possess, for all data handled by the system, both (a) all necessary authorizations (i.e., security clearance and formal access approval) and (b) a need-to-know. (See: /system operation/ under "mode", formal access approval, need to know, protection level, security clearance.)
$ 専用のセキュリティモード（i）システムによって処理されているすべてのデータがすべて（a）必要なすべての権限（すなわち、セキュリティクリアランスとフォーマルアクセス承認）と（B）の両方を所有しているシステム操作のモード。知っている必要があります。（/システム操作/「モード」の「モード」、正式なアクセス承認、知っている、保護レベル、セキュリティクリアランス。）
Usage: Usually abbreviated as "dedicated mode". This mode was defined in U.S. Government policy on system accreditation, but the term is also used outside the Government. In this mode, the system may handle either (a) a single classification level or category of information or (b) a range of levels and categories.
使用法：通常「専用モード」と省略されています。このモードはシステム認定に関する米国政府政策において定義されたが、この用語は政府外でも使用されている。このモードでは、システムは（a）単一の分類レベルまたは情報のカテゴリまたは（b）レベルとカテゴリのどちらかを処理することができます。
$ default account (I) A system login account (usually accessed with a user identifier and password) that has been predefined in a manufactured system to permit initial access when the system is first put into service. (See: harden.)
$ デフォルトアカウント（i）システムが最初にサービスに入れられたときに初期アクセスを許可するために製造されたシステムで事前定義されたシステムログインアカウント（通常はユーザー識別子とパスワードでアクセスされます）。（硬化を参照してください。）
Tutorial: A default account becomes a serious vulnerability if not properly administered. Sometimes, the default identifier and password are well-known because they are the same in each copy of the system. In any case, when a system is put into service, any default password should immediately be changed or the default account should be disabled.
チュートリアル：正しく管理されていない場合、デフォルトアカウントは重大な脆弱性になります。時々、デフォルトの識別子とパスワードはシステムの各コピーで同じであるため、よく知られています。いずれにせよ、システムがサービスに入れると、すぐにデフォルトのパスワードを変更するか、デフォルトのアカウントを無効にする必要があります。
$ defense in depth (N) "The siting of mutually supporting defense positions designed to absorb and progressively weaken attack, prevent initial observations of the whole position by the enemy, and [enable] the commander to maneuver the reserve." [JP1]
深さ（N）の$ DEFESING（N） "攻撃を吸収して漸進的に吸収するように設計された相互に支持する防御ポジションの立地は、敵による位置全体の最初の観察を防ぎ、司令官が予約を操作することを防ぎます。」[JP1]
Tutorial: In information systems, defense in depth means constructing a system's security architecture with layered and complementary security mechanisms and countermeasures, so that if one security mechanism is defeated, one or more other mechanisms (which are "behind" or "beneath" the first mechanism) still provide protection.
チュートリアル：情報システムでは、深さの防衛とは、1つ以上のセキュリティメカニズムが敗北した場合、1つ以上のその他のメカニズム（これは「背後に」または「下に」または「その下」を除いて、システムのセキュリティアーキテクチャと対策を構築することを意味します。メカニズム）はまだ保護を提供します。
This architectural concept is appealing because it aligns with traditional warfare doctrine, which applies defense in depth to physical, geospatial structures; but applying the concept to logical, cyberspace structures of computer networks is more difficult. The concept assumes that networks have a spatial or topological representation. It also assumes that there can be implemented -- from the "outer perimeter" of a network, through its various "layers" of components, to its "center" (i.e., to the subscriber application systems supported by the network) -- a varied series of countermeasures that together provide adequate protection. However, it is more difficult to map the topology of networks and make certain that no path exists by which an attacker could bypass all defensive layers.
この建築の概念は伝統的な戦争の教義と整列しているので、肉体的な地理的建造物に深さを守る伝統的な戦争の教義と一致しているので魅力的です。しかし、コンピュータネットワークの論理的なサイバースペース構造に概念を適用することはより困難です。この概念は、ネットワークが空間的または位相的表現を有すると仮定している。また、ネットワークの「外周」から構成されているコンポーネントの様々な「層」を介して（すなわち、ネットワークによってサポートされている加入者アプリケーションシステムに）実装可能であると仮定する - A一緒に適切な保護を提供する様々な対策のさまざまな対策。しかしながら、ネットワークのトポロジをマッピングし、攻撃者がすべての防御レイヤーを迂回することができる経路が存在しないことを確実にすることはより困難である。
$ Defense Information Infrastructure (DII) (O) /U.S. DoD/ The U.S. DoD's shared, interconnected system of computers, communications, data, applications, security, people, training, and support structures, serving information needs worldwide. (See: DISN.) Usage: Has evolved to be called the GIG.
$ 防衛情報インフラ（DII）（O）/U.S。DOD /米国のDODの共有、相互接続されたコンピュータのシステム、通信、データ、アプリケーション、セキュリティ、人々、トレーニング、およびサポート構造、サービスに提供する情報提供の提供。（DISN。）使用法：GIGと呼ばれることを進化させました。
Tutorial: The DII connects mission support, command and control, and intelligence computers and users through voice, data, imagery, video, and multimedia services, and provides information processing and value-added services to subscribers over the DISN. Users' own data and application software are not considered part of the DII.
チュートリアル：DIIは、音声、データ、画像、ビデオ、およびマルチメディアサービスを通じてミッションサポート、コマンドおよびコントロール、およびユーザーをコネクトし、DISNを介して購読者に情報処理と付加価値サービスを提供します。ユーザー自身のデータとアプリケーションソフトウェアはDIIの一部とは見なされません。
$ Defense Information Systems Network (DISN) (O) /U.S. DoD/ The U.S. DoD's consolidated, worldwide, enterprise level telecommunications infrastructure that provides end-to-end information transfer for supporting military operations; a part of the DII. (Compare: GIG.)
$ 防衛情報システムネットワーク（DISN）（O）/U.S。DOD /米国のDODの連結、世界中で、軍事業務を支援するためのエンドツーエンドの情報転送を提供するインフラストラクチャ。DIIの一部です。（比較：gig。）
$ degauss 1a. (N) Apply a magnetic field to permanently remove data from a magnetic storage medium, such as a tape or disk [NCS25]. (Compare: erase, purge, sanitize.) 1b. (N) Reduce magnetic flux density to zero by applying a reversing magnetic field. (See: magnetic remanence.)
$ DEGAUSS 1A。（n）テープやディスクなどの磁気記憶媒体から恒久的にデータを絶えず除去するための磁界を塗布します[NCS25]。（比較：消去、パージ、サニタイズ。）1b。（n）反転磁場を印加することによって磁束密度をゼロにくくする。（：磁気残留磁気中。）
$ degausser (N) An electrical device that can degauss magnetic storage media.
$ Degausser（n）磁気記憶媒体を脱ガスすることができる電気装置。
$ DEK (I) See: data encryption key.
$ DEK（i）データ暗号化キーを参照してください。
$ delay (I) /packet/ See: secondary definition under "stream integrity service".
$ 遅延（I）/パケット/参照：「Stream Integrity Service」の下のセカンダリ定義。
$ deletion (I) /packet/ See: secondary definition under "stream integrity service".
$ 削除（i）/ packet / see： "Stream Integrity Service"の下のセカンダリ定義。
$ deliberate exposure (I) /threat action/ See: secondary definition under "exposure".
$ 慎重な露出（I）/脅威の処置/参照：「露出」の下の二次定義。
$ delta CRL (I) A partial CRL that only contains entries for certificates that have been revoked since the issuance of a prior, base CRL [X509]. This method can be used to partition CRLs that become too large and unwieldy. (Compare: CRL distribution point.)
$ Delta CRL（i）以前のベースCRL [X509]の発行以降に取り消された証明書のエントリのみを含む部分CRL。この方法は、大きすぎて扱いにくいCRLを分割するために使用できます。（比較：CRL配布ポイント。）
$ demilitarized zone (DMZ) (D) Synonym for "buffer zone".
$ DEMIRITALIATED ZONE（DMZ）（D）「バッファゾーン」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term because it mixes concepts in a potentially misleading way. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：IDOCは潜在的に誤解を招くような方法で概念を混在させるので、この用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ denial of service (I) The prevention of authorized access to a system resource or the delaying of system operations and functions. (See: availability, critical, flooding.)
$ サービス拒否（i）システムリソースへの許可されたアクセスまたはシステム操作と機能の遅延の防止。（：空室状況、批判的、洪水。）
Tutorial: A denial-of-service attack can prevent the normal conduct of business on the Internet. There are four types of solutions to this security problem: - Awareness: Maintaining cognizance of security threats and vulnerabilities. (See: CERT.) - Detection: Finding attacks on end systems and subnetworks. (See: intrusion detection.) - Prevention: Following defensive practices on network-connected systems. (See: [R2827].)
チュートリアル：サービス拒否攻撃は、インターネット上の通常の事業行動を防ぐことができます。このセキュリティ問題には4種類の解決策があります。 - 認識：セキュリティの脅威と脆弱性の認識を維持する。（Sece：CERT。） - 検出：エンドシステムとサブネットワークに関する攻撃の検索（侵入検知を参照してください。） - 防止：ネットワーク接続システムに関する防御的慣行。（参照：[R2827]）
- Response: Reacting effectively when attacks occur. (See: CSIRT, contingency plan.)
- 応答：攻撃が発生したときに効果的に反応する。（参照：CSIRT、緊急時刻計画）
$ DES (N) See: Data Encryption Standard.
$ DES（n）データ暗号化規格を参照してください。
$ designated approving authority (DAA) (O) /U.S. Government/ Synonym for "accreditor".
$ 指定承認局（DAA）（O）/U.S。政府/「accreditor」の同義語。
$ detection (I) See: secondary definition under "security".
$ 検出（i）「セキュリティ」の下の2次定義を参照してください。
$ deterrence (I) See: secondary definition under "security".
$ Deterrence（i）「セキュリティ」の下の2次定義を参照してください。
$ dictionary attack (I) An attack that uses a brute-force technique of successively trying all the words in some large, exhaustive list.
$ 辞書攻撃（i）大規模で徹底的なリストですべての単語を挑戦するブルートフォース技術を使用する攻撃。
Examples: Attack an authentication service by trying all possible passwords. Attack an encryption service by encrypting some known plaintext phrase with all possible keys so that the key for any given encrypted message containing that phrase may be obtained by lookup.
例：すべての可能なパスワードを試して認証サービスを攻撃します。そのフレーズを含む特定の暗号化されたメッセージのキーがルックアップによって取得されるように、すべての可能なキーを使用していくつかの既知のプレーンテキスト句を暗号化することによって暗号化サービスを攻撃します。
$ Diffie-Hellman $ Diffie-Hellman-Merkle (N) A key-agreement algorithm published in 1976 by Whitfield Diffie and Martin Hellman [DH76, R2631].
$ Diffie-Hellman $ diffie-hellman-merkle（n）1976年にWhitfield DiffieとMartin Hellman [DH76、R2631]。
Usage: The algorithm is most often called "Diffie-Hellman". However, in the November 1978 issue of "IEEE Communications Magazine", Hellman wrote that the algorithm "is a public key distribution system, a concept developed by [Ralph C.] Merkle, and hence should be called 'Diffie-Hellman-Merkle' ... to recognize Merkle's equal contribution to the invention of public key cryptography."
使用法：アルゴリズムはほとんどの場合、「Diffie-Hellman」と呼ばれています。しかし、1978年11月の「IEEE Communications Magazine」の号では、[アルゴリズムが公開鍵配布システム、Ralph C.] Merkleによって開発された概念であることを書いた、したがって「diffie-hellman-merkle」と呼ばれるべきです。...公開鍵暗号化の発明へのメルクルの等しい貢献を認識する。」
Tutorial: Diffie-Hellman-Merkle does key establishment, not encryption. However, the key that it produces may be used for encryption, for further key management operations, or for any other cryptography.
チュートリアル：diffie-hellman-merkleは暗号化ではなく重要な確立を行います。しかしながら、それが生成する鍵は、さらなる鍵管理操作のために、または他の任意の暗号化のために暗号化のために使用され得る。
The algorithm is described in [R2631] and [Schn]. In brief, Alice and Bob together pick large integers that satisfy certain mathematical conditions, and then use the integers to each separately compute a public-private key pair. They send each other their public key. Each person uses their own private key and the other person's public key to compute a key, k, that, because of the mathematics of the algorithm, is the same for each of them. Passive wiretapping cannot learn the shared k, because k is not transmitted, and neither are the private keys needed to compute k.
アルゴリズムは[R2631]と[SCHN]に記載されています。簡単に言うと、アリスとボブは一緒になって特定の数学的条件を満たす大きな整数を選んでから、整数をそれぞれ別々に秘密鍵のペアを計算します。彼らはお互いに彼らの公開鍵を送ります。各人は自分の秘密鍵と他人の公開鍵を使用して、アルゴリズムの数学のため、それぞれがそれぞれ同じです。kは送信されないため、パッシブな盗聴は共有kを学ぶことができず、kを計算するのに必要な秘密鍵もそうではありません。
The difficulty of breaking Diffie-Hellman-Merkle is considered to be equal to the difficulty of computing discrete logarithms modulo a large prime. However, without additional mechanisms to authenticate each party to the other, a protocol based on the algorithm may be vulnerable to a man-in-the-middle attack.
Diffie-Hellman-Merkleを破ることの難しさは、離散対数モジュロのコンピューティングの難しさと等しいと考えられています。しかしながら、各当事者を他のパーティを認証するための追加のメカニズムがなくても、アルゴリズムに基づくプロトコルは、中間攻撃に対して脆弱であり得る。
$ digest See: message digest.
$ ダイジェスト：メッセージダイジェスト。
$ digital certificate (I) A certificate document in the form of a digital data object (a data object used by a computer) to which is appended a computed digital signature value that depends on the data object. (See: attribute certificate, public-key certificate.)
$ デジタル証明書（i）データオブジェクトに依存する計算されたデジタル署名値を追加したデジタルデータオブジェクト（コンピュータで使用されるデータオブジェクト）の形式の証明書文書。（属性証明書、公開鍵証明書を参照してください。）
Deprecated Usage: IDOCs SHOULD NOT use this term to refer to a signed CRL or CKL. Although the recommended definition can be interpreted to include other signed items, the security community does not use the term with those meanings.
廃止予定の使用法：IDOCは、この用語を使用して署名付きCRLまたはCKLを参照してください。推奨されている定義は他の署名されたアイテムを含むと解釈される可能性がありますが、セキュリティコミュニティはそれらの意味を持つという用語を使用しません。
$ digital certification (D) Synonym for "certification".
$ デジタル認証（D）「認証」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this definition unless the context is not sufficient to distinguish between digital certification and another kind of certification, in which case it would be better to use "public-key certification" or another phrase that indicates what is being certified.
非推奨の定義：IDocは、デジタル認証と別の種類の認証を区別するのに十分でない限り、IDocsはこの定義を使用しないでください。その場合、「公開鍵認証」または認定されているものを示す別のフレーズを使用することをお勧めします。。
$ digital document (I) An electronic data object that represents information originally written in a non-electronic, non-magnetic medium (usually ink on paper) or is an analogue of a document of that type.
$ デジタル文書（i）非電子非磁性媒体（通常は紙の上のインク）で書かれた情報を表す電子データオブジェクト（通常は紙の上にインク）またはそのタイプの文書のアナログである。
$ digital envelope (I) A combination of (a) encrypted content data (of any kind) intended for a recipient and (b) the content encryption key in an encrypted form that has been prepared for the use of the recipient.
$ デジタルエンベロープ（i）（a）受信者を対象とした暗号化されたコンテンツデータと（b）受信者を使用するために作成された暗号化された形式のコンテンツ暗号化キーの組み合わせ。
Usage: In IDOCs, the term SHOULD be defined at the point of first use because, although the term is defined in PKCS #7 and used in S/MIME, it is not widely known.
使用法：IDOCでは、用語はPKCS＃7で定義され、S / MIMEで使用されているため、最初の使用の時点で定義する必要があります。
Tutorial: Digital enveloping is not simply a synonym for implementing data confidentiality with encryption; digital enveloping is a hybrid encryption scheme to "seal" a message or other data, by encrypting the data and sending both it and a protected form of the key to the intended recipient, so that no one other than the intended recipient can "open" the message. In PKCS #7, it means first encrypting the data using a symmetric encryption algorithm and a secret key, and then encrypting the secret key using an asymmetric encryption algorithm and the public key of the intended recipient. In S/MIME, additional methods are defined for encrypting the content encryption key.
チュートリアル：デジタルエンベロープは、暗号化とデータの機密性を実装するための単なる同義語ではありません。デジタルエンベロープは、データを暗号化し、それを意図した受信者に保護された受信者に保護された受信者に送信することによって、メッセージまたは他のデータを「シール」するハイブリッド暗号化方式であるため、意図した受信者以外の誰もが「開く」ことはできません。メッセージ。PKCS＃7では、最初に対称暗号化アルゴリズムと秘密鍵を使用してデータを暗号化し、次に非対称暗号化アルゴリズムと意図した受信者の公開鍵を使用して秘密鍵を暗号化します。S / MIMEでは、コンテンツ暗号化キーを暗号化するために追加のメソッドが定義されています。
$ Digital ID(service mark) (D) Synonym for "digital certificate".
$ デジタルID（サービスマーク）（D）「デジタル証明書」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term. It is a service mark of a commercial firm, and it unnecessarily duplicates the meaning of a better-established term. (See: credential.)
廃止予定語：IDocsはこの用語を使用しないでください。商業会社のサービスマークであり、それは不必要に確立された用語の意味を重複しています。（「資格情報」を参照してください。
$ digital key (D) Synonym for an input parameter of a cryptographic algorithm or other process. (See: key.)
$ デジタルキー（D）暗号化アルゴリズムまたは他のプロセスの入力パラメータの同義語。（キーを参照してください。）
Deprecated Usage: The adjective "digital" need not be used with "key" or "cryptographic key", unless the context is insufficient to distinguish the digital key from another kind of key, such as a metal key for a door lock.
廃止予定の使用法：形容詞の「デジタル」は、ドアロックのためのメタルキーのような別の種類のキーとデジタルキーを別の種類のキーと区別するのに不十分でない限り、「キー」または「暗号鍵」と共に使用する必要はありません。
$ digital notary (I) An electronic functionary analogous to a notary public. Provides a trusted timestamp for a digital document, so that someone can later prove that the document existed at that point in time; verifies the signature(s) on a signed document before applying the stamp. (See: notarization.)
$ Digital Natory（i）公証人に類似した電子機能。デジタル文書のための信頼できるタイムスタンプを提供するので、誰かがその時点でその時点で文書が存在していることを証明できるようにします。スタンプを適用する前に、署名付き文書上の署名を検証します。（参照：公証を参照してください。）
$ digital signature 1. (I) A value computed with a cryptographic algorithm and associated with a data object in such a way that any recipient of the data can use the signature to verify the data's origin and integrity. (See: data origin authentication service, data integrity service, signer. Compare: digitized signature, electronic signature.) 2. (O) "Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient." [I7498-2]
$ DIGITAL SIGNATURE 1.（i）暗号化アルゴリズムで計算され、データの受信者が署名を使用してデータの起源と整合性を検証できるようにすることでデータオブジェクトに関連付けられた値。（Data Origin認証サービス、Data Integrity Service、署名者。比較：デジタル化シグネチャ、電子シグネチャ。）2。データユニットの受信者を許可するデータユニットに追加されたデータ、または暗号化の変換データユニットのソースと完全性を証明し、例えば受信者によって偽造から保護します。」[I7498-2]
Tutorial: A digital signature should have these properties: - Be capable of being verified. (See: validate vs. verify.) - Be bound to the signed data object in such a way that if the data is changed, then when an attempt is made to verify the signature, it will be seen as not authentic. (In some schemes, the signature is appended to the signed object as stated by definition 2, but in other it, schemes is not.) - Uniquely identify a system entity as being the signer. - Be under the signer's sole control, so that it cannot be created by any other entity.
チュートリアル：デジタル署名はこれらのプロパティを持つべきです： - 検証可能であることがあります。データが変更された場合、署名が検証されたときに署名されたデータオブジェクトにバインドされ、認証されないように署名されたデータオブジェクトにバインドされます。（一部の方式では、定義2で述べたように署名は署名に追加されますが、他にはスキームはありません。） - システムエンティティを署名者として一意に識別します。 - 署名者の唯一のコントロールの下にあるので、他のエンティティによっては作成できません。
To achieve these properties, the data object is first input to a hash function, and then the hash result is cryptographically transformed using a private key of the signer. The final resulting value is called the digital signature of the data object. The signature value is a protected checksum, because the properties of a cryptographic hash ensure that if the data object is changed, the digital signature will no longer match it. The digital signature is unforgeable because one cannot be certain of correctly creating or changing the signature without knowing the private key of the supposed signer.
これらのプロパティを実現するために、データオブジェクトは最初にハッシュ関数に入力され、その後、ハッシュ結果は署名者の秘密鍵を使用して暗号的に変換されます。最終結果の値は、データオブジェクトのデジタル署名と呼ばれます。暗号化されたチェックサムは、データオブジェクトが変更された場合、デジタル署名がそれを一致しなくなることを確認します。想定されている署名者の秘密鍵を知らずに、シグニチャを正しく作成または変更することが確実にすることはできないため、デジタル署名は承認できません。
Some digital signature schemes use an asymmetric encryption algorithm (e.g., "RSA") to transform the hash result. Thus, when Alice needs to sign a message to send to Bob, she can use her private key to encrypt the hash result. Bob receives both the message and the digital signature. Bob can use Alice's public key to decrypt the signature, and then compare the plaintext result to the hash result that he computes by hashing the message himself. If the values are equal, Bob accepts the message because he is certain that it is from Alice and has arrived unchanged. If the values are not equal, Bob rejects the message because either the message or the signature was altered in transit.
いくつかのデジタル署名方式は、ハッシュ結果を変換するための非対称暗号化アルゴリズム（例えば、「RSA」）を使用する。したがって、AliceがBobに送信するメッセージに署名する必要があるとき、彼女は彼女の秘密鍵を使ってハッシュ結果を暗号化することができます。ボブはメッセージとデジタル署名の両方を受け取ります。BOBは署名を復号化するためにAliceの公開鍵を使用してから、プレーンテキストの結果をハッシュ結果と比較することができます。値が等しい場合、BOBはそれがアリスからのものであり、変更されていないことを確認しているため、メッセージを受け入れます。値が等しくない場合、BOBはメッセージまたは署名がTransitで変更されたため、メッセージを拒否します。
Other digital signature schemes (e.g., "DSS") transform the hash result with an algorithm (e.g., "DSA", "El Gamal") that cannot be directly used to encrypt data. Such a scheme creates a signature value from the hash and provides a way to verify the signature value, but does not provide a way to recover the hash result from the signature value. In some countries, such a scheme may improve exportability and avoid other legal constraints on usage. Alice sends the signature value to Bob along with both the message and its hash result. The algorithm enables Bob to use Alice's public signature key and the signature value to verify the hash result he receives. Then, as before, he compares that hash result she sent to the one that he computes by hashing the message himself.
他のデジタル署名方式（例えば、「DSS」）は、データを暗号化するために直接使用することができないアルゴリズム（例えば、「DSA」、「EL Gamal」）でハッシュ結果を変換する。そのような方式はハッシュから署名値を作成し、署名値を検証する方法を提供するが、署名値からハッシュ結果を回復する方法を提供しない。いくつかの国では、そのような方式は輸出可能性を改善し、そして使用に対する他の法的制約を回避するかもしれません。アリスは、メッセージとそのハッシュ結果の両方とともに、署名値をBobに送信します。このアルゴリズムにより、BOBはAliceのパブリックシグネチャキーと署名値を使用してハッシュ結果を確認することができます。それから、以前と同じように、彼は彼女がメッセージをハッシュすることによって計算したものに送られたハッシュ結果と比較します。
$ Digital Signature Algorithm (DSA) (N) An asymmetric cryptographic algorithm for a digital signature in the form of a pair of large numbers. The signature is computed using rules and parameters such that the identity of the signer and the integrity of the signed data can be verified. (See: DSS.)
$ デジタル署名アルゴリズム（DSA）（N）一対の多数の形式のデジタル署名のための非対称暗号化アルゴリズム。署名は、署名者の身元と署名付きデータの整合性を検証することができるように、ルールとパラメータを使用して計算されます。（DSSを参照してください。）
$ Digital Signature Standard (DSS) (N) The U.S. Government standard [FP186] that specifies the DSA.
$ デジタル署名標準（DSS）（N）DSAを指定する米国政府標準[FP186]。
$ digital watermarking (I) Computing techniques for inseparably embedding unobtrusive marks or labels as bits in digital data -- text, graphics, images, video, or audio -- and for detecting or extracting the marks later.
$ デジタルウォーターマーク（I）単純なマークまたはラベルを不可避的に埋め込むためのコンピューティング技術 - テキスト、グラフィック、画像、ビデオ、またはオーディオの後にマークを検出または抽出するためのビットとして。
Tutorial: A "digital watermark", i.e., the set of embedded bits, is sometimes hidden, usually imperceptible, and always intended to be unobtrusive. Depending on the particular technique that is used, digital watermarking can assist in proving ownership, controlling duplication, tracing distribution, ensuring data integrity, and performing other functions to protect intellectual property rights. [ACM]
チュートリアル：「電子透かし」、すなわち埋め込まれたビットのセットは時々隠されていて、通常は知覚できなくなり、常に邪魔にならないことを意図しています。使用される特定の技術に応じて、デジタル透かし入れは、所有権を証明し、複製の制御、トレース分布、データの整合性の確保、および知的財産権を保護するための他の機能の実行を支援することができる。[ACM]
$ digitized signature (D) Denotes various forms of digitized images of handwritten signatures. (Compare: digital signature).
$ デジタル化された署名（d）は、手書きの署名のさまざまな形式の画像を示します。（比較：デジタル署名）。
Deprecated Term: IDOCs SHOULD NOT use this term without including this definition. This term suggests careless use of "digital signature", which is the term standardized by [I7498-2]. (See: electronic signature.)
廃止予定の用語：IDocはこの定義を含まずにこの用語を使用しないでください。この用語は、「デジタル署名」の不注意な使用を示唆しています。これは[I7498-2]によって規格化された用語です。（参照：電子署名。）
$ DII (O) See: Defense Information Infrastructure.
$ DII（O）：防衛情報インフラストラクチャーを参照してください。
$ direct attack (I) See: secondary definition under "attack". (Compare: indirect attack.)
$ 直接攻撃（i）「攻撃」の下の二次定義を参照してください。（比較：間接攻撃）
$ directory, Directory 1. (I) /not capitalized/ Refers generically to a database server or other system that stores and provides access to values of descriptive or operational data items that are associated with the components of a system. (Compare: repository.) 2. (N) /capitalized/ Refers specifically to the X.500 Directory. (See: DN, X.500.)
$ディレクトリ、ディレクトリ1.（i）/資本化/は、システムのコンポーネントに関連付けられている記述的または運用データ項目の値へのアクセスを保存して提供するデータベースサーバーまたはその他のシステムを総称して参照していません。（Compare：リポジトリ。）2。（n）/資本化/特にX.500ディレクトリを参照します。（DN、X.500を参照）
$ Directory Access Protocol (DAP) (N) An OSI protocol [X519] for communication between a Directory User Agent (a type of X.500 client) and a Directory System Agent (a type of X.500 server). (See: LDAP.)
$ Directory Access Protocol（DAP）（N）ディレクトリユーザーエージェント（X.500クライアントの一種）とディレクトリシステムエージェント（X.500サーバーの種類）の間の通信のためのOSIプロトコル[X519]。（参照：LDAPを参照）
$ disaster plan (O) Synonym for "contingency plan".
$ 災害計画（O）「緊急プラン」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; instead, for consistency and neutrality of language, IDOCs SHOULD use "contingency plan".
廃止予定語：IDocsはこの用語を使用しないでください。代わりに、言語の一貫性と中立性のために、IDocは「緊急時刻計画」を使用するべきです。
$ disclosure See: unauthorized disclosure. Compare: exposure.
$ 開示：不正開示を参照してください。比較：露出。
$ discretionary access control 1a. (I) An access control service that (a) enforces a security policy based on the identity of system entities and the authorizations associated with the identities and (b) incorporates a concept of ownership in which access rights for a system resource may be granted and revoked by the entity that owns the resource. (See: access control list, DAC, identity-based security policy, mandatory access control.)
$ 任意アクセス制御1A。（i）システムエンティティの身元に基づいてセキュリティポリシーを施行するアクセス制御サービスと、IDと（B）に関連付けられている承認は、システムリソースのアクセス権が付与される可能性がある所有権の概念を組み込んでいます。リソースを所有するエンティティによって失効されました。（アクセス制御リスト、DAC、IDベースのセキュリティポリシー、必須アクセス制御）
Derivation: This service is termed "discretionary" because an entity can be granted access rights to a resource such that the entity can by its own volition enable other entities to access the resource.
派生：このサービスは、エンティティが自分のボディィションによって他のエンティティがリソースにアクセスできるように、エンティティにリソースへのアクセス権を付与できるため、「慎重な」と呼ばれます。
1b. (O) /formal model/ "A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject." [DoD1]
1b。（O）/フォーマルモデル/「対象物やそれらが属するグループのアイデンティティに基づいてオブジェクトへのアクセスを制限する手段は、特定のアクセス許可を有する被験者がそれを通過することができるという意味で裁量的である。許可（おそらく間接的に）他の主題に。」[DOD1]
$ DISN (O) See: Defense Information Systems Network (DISN).
$ Down（to）：防衛情報システムネットワーク（DISN）を参照してください。
$ disruption (I) A circumstance or event that interrupts or prevents the correct operation of system services and functions. (See: availability, critical, system integrity, threat consequence.) Tutorial: Disruption is a type of threat consequence; it can be caused by the following types of threat actions: incapacitation, corruption, and obstruction.
$中断（i）システムサービスと機能の正しい動作を中断または妨げる状況またはイベント。（空室状況、重要、システムの整合性、脅威の結果）チュートリアル：脅威の影響の一種です。それは以下の種類の脅威行動によって引き起こされる可能性があります：無能力、汚職、および障害物。
$ Distinguished Encoding Rules (DER) (N) A subset of the Basic Encoding Rules that always provides only one way to encode any data structure defined by ASN.1. [X690].
$ 識別符号化規則（der）（n）ASN.1で定義されたデータ構造を符号化する1つの方法のみを常に提供する基本的なエンコード規則のサブセット。[X690]。
Tutorial: For a data structure defined abstractly in ASN.1, BER often provides for encoding the structure into an octet string in more than one way, so that two separate BER implementations can legitimately produce different octet strings for the same ASN.1 definition. However, some applications require all encodings of a structure to be the same, so that encodings can be compared for equality. Therefore, DER is used in applications in which unique encoding is needed, such as when a digital signature is computed on a structure defined by ASN.1.
チュートリアル：ASN.1で抽象的に定義されているデータ構造の場合、BERは、複数の方法で構造を複数の方法で符号化することを可能にしますので、2つの別々のBER実装は同じASN.1定義に対して異なるオクテット文字列を作成できます。しかしながら、いくつかのアプリケーションは、構造体のすべてのエンコーディングを同じにする必要があるので、エンコードを平等と比較することができる。したがって、DERは、デジタル署名がASN.1によって定義された構造で計算されるときなど、固有の符号化が必要とされるアプリケーションで使用される。
$ distinguished name (DN) (N) An identifier that uniquely represents an object in the X.500 Directory Information Tree (DIT) [X501]. (Compare: domain name, identity, naming authority.)
$ 識別名（DN）（n）X.500ディレクトリ情報ツリー（DIT）[X501]のオブジェクトを一意に表す識別子。（比較：ドメイン名、ID、命名権限）
Tutorial: A DN is a set of attribute values that identify the path leading from the base of the DIT to the object that is named. An X.509 public-key certificate or CRL contains a DN that identifies its issuer, and an X.509 attribute certificate contains a DN or other form of name that identifies its subject.
チュートリアル：DNは、DITのベースから名前が付けられているオブジェクトへのパスを識別する属性値のセットです。X.509公開鍵証明書またはCRLには、その発行者を識別するDNが含まれており、X.509属性証明書にはその件名を識別するDNまたはその他の形式の名前が含まれています。
$ distributed attack 1a. (I) An attack that is implemented with distributed computing. (See: zombie.)
$ 分散攻撃1A。（i）分散コンピューティングで実装されている攻撃。（ゾンビを参照してください。）
1b. (I) An attack that deploys multiple threat agents.
1b。（i）複数の脅威エージェントを展開する攻撃。
$ Distributed Authentication Security Service (DASS) (I) An experimental Internet protocol [R1507] that uses cryptographic mechanisms to provide strong, mutual authentication services in a distributed environment.
$ 分散認証セキュリティサービス（DASS）（i）分散環境で強力な相互認証サービスを提供するために暗号化メカニズムを使用する実験的なインターネットプロトコル[R1507]。
$ distributed computing (I) A technique that disperses a single, logically related set of tasks among a group of geographically separate yet cooperating computers. (See: distributed attack.)
$ 分散コンピューティング（i）地理的に別々のまだ協力しているコンピュータのグループ間で単一の論理的に関連する一連のタスクを分散させる手法。（分散攻撃を参照してください。）
$ distribution point (I) An X.500 Directory entry or other information source that is named in a v3 X.509 public-key certificate extension as a location from which to obtain a CRL that may list the certificate.
$ 配布ポイント（i）証明書をリストすることができるCRLを取得するための場所として、X.500ディレクトリエントリまたはv3 X.509公開鍵証明書拡張機能。
Tutorial: A v3 X.509 public-key certificate may have a "cRLDistributionPoints" extension that names places to get CRLs on which the certificate might be listed. (See: certificate profile.) A CRL obtained from a distribution point may (a) cover either all reasons for which a certificate might be revoked or only some of the reasons, (b) be issued by either the authority that signed the certificate or some other authority, and (c) contain revocation entries for only a subset of the full set of certificates issued by one CA or (d) contain revocation entries for multiple CAs.
チュートリアル：v3 x.509公開鍵証明書には、証明書がリストされることがあるCRLを取得するための場所がある「CRLDistributionPoints」の拡張子がある可能性があります。（証明書プロファイル参照）配布ポイントから取得したCRL（a）証明書が取り消される可能性があるすべての理由で、またはその理由の一部、（B）証明書に署名した権限によって発行されるすべての理由他のいくつかの権限、および（c）には、1つのCAまたは（d）によって発行された証明書のフルセットのサブセットのための失効エントリが含まれています。（d）複数のCAの失効エントリが含まれています。
$ DKIM (I) See: Domain Keys Identified Mail.
$ DKIM（i）ドメインキーを識別したメールを参照してください。
$ DMZ (D) See: demilitarized zone.
$ DMZ（D）武装ゾーンを参照してください。
$ DN (N) See: distinguished name.
$ DN（N）参照：識別名。
$ DNS (I) See: Domain Name System.
$ DNS（i）ドメインネームシステムを参照してください。
$ doctrine See: security doctrine.
$ Doctrine See：セキュリティの教義。
$ DoD (N) Department of Defense.
$ DOD（N）防衛科。
Usage: To avoid international misunderstanding, IDOCs SHOULD use this abbreviation only with a national qualifier (e.g., U.S. DoD).
使用法：国際誤解を避けるために、IDocは国内修飾子（例えば、米国のDOD）とのみこの略語を使用する必要があります。
$ DOI (I) See: Domain of Interpretation.
$ doi（i）は、解釈のドメインを参照してください。
$ domain 1a. (I) /general security/ An environment or context that (a) includes a set of system resources and a set of system entities that have the right to access the resources and (b) usually is defined by a security policy, security model, or security architecture. (See: CA domain, domain of interpretation, security perimeter. Compare: COI, enclave.) Tutorial: A "controlled interface" or "guard" is required to transfer information between network domains that operate under different security policies.
ドメイン1a。（i）/一般セキュリティ/（a）の一連のシステムリソースとリソースにアクセスする権利を持つ一連のシステムエンティティが含まれ、通常はセキュリティポリシー、セキュリティモデルによって定義されているシステムリソースのセットが含まれています。またはセキュリティアーキテクチャ。（CAドメイン、解釈のドメイン、セキュリティ境界。比較：COI、エンクリューブ。）チュートリアル：さまざまなセキュリティポリシーで動作するネットワークドメイン間で情報を転送するには、「管理インタフェース」または「GUARD」が必要です。
1b. (O) /security policy/ A set of users, their information objects, and a common security policy. [DoD6, SP33]
1b。（O）/セキュリティポリシー/ユーザのセット、それらの情報オブジェクト、および共通のセキュリティポリシー。[DOD6、SP33]
1c. (O) /security policy/ A system or collection of systems that (a) belongs to a community of interest that implements a consistent security policy and (b) is administered by a single authority.
1c。（O）/セキュリティポリシー/（a）が一貫性のあるセキュリティポリシーを実装する興味のあるコミュニティに属するシステムのシステムまたはコレクションは、単一の権限によって管理されています。
2. (O) /COMPUSEC/ An operating state or mode of a set of computer hardware.
2. （O）/ COMPUSEC /コンピュータハードウェアのセットの動作状態またはモード。
Tutorial: Most computers have at least two hardware operating modes [Gass]: - "Privileged" mode: a.k.a. "executive", "master", "system", "kernel", or "supervisor" mode. In this mode, software can execute all machine instructions and access all storage locations. - "Unprivileged" mode: a.k.a. "user", "application", or "problem" mode. In this mode, software is restricted to a subset of the instructions and a subset of the storage locations.
チュートリアル：ほとんどのコンピュータには、少なくとも2つのハードウェア動作モードがあります。このモードでは、ソフトウェアはすべてのマシン命令を実行し、すべてのストレージロケーションにアクセスできます。 - 「統計的な」モード：a.k.a. "user"、 "application"、または "問題"モード。このモードでは、ソフトウェアは命令のサブセットとストレージ位置のサブセットに制限されています。
3. (O) "A distinct scope within which certain common characteristics are exhibited and common rules are observed." [CORBA]
3. （O）「特定の共通の特徴が発揮され、一般的な規則が観察される明確な範囲。」[CORBA]
4. (O) /MISSI/ The domain of a MISSI CA is the set of MISSI users whose certificates are signed by the CA.
4. （O）/ MISSI / MISSI CAのドメインは、証明書がCAによって署名されているMissi Usersのセットです。
5. (I) /Internet/ That part of the tree-structured name space of the DNS that is at or below the name that specifies the domain. A domain is a subdomain of another domain if it is contained within that domain. For example, D.C.B.A is a subdomain of C.B.A
5. （i）/インターネット/ドメインを指定する名前以下のDNSのツリー構造化ネームスペース。ドメインは、そのドメイン内に含まれている場合、別のドメインのサブドメインです。例えば、D.C.B.AはC.B.Aのサブドメインである
6. (O) /OSI/ An administrative partition of a complex distributed OSI system.
6. （O）/ OSI /複合分散OSIシステムの管理パーティション。
$ Domain Keys Identified Mail (DKIM) (I) A protocol, which is being specified by the IETF working group of the same name, to provide data integrity and domain-level (see: DNS, domain name) data origin authentication for Internet mail messages. (Compare: PEM.)
$ ドメインキー識別されたメール（DKIM）（i）同じ名前のIETFワーキンググループによって指定されているプロトコル、データの整合性とドメインレベルを提供する（DNS、ドメイン名）インターネットメールメッセージのデータ発信元認証。（比較：PEM。）
Tutorial: DKIM employs asymmetric cryptography to create a digital signature for an Internet email message's body and selected headers (see RFC 1822), and the signature is then carried in a header of the message. A recipient of the message can verify the signature and, thereby, authenticate the identity of the originating domain and the integrity of the signed content, by using a public key belonging to the domain. The key can be obtained from the DNS.
チュートリアル：DKIMは、インターネットの電子メールメッセージの本文と選択されたヘッダーのデジタル署名を作成するために非対称暗号化を採用しています（RFC 1822を参照）、その後、署名はメッセージのヘッダーに搭載されます。メッセージの受信者は、そのドメインに属する公開鍵を使用して、署名を検証することができ、それによって発信ドメインの識別情報と署名されたコンテンツの整合性を認証することができます。キーはDNSから取得できます。
$ domain name (I) The style of identifier that is defined for subtrees in the Internet DNS -- i.e., a sequence of case-insensitive ASCII labels separated by dots (e.g., "bbn.com") -- and also is used in other types of Internet identifiers, such as host names (e.g., "rosslyn.bbn.com"), mailbox names (e.g., "rshirey@bbn.com") and URLs (e.g., "http://www.rosslyn.bbn.com/foo"). (See: domain. Compare: DN.)
$ ドメイン名（i）インターネットDNSのサブツリーに対して定義されている識別子のスタイル、すなわち、ドットで区切られた大文字と小文字を区別しないASCIIラベルのシーケンス（例えば、「BBN.com」） - およびその他にも使用されています。ホスト名（「rosslyn.bbn.com」）、メールボックス名（例えば、 "rshireyy@bbn.com"）、URL（例えば、http：//www.rosslyn.bbn）などのインターネット識別子の種類。com / foo "）（ドメインを参照してください。比較：dn。）
Tutorial: The name space of the DNS is a tree structure in which each node and leaf holds records describing a resource. Each node has a label. The domain name of a node is the list of labels on the path from the node to the root of the tree. The labels in a domain name are printed or read left to right, from the most specific (lowest, farthest from the root) to the least specific (highest, closest to the root), but the root's label is the null string. (See: country code.)
チュートリアル：DNSの名前スペースは、各ノードとリーフがリソースを記述するレコードを保持するツリー構造です。各ノードにラベルがあります。ノードのドメイン名は、ノードからツリーのルートへのパス上のラベルのリストです。ドメイン名のラベルは、最も具体的な（ルートから最も遠い最小値）から最小の特定（Rootに最も近い）まで、左から右に表示されますが、ルートのラベルはNULL文字列です。（参照：国コードを参照してください。）
$ Domain Name System (DNS) (I) The main Internet operations database, which is distributed over a collection of servers and used by client software for purposes such as (a) translating a domain name-style host name into an IP address (e.g., "rosslyn.bbn.com" translates to "192.1.7.10") and (b) locating a host that accepts mail for a given mailbox address. (RFC 1034) (See: domain name.)
$ ドメインネームシステム（DNS）（I）メインのインターネット操作データベースは、サーバーのコレクションを介して配布され、（a）ドメイン名スタイルのホスト名をIPアドレスに変換する目的でクライアントソフトウェアで使用されています（例："rosslyn.bbn.com"は "192.1.7.10"）と（b）特定のメールボックスアドレスのメールを受け入れるホストを見つける。（RFC 1034）（ドメイン名参照）
Tutorial: The DNS has three major components: - Domain name space and resource records: Specifications for the tree-structured domain name space, and data associated with the names. - Name servers: Programs that hold information about a subset of the tree's structure and data holdings, and also hold pointers to other name servers that can provide information from any part of the tree. - Resolvers: Programs that extract information from name servers in response to client requests; typically, system routines directly accessible to user programs.
チュートリアル：DNSには3つの主要コンポーネントがあります。 - ドメイン名スペースとリソースレコード：ツリー構造化ドメイン名スペースの仕様、および名前に関連付けられているデータ。 - ネームサーバ：ツリーの構造とデータ保持点のサブセットに関する情報を保持するプログラム、およびツリーの任意の部分から情報を提供できる他のネームサーバへのポインタを保持するプログラム。 - リゾルバ：クライアント要求に応答してネームサーバから情報を抽出するプログラム。通常、システムルーチンはユーザープログラムに直接アクセス可能です。
Extensions to the DNS [R4033, R4034, R4035] support (a) key distribution for public keys needed for the DNS and for other protocols, (b) data origin authentication service and data integrity service for resource records, (c) data origin authentication service for transactions between resolvers and servers, and (d) access control of records.
DNSへの拡張[R4033、R4034、R4035]サポート（A）DNSに必要な公開鍵およびその他のプロトコルのための鍵配布、（B）リソース・レコードのデータ・インテグリティ・サービス、（C）データ・オリジナル認証リゾルバとサーバー間のトランザクションのためのサービス、および（d）レコードのアクセス制御。
$ domain of interpretation (DOI) (I) /IPsec/ A DOI for ISAKMP or IKE defines payload formats, exchange types, and conventions for naming security-relevant information such as security policies or cryptographic algorithms and modes. Example: See [R2407].
$ ISAKMPまたはIKE用の解釈ドメイン（I）/ IPSEC / A DOIは、セキュリティポリシーや暗号化アルゴリズムやモードなどのセキュリティ関連情報と命名するためのペイロードフォーマット、交換タイプ、および規則を定義します。例：[R2407]を参照してください。
Derivation: The DOI concept is based on work by the TSIG's CIPSO Working Group.
派生：DOIコンセプトはTSIGのCIPSOワーキンググループによる作業に基づいています。
$ dominate (I) Security level A is said to "dominate" security level B if the (hierarchical) classification level of A is greater (higher) than or equal to that of B, and A's (nonhierarchical) categories include (as a subset) all of B's categories. (See: lattice, lattice model.)
$ （i）セキュリティレベルAは、Aの（階層的な）分類レベルがBの（階層的な）分類レベルが大きい（より高い）の場合、およびAの（サブセットとして）を含む場合に「支配」セキュリティレベルBと言われています。すべてのBのカテゴリー。（格子、格子モデルを参照）
$ dongle (I) A portable, physical, usually electronic device that is required to be attached to a computer to enable a particular software program to run. (See: token.)
$ Dongle（i）特定のソフトウェアプログラムを実行できるようにコンピュータに接続する必要があるポータブル、物理的、通常は電子機器。（：トークンを参照してください。）
Tutorial: A dongle is essentially a physical key used for copy protection of software; that is, the program will not run unless the matching dongle is attached. When the software runs, it periodically queries the dongle and quits if the dongle does not reply with the proper authentication information. Dongles were originally constructed as an EPROM (erasable programmable read-only memory) to be connected to a serial input-output port of a personal computer.
チュートリアル：ドングルは本質的にソフトウェアのコピー保護に使用される物理キーです。つまり、一致するドングルが接続されていない限り、プログラムは実行されません。ソフトウェアが実行されると、ドングルが適切な認証情報で返信しない場合は、定期的にドングルに問い合わせて終了します。ドングルはもともとパーソナルコンピュータのシリアル入出力ポートに接続されるEPROM（消去可能プログラマブル読み取り専用メモリ）として構築されました。
$ downgrade (I) /data security/ Reduce the security level of data (especially the classification level) without changing the information content of the data. (Compare: downgrade.)
$ データの情報内容を変更せずに、ダウングレード（I）/データセキュリティ/データのセキュリティレベル（特に分類レベル）を縮小します。（比較：ダウングレード）
$ downgrade attack (I) A type of man-in-the-middle attack in which the attacker can cause two parties, at the time they negotiate a security association, to agree on a lower level of protection than the highest level that could have been supported by both of them. (Compare: downgrade.)
$ ダウングレード攻撃（i）攻撃者がセキュリティ協会を交渉する時点で、攻撃者が2人の締約国を引き起こす可能性がある一種の攻撃の一種である。両方でサポートされています。（比較：ダウングレード）
$ draft RFC (D) A preliminary, temporary version of a document that is intended to become an RFC. (Compare: Internet-Draft.)
$ RFC（d）RFCになることを目的とした文書の予備的な一時的なバージョン。（比較：インターネットドラフト）
Deprecated Term: IDOCs SHOULD NOT use this term. The RFC series is archival in nature and consists only of documents in permanent form. A document that is intended to become an RFC usually needs to be published first as an Internet-Draft (RFC 2026). (See: "Draft Standard" under "Internet Standard".)
廃止予定語：IDocsはこの用語を使用しないでください。RFCシリーズは本質的なアーカイブであり、永久形式の文書のみで構成されています。RFCになることを目的とした文書は、通常、インターネットドラフトとして最初に公開される必要があります（RFC 2026）。（「インターネット規格」の下の「ドラフト標準」。）
$ Draft Standard (I) See: secondary definition under "Internet Standard".
$ 標準標準（I）「インターネット規格」の下の二次定義を参照してください。
$ DSA (N) See: Digital Signature Algorithm.
$ DSA（N）は、デジタル署名アルゴリズムを参照してください。
$ DSS (N) See: Digital Signature Standard.
$ DSS（N）デジタル署名規格を参照してください。
$ dual control (I) A procedure that uses two or more entities (usually persons) operating in concert to protect a system resource, such that no single entity acting alone can access that resource. (See: no-lone zone, separation of duties, split knowledge.)
$ デュアルコントロール（i）システムリソースを保護するためにコンサートで動作する2つ以上のエンティティ（通常は人物）を使用する手順は、単一のエンティティがそのリソースにアクセスできないようにします。（孤独な区域、職務の分離、分割知識）
$ dual signature (O) /SET/ A single digital signature that protects two separate messages by including the hash results for both sets in a single encrypted value. [SET2]
$ 両方のセットのハッシュ結果を単一の暗号化値に含めることによって、2つの別々のメッセージを保護するデュアルシグネチャ（O）/ SET / SET / Aシングルデジタル署名。[SET2]
Deprecated Usage: IDOCs SHOULD NOT use this term except when qualified as "SET(trademark) dual signature" with this definition.
廃止予定の使用法：IDOCは、この定義で「セット（登録商標）デュアルシグネチャ」として修飾されている場合を除き、この用語を使用しないでください。
Tutorial: Generated by hashing each message separately, concatenating the two hash results, and then hashing that value and encrypting the result with the signer's private key. Done to reduce the number of encryption operations and to enable verification of data integrity without complete disclosure of the data.
チュートリアル：2つのハッシュ結果を連結してから、各メッセージを別々にハッシュし、その値をハッシュし、その値を署名者の秘密鍵で暗号化します。データの完全な開示なしに、暗号化操作の数を減らし、データの整合性の検証を可能にするために行われます。
$ dual-use certificate (O) A certificate that is intended for use with both digital signature and data encryption services. [SP32]
$ デュアルユース証明書（O）デジタル署名およびデータ暗号化サービスの両方で使用するための証明書。[SP32]
Usage: IDOCs that use this term SHOULD state a definition for it by identifying the intended uses of the certificate, because there are more than just these two uses mentioned in the NIST publication. A v3 X.509 public-key certificate may have a "key Usage" extension, which indicates the purposes for which the public key may be used. (See: certificate profile.)
使用法：この用語を使用するIDocは、NISTパブリケーションで言及されているこれら2つの使用方法以上のものがあるため、証明書の意図された用途を識別することによって、定義を定義します。v3 x.509公開鍵証明書は、公開鍵を使用できる目的を示す「鍵使用法」拡張子を持つことができます。（証明書プロファイルを参照してください。）
$ duty (I) An attribute of a role that obligates an entity playing the role to perform one or more tasks, which usually are essential for the functioning of the system. [Sand] (Compare authorization, privilege. See: role, billet.)
$ Duty（i）役割を果たすエンティティが1つ以上のタスクを実行する義務を負う役割の属性は、通常システムの機能に不可欠です。[砂]（承認、特権を比較してください。参照：役割、ビレット）
$ e-cash (O) Electronic cash; money that is in the form of data and can be used as a payment mechanism on the Internet. (See: IOTP.)
$ 電子キャッシュ（O）電子現金;データの形で、インターネット上の支払いメカニズムとして使用することができます。（参照：iotp。）
Usage: IDOCs that use this term SHOULD state a definition for it because many different types of electronic cash have been devised with a variety of security mechanisms.
使用法：この用語を使用するIDocは、さまざまなセキュリティメカニズムでさまざまな種類の電子現金が考案されているため、定義を定義します。
$ EAP (I) See: Extensible Authentication Protocol.
$ EAP（i）拡張認証プロトコルを参照してください。
$ EAL (O) See: evaluation assurance level.
$ EAL（O）評価保証レベルを参照してください。
$ Easter egg (O) "Hidden functionality within an application program, which becomes activated when an undocumented, and often convoluted, set of commands and keystrokes is entered. Easter eggs are typically used to display the credits for the development team and [are] intended to be non-threatening" [SP28], but Easter eggs have the potential to contain malicious code.
$ イースターエッグ（O） "アプリケーションプログラム内の隠し機能、それが文書化されていない、そしてしばしば回復されたコマンドとキーストロークのセットに入り込まれます。イースターエッグは通常、開発チームのクレジットを表示するために使用されています。非脅迫的な」[SP28]ですが、イースターエッグは悪意のあるコードを含む可能性があります。
Deprecated Usage: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の使用法：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ eavesdropping (I) Passive wiretapping done secretly, i.e., without the knowledge of the originator or the intended recipients of the communication.
$ 盗聴（I）パッシブ盗聴は、密かに、すなわち、発信者または通信の意図された受信者の知識なしに行われる。
$ ECB (N) See: electronic codebook.
$ ECB（N）は、電子コードブックを参照してください。
$ ECDSA (N) See: Elliptic Curve Digital Signature Algorithm.
$ ECDSA（N）：楕円曲線デジタル署名アルゴリズムを参照してください。
$ economy of alternatives (I) The principle that a security mechanism should be designed to minimize the number of alternative ways of achieving a service. (Compare: economy of mechanism.)
$ 代替案の経済（I）セキュリティメカニズムがサービスを実現するための代替方法の数を最小限に抑えるように設計されるべきという原則。（比較：メカニズムの経済。）
$ economy of mechanism (I) The principle that a security mechanism should be designed to be as simple as possible, so that (a) the mechanism can be correctly implemented and (b) it can be verified that the operation of the mechanism enforces the system's security policy. (Compare: economy of alternatives, least privilege.)
$ メカニズムの経済性（i）セキュリティメカニズムをできるだけ単純に設計することができるという原則であるため、（a）メカニズムを正しく実装でき、（b）機構の動作がシステムのシステムの動作を強制することを確認できます。セキュリティポリシー。（比較：代替案の経済、最小特権）。
$ ECU (N) See: end cryptographic unit.
$ ECU（N）参照：暗号化ユニットを終了します。
$ EDI (I) See: electronic data interchange.
$ EDI（i）：電子データ交換。
$ EDIFACT (N) See: secondary definition under "electronic data interchange".
$ EDIFACT（N）「電子データ交換」の下の二次定義を参照してください。
$ EE (D) Abbreviation of "end entity" and other terms.
$ EE（D）「エンドエンティティ」とその他の用語の略語。
Deprecated Abbreviation: IDOCs SHOULD NOT use this abbreviation; there could be confusion among "end entity", "end-to-end encryption", "escrowed encryption standard", and other terms.
廃止予定の省略形：IDOCはこの略語を使用しないでください。「エンドエンティティ」、「エンドツーエンド暗号化」、「エスクド暗号化規格」、およびその他の用語の間で混乱が発生する可能性があります。
$ EES (O) See: Escrowed Encryption Standard.
$ EES（O）ESSCROWED暗号化規格を参照してください。
$ effective key length (O) "A measure of strength of a cryptographic algorithm, regardless of actual key length." [IATF] (See: work factor.)
$ 実際のキー長にかかわらず、実効キー長（O）「暗号化アルゴリズムの強度の尺度」[IATF]（労働係数を参照してください。）
$ effectiveness (O) /ITSEC/ A property of a TOE representing how well it provides security in the context of its actual or proposed operational use.
$ 有効性（O）/ ITSEC /実際の操作式または提案されている運用型の文脈でどの程度安全を提供するかを表すTOEの財産。
$ El Gamal algorithm (N) An algorithm for asymmetric cryptography, invented in 1985 by Taher El Gamal, that is based on the difficulty of calculating discrete logarithms and can be used for both encryption and digital signatures. [ElGa]
$ EL Gamal Algorithm（n）1985年に発明された非対称暗号化のためのアルゴリズムは、離散的な対数を計算することの困難さと、暗号化とデジタル署名の両方に使用することができます。[エルガ]
$ electronic codebook (ECB) (N) A block cipher mode in which a plaintext block is used directly as input to the encryption algorithm and the resultant output block is used directly as cipher text [FP081]. (See: block cipher, [SP38A].)
$ 電子コードブック（ECB）（n）平文ブロックを暗号化アルゴリズムへの入力として直接使用するブロック暗号モードと、結果出力ブロックを直接暗号テキストとして使用する[FP081]。（以下を参照してください.cipher、[SP38A]）
$ electronic commerce 1. (I) Business conducted through paperless exchanges of information, using electronic data interchange, electronic funds transfer (EFT), electronic mail, computer bulletin boards, facsimile, and other paperless technologies.
$ 電子商取引1.（i）電子データ交換、電子資金輸送（EFT）、電子メール、コンピュータ掲示板、ファクシミリ、その他のペーパーレス技術を使用して、ペーパーレス情報交換を行った。
2. (O) /SET/ "The exchange of goods and services for payment between the cardholder and merchant when some or all of the transaction is performed via electronic communication." [SET2]
2. （O）/ SET / "取引の一部または全部が電子通信を介して行われたときのカード保有者とマーチャントの間の支払いのための商品およびサービスの交換。」[SET2]
$ electronic data interchange (EDI) (I) Computer-to-computer exchange, between trading partners, of business data in standardized document formats.
$ 電子データ交換（EDI）（i）標準化された文書フォーマットの業務データの取引相手間のコンピュータからコンピュータへの交換。
Tutorial: EDI formats have been standardized primarily by ANSI X12 and by EDIFACT (EDI for Administration, Commerce, and Transportation), which is an international, UN-sponsored standard primarily used in Europe and Asia. X12 and EDIFACT are aligning to create a single, global EDI standard.
チュートリアル：EDIフォーマットは、主にANSI X12によって標準化されており、主にヨーロッパとアジアで使用されている国際的でスポンサーが伴う規格である。X12とEDIFACTは、単一のグローバルEDI規格を作成するために整列しています。
$ Electronic Key Management System (EKMS) (O) "Interoperable collection of systems developed by ... the U.S. Government to automate the planning, ordering, generating, distributing, storing, filling, using, and destroying of electronic keying material and the management of other types of COMSEC material." [C4009]
$ 電子鍵管理システム（EKMS）（O）「米国政府」の相互運用可能なシステム政府は、電子キーイング材料の計画、注文、生成、配布、保存、充填、使用、および破壊との管理とその管理を自動化する。他の種類のCOMSEC素材。」[C4009]
$ electronic signature (D) Synonym for "digital signature" or "digitized signature".
$ 電子署名（D）「デジタル署名」または「デジタル化シグネチャ」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; there is no current consensus on its definition. Instead, use "digital signature", if that is what was intended
廃止予定語：IDocsはこの用語を使用しないでください。その定義には現在の合意はありません。代わりに、「デジタル署名」を使用してください。
$ electronic wallet (D) A secure container to hold, in digitized form, some sensitive data objects that belong to the owner, such as electronic money, authentication material, and various types of personal information. (See: IOTP.)
$ 電子財布（D）デジタル化された形で、電子マネー、認証資料、およびさまざまな種類の個人情報など、所有者に属するいくつかの機密データオブジェクトを保持するためのセキュアコンテナ。（参照：iotp。）
Deprecated Term: IDOCs SHOULD NOT use this term. There is no current consensus on its definition; and some uses and definitions may be proprietary. Meanings range from virtual wallets implemented by data structures to physical wallets implemented by cryptographic tokens. (See: Deprecated Usage under "Green Book".)
廃止予定語：IDocsはこの用語を使用しないでください。その定義には現在の合意はありません。そしていくつかの用途と定義は所有権かもしれません。データ構造によって実装された仮想財布から暗号化トークンによって実装された物理的財布までの意味範囲。（「グリーンブック」の「廃止予定の使用」。）
$ elliptic curve cryptography (ECC) (I) A type of asymmetric cryptography based on mathematics of groups that are defined by the points on a curve, where the curve is defined by a quadratic equation in a finite field. [Schn]
$ 楕円曲線暗号（ECC）（I）曲線上の点によって定義されるグループの数学に基づく非対称暗号化の一種。ここで曲線は、有限磁界の二次方程式によって定義される。[シュン]
Tutorial: ECC is based on mathematics different than that originally used to define the Diffie-Hellman-Merkle algorithm and the DSA, but ECC can be used to define an algorithm for key agreement that is an analog of Diffie-Hellman-Merkle [A9063] and an algorithm for digital signature that is an analog of DSA [A9062]. The mathematical problem upon which ECC is based is believed to be more difficult than the problem upon which Diffie-Hellman-Merkle is based and, therefore, that keys for ECC can be shorter for a comparable level of security. (See: ECDSA.)
チュートリアル：ECCは、Diffie-Hellman-MerkleアルゴリズムとDSAを定義するために使用されているものとは異なる数学に基づいていますが、Diffie-Hellman-Merkleの類似体である主な合意のためのアルゴリズムを定義するためにECCを使用することができます[A9063]DSAのアナログであるデジタル署名のためのアルゴリズム[A9062]。ECCが基づいている数学的問題は、DIFFIE-HELLMAN-MERKLEが基づく問題よりも難しいと考えられており、したがってECCのキーが同等のレベルのセキュリティでは短くなる可能性があると考えられています。（ECDSAを参照してください。）
$ Elliptic Curve Digital Signature Algorithm (ECDSA) (N) A standard [A9062] that is the analog, in elliptic curve cryptography, of the Digital Signature Algorithm.
$ 楕円曲線デジタル署名アルゴリズム（ECDSA）（N）デジタル署名アルゴリズムの楕円曲線暗号化である標準[A9062]。
$ emanation (I) A signal (e.g., electromagnetic or acoustic) that is emitted by a system (e.g., through radiation or conductance) as a consequence (i.e., byproduct) of the system's operation, and that may contain information. (See: emanations security.)
$ 放置（i）システムの動作の結果として（例えば、放射線またはコンダクタンスを通して）システムによって放出される信号（例えば、電磁または音響）であり、情報を含み得る。（調査セキュリティを参照してください。）
$ emanations analysis (I) /threat action/ See: secondary definition under "interception".
$ 発行分析（I）/脅威対応/参照：「傍受」の下の二次定義。
$ emanations security (EMSEC) (I) Physical security measures to protect against data compromise that could occur because of emanations that might be received and read by an unauthorized party. (See: emanation, TEMPEST.)
$ エミンテーションセキュリティ（EMSEC）（i）不正なパーティーによって受信されて読み取られる可能性がある分析の原因で発生する可能性があるデータの侵害から保護するための物理的なセキュリティ対策。（探している、緊張した。）
Usage: Refers either to preventing or limiting emanations from a system and to preventing or limiting the ability of unauthorized parties to receive the emissions.
使用法：システムからの発散を予防または制限し、許可されていない当事者が排出を受ける能力を予防または制限することを指します。
$ embedded cryptography (N) "Cryptography engineered into an equipment or system whose basic function is not cryptographic." [C4009]
$ 埋め込み暗号化（n） "基本機能が暗号化されていない機器またはシステムに設計された暗号化。」[C4009]
$ emergency plan (D) Synonym for "contingency plan".
$ 緊急計画（D）「緊急プラン」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term. Instead, for neutrality and consistency of language, use "contingency plan".
廃止予定語：IDocsはこの用語を使用しないでください。代わりに、中立性と言語の一貫性のために、「緊急時刻計画」を使用してください。
$ emergency response (O) An urgent response to a fire, flood, civil commotion, natural disaster, bomb threat, or other serious situation, with the intent of protecting lives, limiting damage to property, and minimizing disruption of system operations. [FP087] (See: availability, CERT, emergency plan.)
$ 緊急対応（O）耐火性、洪水、民事騒動、自然災害、爆弾の脅威、またはその他の深刻な状況への緊急の対応、寿命を保護し、財産の損傷を制限し、システム運用の中断を最小限に抑えます。[FP087]（availability、cert、緊急計画を参照）
$ EMSEC (I) See: emanations security.
$ EMSEC（I）EMANATIONSセキュリティを参照してください。
$ EMV (N) Abbreviation of "Europay, MasterCard, Visa". Refers to a specification for smart cards that are used as payment cards, and for related terminals and applications. [EMV1, EMV2, EMV3]
$ emv（n）「Europay、MasterCard、Visa」の略語。支払いカードとして使用されるスマートカード、および関連する端末およびアプリケーションのための仕様を指します。[EMV1、EMV2、EMV3]
$ Encapsulating Security Payload (ESP) (I) An Internet protocol [R2406, R4303] designed to provide data confidentiality service and other security services for IP datagrams. (See: IPsec. Compare: AH.)
$ セキュリティペイロード（ESP）をカプセル化する（i）IPデータグラムのためのデータ機密保持サービスおよびその他のセキュリティサービスを提供するように設計されたインターネットプロトコル[R2406、R4303]。（：IPSec。比較：ああ）
Tutorial: ESP may be used alone, or in combination with AH, or in a nested fashion with tunneling. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a host and a gateway. The ESP header is encapsulated by the IP header, and the ESP header encapsulates either the upper-layer protocol header (transport mode) or an IP header (tunnel mode). ESP can provide data confidentiality service, data origin authentication service, connectionless data integrity service, an anti-replay service, and limited traffic-flow confidentiality. The set of services depends on the placement of the implementation and on options selected when the security association is established.
チュートリアル：ESPは、単独で、またはAHと組み合わせて、トンネリングで入れ子になっています。セキュリティサービスは、一対の通信ホスト間、またはCommunicating Security Gatewaysの間、またはホストとゲートウェイの間に提供できます。ESPヘッダーはIPヘッダーによってカプセル化され、ESPヘッダーは上位層プロトコルヘッダー（トランスポートモード）またはIPヘッダー（トンネルモード）のいずれかをカプセル化します。ESPは、データ機密保持サービス、データオリジナル認証サービス、コネクションレスデータ整合性サービス、アンチリプレイサービス、およびトラフィックフロー機密性を提供できます。一連のサービスは、セキュリティアソシエーションが確立されたときに選択された実装の配置と選択されたオプションの配置によって異なります。
$ encipher (D) Synonym for "encrypt".
$ "暗号化"のための暗号化（d）同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "encrypt". However, see Usage note under "encryption".
廃止予定の定義：IDocは、この用語を「暗号化」の同義語として使用しないでください。ただし、「暗号化」の「使用上の注意」を参照してください。
$ encipherment (D) Synonym for "encryption".
$ 暗号化（D）「暗号化」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "encryption". However, see Usage note under "encryption".
非推奨の定義：IDocは、この用語を「暗号化」の同義語として使用しないでください。ただし、「暗号化」の「使用上の注意」を参照してください。
$ enclave 1. (I) A set of system resources that operate in the same security domain and that share the protection of a single, common, continuous security perimeter. (Compare: domain.)
$ Enclave 1.（i）同じセキュリティドメインで動作し、単一の一般的な、連続的なセキュリティ境界の保護を共有するシステムリソースのセットです。（比較：ドメイン。）
2. (D) /U.S. Government/ "Collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security." [C4009]
2. （d）/u.S。政府/「人員と物理的なセキュリティを含む単一の権限とセキュリティポリシーの管理に基づく1つ以上の内部ネットワークによって接続されたコンピューティング環境のコレクション。」[C4009]
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2 because the definition applies to what is usually called a "security domain". That is, a security domain is a set of one or more security enclaves.
定義の定義：定義は通常「セキュリティドメイン」と呼ばれるものに適用されるため、IDocは定義2でこの用語を使用しないでください。つまり、セキュリティドメインは1つ以上のセキュリティエンクレーブのセットです。
$ encode 1. (I) Use a system of symbols to represent information, which might originally have some other representation. Example: Morse code. (See: ASCII, BER.) (See: code, decode.)
$ エンコード1.（i）情報を表すためにシンボルのシステムを使用します。これにより、他のいくつかの表現がある可能性があります。例：モールスコード（：ASCII、BER。）（参照：コード、デコードを参照）
2. (D) Synonym for "encrypt".
2. （d）「暗号化」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "encrypt"; encoding is not always meant to conceal meaning.
非推奨の定義：IDocは、この用語を「暗号化」の同義語として使用しないでください。エンコードは必ずしも意味を隠すことを意味していません。
$ encrypt (I) Cryptographically transform data to produce cipher text. (See: encryption. Compare: seal.)
$ 暗号化（i）暗号的にデータを変換して暗号テキストを作成します。（暗号化を参照してください。比較：シールを参照してください。）
$ encryption 1. (I) Cryptographic transformation of data (called "plain text") into a different form (called "cipher text") that conceals the data's original meaning and prevents the original form from being used. The corresponding reverse process is "decryption", a transformation that restores encrypted data to its original form. (See: cryptography.)
$ 暗号化1.（i）データの元の形式を隠し、元のフォームが使用されるのを防ぎ、データの暗号化変換（「プレーンテキスト」と呼ばれる）の形式（「暗号テキスト」と呼ばれます）。対応する逆プロセスは、暗号化データを元のフォームに復元する変換である「復号化」です。（参照：暗号化。）
2. (O) "The cryptographic transformation of data to produce ciphertext." [I7498-2]
2. （O）「暗号文を生成するためのデータの暗号変換」[I7498-2]
Usage: For this concept, IDOCs SHOULD use the verb "to encrypt" (and related variations: encryption, decrypt, and decryption). However, because of cultural biases involving human burial, some international documents (particularly ISO and CCITT standards) avoid "to encrypt" and instead use the verb "to encipher" (and related variations: encipherment, decipher, decipherment).
使用法：このコンセプトの場合、IDocは動詞「暗号化」（および暗号化、復号化、および復号化）を使用する必要があります。しかし、人間の埋葬を含む文化的な偏りのために、いくつかの国際文書（特にISOおよびCCITT規格）は「暗号化する」を回避し、代わりに動詞「暗号化」（および関連する変動：暗号化、解読、解読）を使用します。
Tutorial: Usually, the plaintext input to an encryption operation is clear text. But in some cases, the plain text may be cipher text that was output from another encryption operation. (See: superencryption.)
チュートリアル：通常、暗号化操作への平文入力はクリアテキストです。しかし、いくつかの場合、プレーンテキストは別の暗号化操作から出力された暗号テキストであり得る。（SuperEncryptionを参照してください。）
Encryption and decryption involve a mathematical algorithm for transforming data. Besides the data to be transformed, the algorithm has one or more inputs that are control parameters: (a) a key that varies the transformation and, in some cases, (b) an IV that establishes the starting state of the algorithm.
暗号化と復号化はデータを変換するための数学的アルゴリズムを含みます。変換されるべきデータの他に、アルゴリズムは制御パラメータである1つ以上の入力を有し、（a）変換を変えるキー、および場合によっては（b）アルゴリズムの開始状態を確立するIV。
$ encryption certificate (I) A public-key certificate that contains a public key that is intended to be used for encrypting data, rather than for verifying digital signatures or performing other cryptographic functions.
$ 暗号化証明書（i）デジタル署名を検証するか他の暗号機能を実行するのではなく、データの暗号化に使用されることを意図した公開鍵を含む公開鍵証明書。
Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" extension that indicates the purpose for which the certified public key is intended. (See: certificate profile.)
チュートリアル：v3 x.509公開鍵証明書には、認証された公開鍵が意図されている目的を示す「KeyUsage」拡張子がある可能性があります。（証明書プロファイルを参照してください。）
$ end cryptographic unit (ECU) 1. (N) Final destination device into which a key is loaded for operational use.
$ 終了暗号化ユニット（ECU）1。（n）操作式のためにキーがロードされる最終宛先デバイス。
2. (N) A device that (a) performs cryptographic functions, (b) typically is part of a larger system for which the device provides security services, and (c), from the viewpoint of a supporting security infrastructure such as a key management system, is the lowest level of identifiable component with which a management transaction can be conducted
2. （n）（a）が暗号機能を実行する装置（b）は、通常、装置がセキュリティサービスを提供する大規模システムの一部であり、（c）、鍵管理システムなどの支援セキュリティ基盤の観点から、管理トランザクションを実行できる最低レベルの識別可能なコンポーネントです。
$ end entity 1. (I) A system entity that is the subject of a public-key certificate and that is using, or is permitted and able to use, the matching private key only for purposes other than signing a digital certificate; i.e., an entity that is not a CA.
$ エンドエンティティ1.（i）公開鍵証明書の件名であり、使用している、または使用できるシステムエンティティ、または使用可能で、デジタル証明書に署名すること以外の目的のための秘密鍵。すなわち、CAではないエンティティ。
2. (O) "A certificate subject [that] uses its public [sic] key for purposes other than signing certificates." [X509]
2. （O）「証明書の件名[証明書の署名以外の目的で）を使用している[SIC]キーを使用します。」[X509]
Deprecated Definition: IDOCs SHOULD NOT use definition 2, which is misleading and incomplete. First, that definition should have said "private key" rather than "public key" because certificates are not usefully signed with a public key. Second, the X.509 definition is ambiguous regarding whether an end entity may or may not use the private key to sign a certificate, i.e., whether the subject may be a CA. The intent of X.509's authors was that an end entity certificate is not valid for use in verifying a signature on an X.509 certificate or X.509 CRL. Thus, it would have been better for the X.509 definition to have said "only for purposes other than signing certificates".
廃止予定の定義：IDocは定義2を使用しないでください。これは誤解を招くと不完全です。まず、証明書が公開鍵で署名されていないため、その定義は「公開鍵」ではなく「秘密鍵」を持っているべきです。第二に、X.509の定義は、エンドエンティティが秘密鍵を使用して証明書に署名すること、すなわち対象がCAである可能性があるかどうかに関して曖昧である。X.509の著者の意図は、エンドエンティティ証明書がX.509証明書またはX.509 CRL上の署名の検証に使用するのに有効ではないことでした。したがって、X.509の定義が「証明書に署名する以外の目的のためだけに」と言ったことはより良いでしょう。
Usage: Despite the problems in the X.509 definition, the term itself is useful in describing applications of asymmetric cryptography. The way the term is used in X.509 implies that it was meant to be defined, as we have done here, relative to roles that an entity (which is associated with an OSI end system) is playing or is permitted to play in applications of asymmetric cryptography other than the PKI that supports applications.
使用法：X.509の定義の問題にもかかわらず、そのものは非対称暗号化の応用を説明するのに役立ちます。X.509で用語が使用されている方法は、エンティティ（OSIエンドシステムに関連付けられている）が再生されている、またはアプリケーションで再生を許可されているように、ここで行ったように、定義されることを意味することを意味します。アプリケーションをサポートするPKI以外の非対称暗号化の。
Tutorial: Whether a subject can play both CA and non-CA roles, with either the same or different certificates, is a matter of policy. (See: CPS.) A v3 X.509 public-key certificate may have a "basicConstraints" extension containing a "cA" value that specifically "indicates whether or not the public key may be used to verify certificate signatures". (See: certificate profile.)
チュートリアル：サブジェクトがCAと非CAロールの両方を再生できるか、同じまたは異なる証明書のいずれかで、ポリシーの問題です。（cps。）v3 X.509公開鍵証明書には、「公開鍵を使用して証明書署名を検証することができるかどうかを示す「CA」値を含む「基本情報」拡張子がある場合があります。（証明書プロファイルを参照してください。）
$ end system (N) /OSIRM/ A computer that implements all seven layers of the OSIRM and may attach to a subnetwork. Usage: In the IPS context, an end system is called a "host".
$ エンドシステム（N）/ OSIRR / OSIRMの7つのレイヤーを実装し、サブネットワークに添付することができるコンピュータ。使用法：IPSのコンテキストでは、エンドシステムは「ホスト」と呼ばれます。
$ end-to-end encryption (I) Continuous protection of data that flows between two points in a network, effected by encrypting data when it leaves its source, keeping it encrypted while it passes through any intermediate computers (such as routers), and decrypting it only when it arrives at the intended final destination. (See: wiretapping. Compare: link encryption.)
$ エンドツーエンド暗号化（i）ネットワーク内の2つの点間を流れるデータの連続保護、データをソースに残すときにデータを暗号化することによって影響を与え、それが任意の中間コンピュータ（ルーターなど）を通過し、復号化します。それは意図された最終目的地に到着したときだけです。（：盗聴：Link Encryptionを比較してください。）
Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS, SSH, SSL, TLS.
例：黒人、仲良活、IPLI、IPSec、PLI、SDN、SILS、SSH、SSL、TLSです。
Tutorial: When two points are separated by multiple communication links that are connected by one or more intermediate relays, end-to-end encryption enables the source and destination systems to protect their communications without depending on the intermediate systems to provide the protection.
チュートリアル：2つの点が1つ以上の中間リレーによって接続されている複数の通信リンクによって区切られている場合、エンドツーエンドの暗号化は、ソースシステムと宛先システムが中間システムに依存せずにそれらの通信を保護することを可能にします。
$ end user 1. (I) /information system/ A system entity, usually a human individual, that makes use of system resources, primarily for application purposes as opposed to system management purposes.
$ エンドユーザー1.（i）/情報システム/システムエンティティ、通常は人間の個人、システム管理の目的とは対照的に、システムリソースを利用しています。
2. (D) /PKI/ Synonym for "end entity".
2. （D）/ PKI /「エンドエンティティ」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use "end user" as a synonym for "end entity", because that would mix concepts in a potentially misleading way.
廃止予定の定義：IDocは「エンドエンティティ」の同義語として「エンドユーザー」を使用しないでください。
$ endorsed-for-unclassified cryptographic item (EUCI) (O) /U.S. Government/ "Unclassified cryptographic equipment that embodies a U.S. Government classified cryptographic logic and is endorsed by NSA for the protection of national security information." [C4009] (Compare: CCI, type 2 product.)
$ 未分類暗号化品（euci）/ us.政府/「米国政府に分類された暗号化論理を具現化し、国内のセキュリティ情報の保護のためにNSAによって承認されていない暗号化されていない機器」。[C4009]（比較：CCI、Type 2製品）
$ entity See: system entity.
$ エンティティ参照：システムエンティティ。
$ entrapment (I) "The deliberate planting of apparent flaws in a system for the purpose of detecting attempted penetrations or confusing an intruder about which flaws to exploit." [FP039] (See: honey pot.)
$ 閉じ込められた浸透を検出すること、または侵入者を侵入するための侵入者を混乱させることを目的とした、または侵入者を混乱させることを目的としたシステム内の見かけの欠陥の意図的な植栽。」[FP039]（参照：蜂蜜ポット。）
$ entropy 1. (I) An information-theoretic measure (usually stated as a number of bits) of the amount of uncertainty that an attacker faces to determine the value of a secret. [SP63] (See: strength.)
$ Entropy 1.（i）攻撃者が秘密の価値を決定するために顔が直面する不確実性の量の情報理論的尺度（通常、ビット数として記載されています）。[SP63]（See：強さを参照）
Example: If a password is said to contain at least 20 bits of entropy, that means that it must be as hard to find the password as to guess a 20-bit random number.
例：パスワードが少なくとも20ビットのエントロピーを含むと言われている場合、それはそれが20ビットの乱数を推測するようにパスワードを見つけるのが難しいことである必要があることを意味します。
2. (I) An information-theoretic measure (usually stated as a number of bits) of the amount of information in a message; i.e., the minimum number of bits needed to encode all possible meanings of that message. [Schn] (See: uncertainty.)
2. （i）メッセージ内の情報量の情報理論的尺度（通常、ビット数として記載されている）。すなわち、そのメッセージのすべての可能な意味を符号化するのに必要な最小ビット数。[SCHN]（参照：不確実性。）
$ ephemeral (I) /adjective/ Refers to a cryptographic key or other cryptographic parameter or data object that is short-lived, temporary, or used one time. (See: session key. Compare: static.)
$ エフェメラル（i）/形容詞/短期間、一時的な、または1回使用されている暗号鍵または他の暗号化パラメータまたはデータオブジェクトを指す。（セッションキーを参照してください。比較：静的。）
$ erase 1. (I) Delete stored data. (See: sanitize, zeroize.)
$ （i）格納されているデータを削除します。（：サニタイズ、ゼロ化を参照してください。）
2. (O) /U.S. Government/ Delete magnetically stored data in such a way that the data cannot be recovered by ordinary means, but might be recoverable by laboratory methods. [C4009] (Compare: /U.S. Government/ purge.)
2. （O）/U.S。政府/データを通常の手段で回収できないように磁気的に記憶されたデータを削除するが、実験室の方法で回復可能である可能性がある。[C4009]（比較：/政府/パージ）
$ error detection code (I) A checksum designed to detect, but not correct, accidental (i.e., unintentional) changes in data.
$ エラー検出コード（i）データの変更を検出するが、誤って、誤って、正しくない、正しくない、そうではないチェックサム。
$ Escrowed Encryption Standard (EES) (N) A U.S. Government standard [FP185] that specifies how to use a symmetric encryption algorithm (SKIPJACK) and create a Law Enforcement Access Field (LEAF) for implementing part of a key escrow system that enables decryption of telecommunications when interception is lawfully authorized.
$ ESSCROWED暗号化規格（EES）（N）対称暗号化アルゴリズム（SkipJack）の使用方法を指定し、復号化を可能にするキーエスクローシステムの一部を実装するための法執行アクセスフィールド（リーフ）を作成する米国政府標準[FP185]傍受が合法的に許可されている場合の電気通信。
Tutorial: Both SKIPJACK and the LEAF are intended for use in equipment used to encrypt and decrypt sensitive, unclassified, telecommunications data.
チュートリアル：SkipjackとLeafの両方が、機密性、身体範囲外、電気通信データの暗号化および復号化に使用される機器での使用を目的としています。
$ ESP (I) See: Encapsulating Security Payload.
$ ESP（I）：セキュリティペイロードのカプセル化。
$ Estelle (N) A language (ISO 9074-1989) for formal specification of computer network protocols.
$ ESTELLE（N）コンピュータネットワークプロトコルの正式な仕様のための言語（ISO 9074-1989）。
$ ETSI (N) See: European Telecommunication Standards Institute.
$ ETSI（N）はヨーロッパの電気通信基準研究所を参照してください。
$ EUCI (O) See: endorsed-for-unclassified cryptographic item.
$ euci（o）承認されていない暗号化項目を参照してください。
$ European Telecommunication Standards Institute (ETSI) (N) An independent, non-profit organization, based in France, that is officially recognized by the European Commission and responsible for standardization of information and communication technologies within Europe.
$ 欧州電気通信基準研究所（N）フランスに拠点を置く独立した非営利団体、それは欧州委員会によって正式に認識され、ヨーロッパ内の情報通信技術の標準化を担当します。
Tutorial: ETSI maintains the standards for a number of security algorithms, including encryption algorithms for mobile telephone systems in Europe.
チュートリアル：ETSIは、ヨーロッパの携帯電話システムのための暗号化アルゴリズムを含む、多くのセキュリティアルゴリズムの標準を維持しています。
$ evaluated system (I) A system that has been evaluated against security criteria (for example, against the TCSEC or against a profile based on the Common Criteria).
$ 評価システム（i）セキュリティ基準に対して評価されたシステム（例えば、TCSECに対して、または共通の基準に基づくプロファイルに対して）。
$ evaluation (I) Assessment of an information system against defined security criteria (for example, against the TCSEC or against a profile based on the Common Criteria). (Compare: certification.)
$ 評価（i）定義されたセキュリティ基準に対する情報システムの評価（例えば、TCSECに対して、または共通の基準に基づくプロファイルに対する）。（Compare：認定。）
$ evaluation assurance level (EAL) (N) A predefined package of assurance components that represents a point on the Common Criteria's scale for rating confidence in the security of information technology products and systems.
$ 評価保証レベル（EAL）（n）情報技術製品およびシステムのセキュリティへの信頼性に対する信頼性を評価するための一般的な基準のスケールの点を表す保証コンポーネントの事前定義されたパッケージ。
Tutorial: The Common Criteria defines a scale of seven, hierarchically ordered EALs for rating a TOE. From highest to lowest, they are as follows: - EAL7. Formally verified design and tested. - EAL6. Semiformally verified design and tested. - EAL5. Semiformally designed and tested. - EAL4. Methodically designed, tested, and reviewed. - EAL3. Methodically tested and checked. - EAL2. Structurally tested. - EAL1. Functionally tested.
チュートリアル：一般的な基準は、TOEを評価するための7のスケールで、階層的に順序付けられたEALSを定義します。最高から最も低い、それらは次のとおりです。 - EAL7。正式に検証されたデザインとテスト済み。 - EAL6。セミフォーム検証済みの設計とテスト済み。 - EAL5。ご容赦なく設計されテストされています。 - EAL4。方法で設計、テスト、およびレビュー。 - EAL3。方法でテストされチェックされています。 - EAL2。構造的にテストされます。 - EAL1。機能的にテストされます。
An EAL is a consistent, baseline set of requirements. The increase in assurance from EAL to EAL is accomplished by substituting higher assurance components (i.e., criteria of increasing rigor, scope, or depth) from seven assurance classes: (a) configuration management, (b) delivery and operation, (c) development, (d) guidance documents, (e) lifecycle support, (f) tests, and (g) vulnerability assessment.
EALは一貫したベースラインの要件のセットです。EALからEALへの保証の増加は、7つの保証クラスからより高い保証成分（すなわち、厳密な厳格、範囲、または深さの基準）を代入することによって達成される。（a）構成管理、（B）配信および運用、（C）開発、（D）ガイダンス文書、（E）ライフサイクルサポート、（F）テスト、および（G）脆弱性評価。
The EALs were developed with the goal of preserving concepts of assurance that were adopted from earlier criteria, so that results of previous evaluations would remain relevant. For example, EALs levels 2-7 are generally equivalent to the assurance portions of the TCSEC C2-A1 scale. However, this equivalency should be used with caution. The levels do not derive assurance in the same manner, and exact mappings do not exist.
以前の評価の結果は関連性が低いほど関連があると思われるので、以前の評価の結果が依然として関連したままになるように、EALSは開発されました。例えば、EARSレベル2~7は一般にTCSEC C2 - A1スケールの保証部分と等価である。ただし、この等価性は注意して使用する必要があります。レベルは同じ方法で保証を導きません。正確なマッピングは存在しません。
$ expire (I) /credential/ Cease to be valid (i.e., change from being valid to being invalid) because its assigned lifetime has been exceeded. (See: certificate expiration.)
$ 割り当てられたライフタイムが超えられているため、有効（i）/信任状/が有効（すなわち無効になることから無効の変更）を実行します。（参照：証明書の有効期限を参照してください。）
$ exposure (I) A type of threat action whereby sensitive data is directly released to an unauthorized entity. (See: unauthorized disclosure.)
$ 露出（i）機密データが不正なエンティティに直接解放される脅威動作の一種。（未承認の開示を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Deliberate Exposure": Intentional release of sensitive data to an unauthorized entity. - "Scavenging": Searching through data residue in a system to gain unauthorized knowledge of sensitive data. - "Human error": /exposure/ Human action or inaction that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.) - "Hardware or software error": /exposure/ System failure that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.)
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「意図的な露出」：不正なエンティティへの機密データの意図的な解放。 - 「掃気」：システム内のデータ残差を検索して、機密データの不正な知識を得るために。 - 「ヒューマンエラー」：/露出/人間の行動または不作為では、意図せずに機密データに関する不正な知識を得た企業が発生します。（比較：破損、無益） - 「ハードウェアまたはソフトウェアのエラー」：/露出/システムの障害では、意図せずに機密データの不正な知識を得たエンティティをもたらす。（比較：破損、無益）
$ Extended Security Option (I) See: secondary definition under "IPSO".
$ 拡張セキュリティオプション（i） "IPSO"の下のセカンダリ定義。
$ Extensible Authentication Protocol (EAP) (I) An extension framework for PPP that supports multiple, optional authentication mechanisms, including cleartext passwords, challenge-response, and arbitrary dialog sequences. [R3748] (Compare: GSS-API, SASL.)
$ Extensible Authentication Protocol（EAP）（i）クリアテキストパスワード、チャレンジレスポンス、および任意のダイアログシーケンスを含む、複数のオプションの認証メカニズムをサポートするPPPの拡張フレームワーク。[R3748]（比較：GSS-API、SASL）
Tutorial: EAP typically runs directly over IPS data link protocols or OSIRM Layer 2 protocols, i.e., without requiring IP. Originally, EAP was developed for use in PPP, by a host or router that connects to a network server via switched circuits or dial-up lines. Today, EAP's domain of applicability includes other areas of network access control; it is used in wired and wireless LANs with IEEE 802.1X, and in IPsec with IKEv2. EAP is conceptually related to other authentication mechanism frameworks, such as SASL and GSS-API.
チュートリアル：EAPは通常、IPSデータリンクプロトコルまたはOSIRMレイヤ2プロトコル、すなわちIPを必要とせずに直接実行される。元々、IEAPは、スイッチ付き回線またはダイヤルアップラインを介してネットワークサーバーに接続するホストまたはルーターによって、PPPで使用するために開発されました。今日、EAPの適用可能性のあるドメインには、ネットワークアクセス制御の他の分野が含まれています。それはIEEE 802.1xを持つ有線および無線LANで、IPSecでIPSECで使用されています。EAPは、SASLやGSS-APIなどの他の認証メカニズムフレームワークに概念的に関連しています。
$ Extensible Markup Language (XML) (N) A version of Standard Generalized Markup Language (ISO 8879) that separately represents a document's content and its structure. XML was designed by W3C for use on the World Wide Web.
$ Extensible Markup Language（XML）（n）個別に文書の内容とその構造を表す標準一般化マークアップ言語のバージョン（ISO 8879）。XMLは、World Wide Web上で使用するためにW3Cによって設計されました。
$ extension (I) /protocol/ A data item or a mechanism that is defined in a protocol to extend the protocol's basic or original functionality.
$ 延長（i）/プロトコル/データ項目またはプロトコルの基本的な機能または元の機能を拡張するためのプロトコルで定義されているメカニズム。
Tutorial: Many protocols have extension mechanisms, and the use of these extension is usually optional. IP and X.509 are two examples of protocols that have optional extensions. In IP version 4, extensions are called "options", and some of the options have security purposes (see: IPSO).
チュートリアル：多くのプロトコルには拡張メカニズムがあり、これらの拡張機能の使用は通常オプションです。IPとX.509は、オプションの拡張機能を持つプロトコルの例です。IPバージョン4では、拡張機能は「オプション」と呼ばれ、いくつかのオプションにセキュリティ上のものがあります（IPSOを参照）。
In X.509, certificate and CRL formats can be extended to provide methods for associating additional attributes with subjects and public keys and for managing a certification hierarchy: - A "certificate extension": X.509 defines standard extensions that may be included in v3 certificates to provide additional key and security policy information, subject and issuer attributes, and certification path constraints. - A "CRL extension": X.509 defines extensions that may be included in v2 CRLs to provide additional issuer key and name information, revocation reasons and constraints, and information about distribution points and delta CRLs.
X.509では、証明書とCRLの形式を拡張して、追加の属性をサブジェクトとパブリックキーと関連付ける方法を提供し、認定階層を管理するためのメソッドを提供することができます。 - 「証明書拡張」：X.509はV3に含まれている可能性がある標準拡張機能を定義します。追加のキーとセキュリティポリシー情報、サブジェクトおよび発行者の属性、および認証パスの制約を提供する証明書。 - 「CRL Extension」：X.509は、追加の発行者鍵と名前情報、失効上の理由、および制約、および配布ポイントおよびデルタCRLに関する情報を提供するためのV2 CRLに含まれ得る拡張機能を定義します。
- A "private extension": Additional extensions, each named by an OID, can be locally defined as needed by applications or communities. (See: Authority Information Access extension, SET private extensions.)
- 「Private Extension」：それぞれOIDによって指定された追加の拡張機能は、アプリケーションまたはコミュニティによって必要に応じてローカルに定義できます。（注意事項：権限情報のアクセス拡張、プライベート拡張機能を設定します。）
$ external controls (I) /COMPUSEC/ Refers to administrative security, personnel security, and physical security. (Compare: internal controls.)
$ 外部コントロール（I）/ CompUsec /管理セキュリティ、人事セキュリティ、および物理的セキュリティを指します。（比較：内部統制）
$ extranet (I) A computer network that an organization uses for application data traffic between the organization and its business partners. (Compare: intranet.)
$ ExtraNet（i）組織が組織とそのビジネスパートナー間のアプリケーションデータトラフィックに使用するコンピュータネットワーク。（比較：イントラネット。）
Tutorial: An extranet can be implemented securely, either on the Internet or using Internet technology, by constructing the extranet as a VPN.
チュートリアル：ExtraNetをVPNとして構成することで、インターネット上でもインターネットテクノロジを使用して、エクストラネットを安全に実装できます。
$ extraction resistance (O) Ability of cryptographic equipment to resist efforts to extract keying material directly from the equipment (as opposed to gaining knowledge of keying material by cryptanalysis). [C4009]
$ 抽出抵抗（O）暗号化装置の能力（暗号分析による鍵材料の知識を得るのは）機器から直接捕捉材料を抽出するための努力に抵抗する能力。[C4009]
$ extrusion detection (I) Monitoring for unauthorized transfers of sensitive information and other communications that originate inside a system's security perimeter and are directed toward the outside; i.e., roughly the opposite of "intrusion detection".
$ 押出検出（i）機密情報の不正転送およびシステムのセキュリティ周辺の内部に発生し、外部に向けられている他の通信のための監視。すなわち、「侵入検知」のほぼ逆。
$ fail-safe 1. (I) Synonym for "fail-secure".
$ Fail-Safe 1.（i）「フェイルセキュア」の同義語。
2. (I) A mode of termination of system functions that prevents damage to specified system resources and system entities (i.e., specified data, property, and life) when a failure occurs or is detected in the system (but the failure still might cause a security compromise). (See: failure control.)
2. （i）システム内で障害が発生したときに特定のシステムリソースおよびシステムエンティティ（すなわち、指定されたデータ、プロパティ、および寿命）の損傷を防止するシステム機能の終了モード（でも障害が生じている可能性があります。妥協）。（障害管理を参照してください。）
Tutorial: Definitions 1 and 2 are opposing design alternatives. Therefore, IDOCs SHOULD NOT use this term without providing a definition for it. If definition 1 is intended, IDOCs can avoid ambiguity by using "fail-secure" instead.
チュートリアル：定義1と2は反対のデザインの選択肢です。したがって、IDocは定義を提供することなくこの用語を使用しないでください。定義1が意図されている場合、IDocは代わりに「フェールセキュア」を使用してあいまいさを避けることができます。
$ fail-secure (I) A mode of termination of system functions that prevents loss of secure state when a failure occurs or is detected in the system (but the failure still might cause damage to some system resource or system entity). (See: failure control. Compare: fail-safe.)
$ フェイルセキュリティ（i）システム内で障害が発生したときにセキュア状態の損失を防ぐシステム機能の終了モード（ただし、システムリソースまたはシステムエンティティに損傷を与える可能性があります）。（障害管理を参照してください。比較：フェイルセーフ）
$ fail-soft (I) Selective termination of affected, non-essential system functions when a failure occurs or is detected in the system. (See: failure control.)
$ fail-soft（i）障害が発生したとき、またはシステム内で検出されたときの影響を受ける非必須システム関数の選択的終端。（障害管理を参照してください。）
$ failure control (I) A methodology used to provide fail-safe, fail-secure or fail-soft termination and recovery of system functions. [FP039]
$ 失敗制御（i）フェイルセーフ、フェイルセキュリティまたはフェイルソフトの終了およびシステム機能の回復を提供するために使用される方法論。[FP039]
$ fairness (I) A property of an access protocol for a system resource whereby the resource is made equitably or impartially available to all eligible users. (RFC 3753)
$ 公平性（i）システムリソースのためのアクセスプロトコルのプロパティは、リソースがすべての適格ユーザーに公平または公平に利用可能にされます。（RFC 3753）
Tutorial: Fairness can be used to defend against some types of denial-of-service attacks on a system connected to a network. However, this technique assumes that the system can properly receive and process inputs from the network. Therefore, the technique can mitigate flooding but is ineffective against jamming.
チュートリアル：公平性は、ネットワークに接続されているシステムに対する一種のサービス拒否攻撃に対して守るために使用できます。しかしながら、この技術は、システムがネットワークからの入力を正しく受信して処理することができると仮定している。したがって、この技術はフラッディングを軽減することができますが、妨害に対しては効果がありません。
$ falsification (I) A type of threat action whereby false data deceives an authorized entity. (See: active wiretapping, deception.)
$ 改ざん（i）誤ったデータが許可されたエンティティを欺く脅威アクションの一種です。（積極的な盗聴、詐欺を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Substitution": Altering or replacing valid data with false data that serves to deceive an authorized entity. - "Insertion": Introducing false data that serves to deceive an authorized entity.
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「置換」：許可されたエンティティを欺くのに役立つ誤ったデータを含む有効なデータの変更または置換。 - "挿入"：承認されたエンティティを欺くための誤ったデータを紹介します。
$ fault tree (I) A branching, hierarchical data structure that is used to represent events and to determine the various combinations of component failures and human acts that could result in a specified undesirable system event. (See: attack tree, flaw hypothesis methodology.)
$ 障害ツリー（i）イベントを表現するために使用される分岐、階層データ構造と、指定された望ましくないシステムイベントをもたらす可能性があるコンポーネントの障害と人間のさまざまな組み合わせを決定します。（攻撃木、傷の仮説方法論を参照してください。）
Tutorial: "Fault-tree analysis" is a technique in which an undesired state of a system is specified and the system is studied in the context of its environment and operation to find all credible ways in which the event could occur. The specified fault event is represented as the root of the tree. The remainder of the tree represents AND or OR combinations of subevents, and sequential combinations of subevents, that could cause the root event to occur. The main purpose of a fault-tree analysis is to calculate the probability of the root event, using statistics or other analytical methods and incorporating actual or predicted quantitative reliability and maintainability data. When the root event is a security violation, and some of the subevents are deliberate acts intended to achieve the root event, then the fault tree is an attack tree.
チュートリアル：「フォールトツリー分析」は、システムの望ましくない状態を指定し、その環境と操作の文脈で検討され、イベントが発生する可能性のあるすべての方法を見つけます。指定された障害イベントはツリーのルートとして表されます。ツリーの残りの部分は、ルートイベントが発生する可能性があるサブイベントのサブイベント、および順次組み合わせを表します。故障木分析の主な目的は、統計または他の分析方法を使用して、根本事象の確率を計算し、実際のまたは予測された定量的信頼性および保守性データを組み込むことです。ルートイベントがセキュリティ違反であり、一部のサブイベントがルートイベントを実現することを目的とした故意の行為である場合、障害ツリーは攻撃ツリーです。
$ FEAL (O) A family of symmetric block ciphers that was developed in Japan; uses a 64-bit block, keys of either 64 or 128 bits, and a variable number of rounds; and has been successfully attacked by cryptanalysts. [Schn]
$ 日本で開発された対称ブロック暗号のファミリー（O）64ビットブロック、64または128ビットのキー、および可変数のラウンドを使用します。そして暗号麻痺者によってうまく攻撃されました。[シュン]
$ Federal Information Processing Standards (FIPS) (N) The Federal Information Processing Standards Publication (FIPS PUB) series issued by NIST under the provisions of Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987 (Public Law 100-235) as technical guidelines for U.S. Government procurements of information processing system equipment and services. (See: "[FPxxx]" items in Section 7, Informative References.)
$ 連邦情報処理基準（FIPS）（N）連邦財産法第111条（D）の規定に基づきNISTが発行した連邦情報処理基準版（FIPS PUB）シリーズ（D）1949年の行政法第1949条情報処理システム機器およびサービスの米国政府調達のための技術ガイドラインとして、1987年（公的法100-235）。（以下「「FPXXX」」の項目7、有益な参考文献の項目。
$ Federal Public-key Infrastructure (FPKI) (O) A PKI being planned to establish facilities, specifications, and policies needed by the U.S. Government to use public-key certificates in systems involving unclassified but sensitive applications and interactions between Federal agencies as well as with entities of state and local governments, the business community, and the public. [FPKI]
$ 連邦公開基準インフラ（FPKI）（o）米国政府が米国政府が必要とする施設、仕様、および政策を制定することを計画されている。州および地方自治体、ビジネスコミュニティ、そして一般の企業。[FPKI]
$ Federal Standard 1027 (N) An U.S. Government document defining emanation, anti-tamper, security fault analysis, and manual key management criteria for DES encryption devices, primary for OSIRM Layer 2. Was renamed "FIPS PUB 140" when responsibility for protecting unclassified, sensitive information was transferred from NSA to NIST, and has since been superseded by newer versions of that standard [FP140].
$ Federal Standard 1027（n）Encirm Layerのプライマリを保護する責任がある場合、米国の暗号化デバイスのエンマンテーション、アンチタンパー、セキュリティ障害分析、および手動キー管理基準を定義しています。機密情報はNSAからNISTに転送され、その標準の新しいバージョンがより新しいバージョンで置き換えられました[FP140]。
$ File Transfer Protocol (FTP) (I) A TCP-based, Application-Layer, Internet Standard protocol (RFC 959) for moving data files from one computer to another.
$ ファイル転送プロトコル（FTP）（i）データファイルをあるコンピュータから別のコンピュータに移動するためのTCPベースのアプリケーション層、インターネット標準プロトコル（RFC 959）。
$ fill device (N) /COMSEC/ A device used to transfer or store keying material in electronic form or to insert keying material into cryptographic equipment.
$ 充填装置（N）/ COMSEC /電子形式でキーイング材料を転送または保存するために使用される装置または暗号化装置にキーインストール材料を挿入するために使用される装置。
$ filter 1. (I) /noun/ Synonym for "guard". (Compare: content filter, filtering router.) 2. (I) /verb/ To process a flow of data and selectively block passage or permit passage of individual data items according to a security policy.
$ FILTER 1.（i）/名詞/「GUARD」の同義語。（コンテンツフィルタ、フィルタリングルータ。）2。（i）/ verb /データの流れを処理し、セキュリティポリシーに従って個々のデータ項目の通過を選択的にブロックまたは許可する。
$ filtering router (I) An internetwork router that selectively prevents the passage of data packets according to a security policy. (See: guard.)
$ フィルタリングルータ（i）セキュリティポリシーに従ってデータパケットの通過を選択的に防止するインターネットワークルータ。（：警備員を参照してください。）
Tutorial: A router usually has two or more physical connections to networks or other systems; and when the router receives a packet on one of those connections, it forwards the packet on a second connection. A filtering router does the same; but it first decides, according to some security policy, whether the packet should be forwarded at all. The policy is implemented by rules (packet filters) loaded into the router. The rules mostly involve values of data packet control fields (especially IP source and destination addresses and TCP port numbers) [R2179]. A filtering router may be used alone as a simple firewall or be used as a component of a more complex firewall.
チュートリアル：ルータは通常、ネットワークまたは他のシステムへの2つ以上の物理接続を持ちます。そして、ルータがそれらの接続のうちの1つにパケットを受信すると、パケットを2番目の接続に転送します。フィルタリングルータは同じです。しかし、それは最初にセキュリティポリシーに従って、パケットがまったく転送されるべきかどうかを決定します。ポリシーは、ルータにロードされたルール（パケットフィルタ）によって実装されています。規則は、データパケット制御フィールド（特にIP送信元と宛先アドレスとTCPポート番号）の値の値をほとんど含みます[R2179]。フィルタリングルータは、単純なファイアウォールとして単独で使用されてもよく、またはより複雑なファイアウォールのコンポーネントとして使用されてもよい。
$ financial institution (N) "An establishment responsible for facilitating customer-initiated transactions or transmission of funds for the extension of credit or the custody, loan, exchange, or issuance of money." [SET2]
$ 金融機関（N） "顧客が開始した取引を促進する責任を担うか、信用の延長、債権、融資、交換、または発行の発行のための資金の伝達を促進します。」[SET2]
$ fingerprint 1. (I) A pattern of curves formed by the ridges on a fingertip. (See: biometric authentication. Compare: thumbprint.)
$ 指紋1.（i）指先の隆起部によって形成された曲線のパターン。（バイオメトリック認証を参照してください。比較：拇印を参照してください。）
2. (D) /PGP/ A hash result ("key fingerprint") used to authenticate a public key or other data. [PGP]
2. （D）/ PGP / A HASH結果（「キー指紋」）公開鍵またはその他のデータを認証するために使用されます。[PGP]
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2, and SHOULD NOT use this term as a synonym for "hash result" of *any* kind. Either use would mix concepts in a potentially misleading way.
廃止予定の定義：IDocは定義2でこの用語を使用しないでください。どちらの使用も潜在的に誤解を招くような方法で混在するでしょう。
$ FIPS (N) See: Federal Information Processing Standards.
$ FIPS（N）参照：連邦情報処理基準を参照してください。
$ FIPS PUB 140 (N) The U.S. Government standard [FP140] for security requirements to be met by a cryptographic module when the module is used to protect unclassified information in computer and communication systems. (See: Common Criteria, FIPS, Federal Standard 1027.) Tutorial: The standard specifies four increasing levels (from "Level 1" to "Level 4") of requirements to cover a wide range of potential applications and environments. The requirements address basic design and documentation, module interfaces, authorized roles and services, physical security, software security, operating system security, key management, cryptographic algorithms, electromagnetic interference and electromagnetic compatibility (EMI/EMC), and self-testing. NIST and the Canadian Communication Security Establishment jointly certify modules.
$ FIPS PUB 140（N）コンピュータおよび通信システムにおける未分類の情報を保護するために使用されるときに、暗号モジュールによって満たされるべきセキュリティ要件のための米国政府標準[FP140]。（参照：一般的な基準、FIPS、Federal Standard 1027.）チュートリアル：標準は、幅広い潜在的なアプリケーションや環境をカバーするための4つの増加レベル（「レベル1」から「レベル4」まで）を指定します。要件は、基本的な設計と文書化、モジュールのインタフェース、承認された役割、サービス、物理的なセキュリティ、ソフトウェアセキュリティ、オペレーティングシステムのセキュリティ、鍵管理、暗号化アルゴリズム、電磁干渉と電磁互換性（EMI / EMC）、および自己テストです。NISTとカナダの通信セキュリティ設立は、モジュールを共同で認証します。
$ FIREFLY (O) /U.S. Government/ "Key management protocol based on public-key cryptography." [C4009]
$ ホタル（O）/U.S。政府/「公開鍵暗号化に基づく鍵管理プロトコル」[C4009]
$ firewall 1. (I) An internetwork gateway that restricts data communication traffic to and from one of the connected networks (the one said to be "inside" the firewall) and thus protects that network's system resources against threats from the other network (the one that is said to be "outside" the firewall). (See: guard, security gateway.)
$ Firewall 1.（i）接続されているネットワークのいずれか（言われているものの内側にあるもの）との間のデータ通信トラフィックを制限し、したがって他のネットワークからの脅威に対するネットワークのシステムリソースを保護するインターネットワークゲートウェイ。それは「ファイアウォールの外」と言われています）。（：ガード、セキュリティゲートウェイ。）
2. (O) A device or system that controls the flow of traffic between networks using differing security postures. [SP41]
2. （O）異なるセキュリティ姿勢を使用してネットワーク間のトラフィックの流れを制御する装置またはシステム。[SP41]
Tutorial: A firewall typically protects a smaller, secure network (such as a corporate LAN, or even just one host) from a larger network (such as the Internet). The firewall is installed at the point where the networks connect, and the firewall applies policy rules to control traffic that flows in and out of the protected network.
チュートリアル：ファイアウォールは通常、より大きなネットワーク（インターネットなど）から、より小さな、安全なネットワーク（企業LANなど、または1つのホストなど）を保護します。ファイアウォールは、ネットワークが接続する時点でインストールされ、ファイアウォールは保護されたネットワークの内外に流出するトラフィックを制御するためのポリシールールを適用します。
A firewall is not always a single computer. For example, a firewall may consist of a pair of filtering routers and one or more proxy servers running on one or more bastion hosts, all connected to a small, dedicated LAN (see: buffer zone) between the two routers. The external router blocks attacks that use IP to break security (IP address spoofing, source routing, packet fragments), while proxy servers block attacks that would exploit a vulnerability in a higher-layer protocol or service. The internal router blocks traffic from leaving the protected network except through the proxy servers. The difficult part is defining criteria by which packets are denied passage through the firewall, because a firewall not only needs to keep unauthorized traffic (i.e., intruders) out, but usually also needs to let authorized traffic pass both in and out.
ファイアウォールは必ずしも単一のコンピュータではありません。例えば、ファイアウォールは、1対のフィルタリングルータと1つ以上のバスティオンホスト上で実行されている1つ以上のプロキシサーバとから構成されていてもよいし、2つのルータ間の小さな専用LAN（バッファゾーン）に接続されています。外部ルーターは、IPを使用してセキュリティを分割する攻撃（IPアドレスのなりすまし、送信元ルーティング、パケットフラグメント）をブロックしますが、プロキシサーバーは、上位層のプロトコルまたはサービスの脆弱性を悪用するであろう攻撃をブロックします。内部ルータは、プロキシサーバーを介してプロテクトネットワークを残してからトラフィックをブロックします。難しい部分は、ファイアウォールを通過するのが必要であるため、ファイアウォールはファイアウォールを通過する基準を定義しています。
$ firmware (I) Computer programs and data stored in hardware -- typically in read-only memory (ROM) or programmable read-only memory (PROM) -- such that the programs and data cannot be dynamically written or modified during execution of the programs. (See: hardware, software.)
$ ファームウェア（i）ハードウェアで保存されているコンピュータプログラムとデータ - 通常、読み取り専用メモリ（ROM）またはプログラマブル読み取り専用メモリ（PROM） - プログラムの実行中にプログラムとデータを動的に書き込んだり変更することができないような。（ハードウェア、ソフトウェアを参照してください。）
$ FIRST (N) See: Forum of Incident Response and Security Teams.
$ 最初の（n）インシデント対応とセキュリティチームのフォーラムを参照してください。
$ flaw 1. (I) An error in the design, implementation, or operation of an information system. A flaw may result in a vulnerability. (Compare: vulnerability.)
$ （i）情報システムの設計、実装、または操作の誤差。欠陥が発生する可能性があります。（比較：脆弱性）
2. (D) "An error of commission, omission, or oversight in a system that allows protection mechanisms to be bypassed." [NCSSG] (Compare: vulnerability. See: brain-damaged.)
2. （d）「保護メカニズムをバイパスすることを可能にするシステムにおける委員会、省略、または監督の誤差。」[NCSSG]（比較：脆弱性。脳損傷を参照してください。）
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2; not every flaw is a vulnerability.
廃止予定の定義：IDocは定義2でこの用語を使用しないでください。すべての欠陥が脆弱性ではありません。
$ flaw hypothesis methodology (I) An evaluation or attack technique in which specifications and documentation for a system are analyzed to hypothesize flaws in the system. The list of hypothetical flaws is prioritized on the basis of the estimated probability that a flaw exists and, assuming it does, on the ease of exploiting it and the extent of control or compromise it would provide. The prioritized list is used to direct a penetration test or attack against the system. [NCS04] (See: fault tree, flaw.)
$ 有効仮説方法論（I）システムの仕様と文書化をシステム内の欠陥を仮定するために分析する評価または攻撃技術。仮想的な欠陥のリストは、欠陥が存在する推定された確率に基づいて優先され、それがそれを活用しやすく、そしてそれを提供するか妥協の程度をもたらすだろうと仮定する。優先リストは、システムに対する侵入検査または攻撃を指示するために使用されます。[NCS04]（参照：障害ツリー、欠陥）
$ flooding 1. (I) An attack that attempts to cause a failure in a system by providing more input than the system can process properly. (See: denial of service, fairness. Compare: jamming.)
$ フラッディング1.（i）システムよりも多くの入力を提供することでシステムに障害が発生しようとする攻撃が適切に処理できます。（「サービス拒否、公平性」を参照してください。比較：Jamming。）
Tutorial: Flooding uses "overload" as a type of "obstruction" intended to cause "disruption".
チュートリアル：フラッディングは「中断」を引き起こすことを意図した「障害物」の種類として「過負荷」を使用します。
2. (I) The process of delivering data or control messages to every node of a network. (RFC 3753)
2. （i）ネットワークのすべてのノードにデータまたは制御メッセージを配信するプロセス。（RFC 3753）
$ flow analysis (I) An analysis performed on a nonprocedural, formal, system specification that locates potential flows of information between system variables. By assigning security levels to the variables, the analysis can find some types of covert channels. [Huff]
$ フロー分析（i）システム変数間の情報の潜在的な流れの流れを特定する非事実で正式なシステム仕様で実行された分析。セキュリティレベルを変数に割り当てることで、分析によっていくつかの種類のCovertチャネルがあります。[ハフ]
$ flow control 1. (I) /data security/ A procedure or technique to ensure that information transfers within a system are not made from one security level to another security level, and especially not from a higher level to a lower level. [Denns] (See: covert channel, confinement property, information flow policy, simple security property.)
$ フロー制御1.（i）/データセキュリティ/システム内の情報転送があるセキュリティレベルから別のセキュリティレベルまで、特に高いレベルから下位レベルへの情報転送を確実にするための手順または技術。[Denns]（参照：Covert Channel、Confinate Property、Information Flow Policy、Simple Security Property。）
2. (O) /data security/ "A concept requiring that information transfers within a system be controlled so that information in certain types of objects cannot, via any channel within the system, flow to certain other types of objects." [NCSSG]
2. （O）/ Data Security /「システム内の情報がシステム内の情報がシステム内の任意のチャネルを介して、他の種類のオブジェクトにフローできないように、システム内の情報転送を施す必要がある概念です。」[NCSSG]
$ For Official Use Only (FOUO) (O) /U.S. DoD/ A U.S. Government designation for information that has not been given a security classification pursuant to the criteria of an Executive Order dealing with national security, but which may be withheld from the public because disclosure would cause a foreseeable harm to an interest protected by one of the exemptions stated in the Freedom of Information Act (Section 552 of title 5, United States Code). (See: security label, security marking. Compare: classified.)
$ 公式使用のみ（FOU）/U.S。国家安全保障を扱う執行命令の基準に基づいてセキュリティ分類を与えられていないが、開示が施されている興味に害を及ぼす可能性があるため、DOD / A米国政府の指定。情報法の自由度に記載されている免除の場合（米国コードの第5章のセクション552）。（セキュリティラベル、セキュリティマーキングを参照してください。比較：分類しました。）
$ formal (I) Expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts. [CCIB] (Compare: informal, semiformal.)
$ 正式（i）は、確立された数学的概念に基づいて定義された意味論を持つ制限された構文言語で表現されています。[CCIB]（比較：非公式、半型）
$ formal access approval (O) /U.S. Government/ Documented approval by a data owner to allow access to a particular category of information in a system. (See: category.)
$ 正式アクセス承認（O）/U.S。システム内の特定のカテゴリの情報へのアクセスを許可するためのデータ所有者による政府/文書化された承認。（参照：カテゴリを参照してください。）
$ Formal Development Methodology (O) See: Ina Jo.
$ 正式な開発方法論（O）参照：INA JO。
$ formal model (I) A security model that is formal. Example: Bell-LaPadula model. [Land] (See: formal, security model.)
$ 正式なモデル（i）正式なセキュリティモデル。例：ベルラップラドゥラモデル[Land]（参照：正式な、セキュリティモデル。）
$ formal proof (I) "A complete and convincing mathematical argument, presenting the full logical justification for each step in the proof, for the truth of a theorem or set of theorems." [NCSSG]
$ 正式な証明（I）」は、定理または定理の組の真理のために、証明の各ステップの完全な論理的正当化を提示して、完全かつ説得力のある数学的議論を示しています。」[NCSSG]
$ formal specification (I) A precise description of the (intended) behavior of a system, usually written in a mathematical language, sometimes for the purpose of supporting formal verification through a correctness proof. [Huff] (See: Affirm, Gypsy, HDM, Ina Jo.) (See: formal.)
$正式な仕様（i）通常、正式な言語で書かれたシステムの（意図した）動作の正確な説明、時には正式な証明を通して正式な検証をサポートすることを目的としています。[huff]（参照：肯定、ジプシー、HDM、INA JO.）（「正式な」を参照）
Tutorial: A formal specification can be written at any level of detail but is usually a top-level specification.
チュートリアル：正式な仕様は、任意のレベルの詳細で書くことができますが、通常最上位の仕様です。
$ formal top-level specification (I) "A top-level specification that is written in a formal mathematical language to allow theorems showing the correspondence of the system specification to its formal requirements to be hypothesized and formally proven." [NCS04] (See: formal specification.)
$ 正式なトップレベルの仕様（i）「正式な数学的言語で書かれて、定理が仮定され、正式に証明されるという正式な要件に対するシステム仕様の対応を示す定理を認証できるようにする。[NCS04]（参照：正式な仕様参照）
$ formulary (I) A technique for enabling a decision to grant or deny access to be made dynamically at the time the access is attempted, rather than earlier when an access control list or ticket is created.
$ 定式（I）アクセス制御リストまたはチケットが作成されたときに、アクセスが試行される時点でアクセスが試行される時点でアクセスが行われることを決定するための手法を実行するための技術。
$ FORTEZZA(trademark) (O) A registered trademark of NSA, used for a family of interoperable security products that implement a NIST/NSA-approved suite of cryptographic algorithms for digital signature, hash, encryption, and key exchange. The products include a PC card (which contains a CAPSTONE chip), and compatible serial port modems, server boards, and software implementations.
$ Fortezza（登録商標）（o）デジタル署名、ハッシュ、暗号化、および鍵交換のためのNIST / NSA承認された暗号化アルゴリズムを実装する相互運用可能なセキュリティ製品の家族に使用されているNSAの登録商標。製品には、PCカード（キャプソンチップを含む）、互換性のあるシリアルポートモデム、サーバーボード、およびソフトウェアの実装が含まれます。
$ Forum of Incident Response and Security Teams (FIRST) (N) An international consortium of CSIRTs (e.g., CIAC) that work together to handle computer security incidents and promote preventive activities. (See: CSIRT, security incident.)
$ インシデント対応とセキュリティチーム（最初の）（N）コンピュータのセキュリティの事件を処理し、予防活動を促進するために協力して協力して働くCSIRTS（例えば、CIAC）の国際コンソーシアム。（参照：CSIRT、セキュリティ事件。）
Tutorial: FIRST was founded in 1990 and, as of July 2004, had more than 100 members spanning the globe. Its mission includes: - Provide members with technical information, tools, methods, assistance, and guidance. - Coordinate proactive liaison activities and analytical support. - Encourage development of quality products and services. - Improve national and international information security for governments, private industry, academia, and the individual. - Enhance the image and status of the CSIRT community.
チュートリアル：最初に1990年に設立され、2004年7月現在、100人以上のメンバーが世界中に及んでいました。その使命は以下を含みます： - 技術情報、ツール、方法、援助、そしてガイダンスを含むメンバーを提供します。 - 積極的な連絡活動と分析支援を調整します。 - 品質の製品やサービスの開発を奨励する。 - 政府、民間産業、学界、そして個人のための国内および国際的な情報セキュリティを改善する。 - CSIRTコミュニティのイメージとステータスを強化します。
$ forward secrecy (I) See: perfect forward secrecy.
$ 前方秘密（I）を参照してください。完璧な前進秘密。
$ FOUO (O) See: For Official Use Only.
$ fouo（o）参照：公式使用のみ。
$ FPKI (O) See: Federal Public-Key Infrastructure.
$ fpki（o）連邦公開鍵インフラストラクチャ：
$ fraggle attack (D) /slang/ A synonym for "smurf attack".
$ フラグル攻撃（D）/ SLANG /「SMURF攻撃」の同義語。
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term.
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。
Derivation: The Fraggles are a fictional race of small humanoids (represented as hand puppets in a children's television series, "Fraggle Rock") that live underground.
派生：亀裂は小さなヒューマノイドの架空の人種です（子供のテレビシリーズのハンド人形として表現されている、「フラグルロック」）地下に住んでいます。
$ frequency hopping (N) Repeated switching of frequencies during radio transmission according to a specified algorithm. [C4009] (See: spread spectrum.)
$ 周波数ホッピング（n）指定されたアルゴリズムに従って無線送信中の周波数の切り替えを繰り返します。[C4009]（スペプトスペクトルを参照してください。）
Tutorial: Frequency hopping is a TRANSEC technique to minimize the potential for unauthorized interception or jamming.
チュートリアル：周波数ホッピングは、不正な傍受または妨害の可能性を最小限に抑えるためのトランコン技術です。
$ fresh (I) Recently generated; not replayed from some earlier interaction of the protocol.
$ 最近生成された新鮮な（i）プロトコルの以前の対話から再生されません。
Usage: Describes data contained in a PDU that is received and processed for the first time. (See: liveness, nonce, replay attack.)
使用法：初めて受信および処理されたPDUに含まれるデータを説明します。（Livity、Nonce、Replay Attack。）
$ FTP (I) See: File Transfer Protocol.
$ ftp（i）ファイル転送プロトコルを参照してください。
$ gateway (I) An intermediate system (interface, relay) that attaches to two (or more) computer networks that have similar functions but dissimilar implementations and that enables either one-way or two-way communication between the networks. (See: bridge, firewall, guard, internetwork, proxy server, router, and subnetwork.)
$ ゲートウェイ（i）同様の機能であるが異なる実装を持つ2つの（またはそれ以上）のコンピュータネットワークに付着し、ネットワーク間の一方向または双方向通信を可能にする中間システム（インタフェース、リレー）。（ブリッジ、ファイアウォール、ガード、インターネットワーク、プロキシサーバー、ルータ、サブネットワーク。）
Tutorial: The networks may differ in any of several aspects, including protocols and security mechanisms. When two computer networks differ in the protocol by which they offer service to hosts, a gateway may translate one protocol into the other or otherwise facilitate interoperation of hosts (see: Internet Protocol). In theory, gateways between computer networks are conceivable at any OSIRM layer. In practice, they usually operate at OSIRM Layer 2 (see: bridge), 3 (see: router), or 7 (see: proxy server).
チュートリアル：ネットワークは、プロトコルとセキュリティメカニズムなど、いくつかの側面のいずれかによって異なる場合があります。2つのコンピュータネットワークがホストへのサービスを提供するプロトコルが異なる場合、ゲートウェイは1つのプロトコルを他のプロトコルに変換することができ、あるいはホストの相互運用を容易にすることができます（インターネットプロトコルを参照）。理論的には、コンピュータネットワーク間のゲートウェイが任意のOSIRR層で考えられる。実際には、それらは通常OSIRMレイヤ2（Bridge）、3（参照：ルータ）、または7（参照：プロキシサーバ）で動作します。
$ GCA (O) See: geopolitical certificate authority.
$ GCA（O）：地政学的な認証局。
$ GDOI (O) See: Group Domain of Interpretation.
$ gdoi（o）解釈のグループドメインを参照してください。
$ GeldKarte (O) A smartcard-based, electronic money system that is maintained by the German banking industry, incorporates cryptography, and can be used to make payments via the Internet. (See: IOTP.)
$ Geldkarte（o）ドイツの銀行業界によって維持されているスマートカードベースの電子マネーシステムを、暗号化を取り入れ、インターネットを介して支払いをするために使用することができます。（参照：iotp。）
$ GeneralizedTime (N) The ASN.1 data type "GeneralizedTime" (ISO 8601) contains a calendar date (YYYYMMDD) and a time of day, which is either (a) the local time, (b) the Coordinated Universal Time, or (c) both the local time and an offset that enables Coordinated Universal Time to be calculated. (See: Coordinated Universal Time. Compare: UTCTime.)
$ 一般化時間（n）ASN.1データ型 "generalizeTime"（ISO 8601）には、カレンダー日付（YYYYMMDD）と時刻が含まれています。これは、（a）現地時間、（b）協定されたユニバーサルタイム、または（c）協調世界時間を算出することを可能にする現地時間とオフセットの両方。（協定ユニバーサル時間を参照してください。比較：utctime。）
$ Generic Security Service Application Program Interface (GSS-API) (I) An Internet Standard protocol [R2743] that specifies calling conventions by which an application (typically another communication protocol) can obtain authentication, integrity, and confidentiality security services independently of the underlying security mechanisms and technologies, thus enabling the application source code to be ported to different environments. (Compare: EAP, SASL.)
$ Generic Security Serviceアプリケーションプログラムインタフェース（gss-api）（i）アプリケーション（通常別の通信プロトコル）が、基礎となるセキュリティとは無関係に認証、整合性、および機密保持セキュリティサービスを受信できる通話規則を指定するインターネット標準プロトコル[R2743]メカニズムと技術、したがって、アプリケーションのソースコードをさまざまな環境に移植することができます。（比較：EAP、SASL。）
Tutorial: "A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on [symmetric] and [asymmetric cryptography]." [R2743]
チュートリアル： "GSS-API呼び出し側は、そのローカルのGSS-API実装によって提供されたトークンを受け入れ、トークンをリモートシステムのピアに転送します。そのピアは、受信したトークンをそのローカルのGSS-API実装に処理するためにそのピアを渡します。セキュリティこの方法でGSS-APIから入手可能なサービスは、[対称]と[非対称暗号]に基づく範囲の基礎となるメカニズムにわたって実装可能な（そして実装されています）。[R2743]
$ geopolitical certificate authority (GCA) (O) /SET/ In a SET certification hierarchy, an optional level that is certified by a BCA and that may certify cardholder CAs, merchant CAs, and payment gateway CAs. Using GCAs enables a brand to distribute responsibility for managing certificates to geographic or political regions, so that brand policies can vary between regions as needed.
$ 地域認証局（GCA）（O）/セット/セット/セット/セット認証階層、BCAによって認証されているオプションレベル、カード会員CAS、マーチャントCAS、および支払いゲートウェイCASを認証することができます。GCASを使用することで、ブランドは地理的または政治地域への証明書の管理責任を分散させることができるので、ブランドポリシーは必要に応じて地域間で異なります。
$ GIG (O) See: Global Information Grid.
$ ギグ（O）グローバル情報グリッドを参照してください。
$ Global Information Grid (GIG) (O) /U.S. DoD/ The GIG is "a globally interconnected, end-to-end set of information capabilities, associated processes and personnel for collecting, processing, storing, disseminating, and managing information on demand to war fighters, policy makers, and support personnel." [IATF] Usage: Formerly referred to as the DII.
$ グローバル情報グリッド（GIG）/ U.S。Dod / Gigは、世界中の情報能力、関連するプロセス、および戦争戦闘機、政策メーカー、および支援担当者への需要に関する情報を収集、処理、保存、普及および管理のための関連プロセスの一連の情報能力、担当者です。」[IATF]使用法：以前はDIIと呼ばれています。
$ good engineering practice(s) (N) A term used to specify or characterize design, implementation, installation, or operating practices for an information system, when a more explicit specification is not possible. Generally understood to refer to the state of the engineering art for commercial systems that have problems and solutions equivalent to the system in question.
$ 良いエンジニアリング慣行（N）より明確な仕様が不可能な場合、情報システムの設計、実装、インストール、またはオペレーティングプラクティスを指定または特徴付けるために使用される用語。問題のあるシステムと同等の問題および解決策を有する商業システムのためのエンジニアリングアートの状態を指すと一般的に理解されている。
$ granularity 1. (N) /access control/ Relative fineness to which an access control mechanism can be adjusted.
$ 粒度1.（N）/アクセス制御/アクセス制御機構を調整できる相対的な細かさ。
2. (N) /data security/ "The size of the smallest protectable unit of information" in a trusted system. [Huff]
2. （N）/データセキュリティ/「保護可能な情報の最小保護単位のサイズ」。[ハフ]
$ Green Book (D) /slang/ Synonym for "Defense Password Management Guideline" [CSC2].
$ グリーンブック（D）/スラング/「防御パスワード管理ガイドライン」[CSC2]の同義語。
Deprecated Term: Except as an explanatory appositive, IDOCs SHOULD NOT use this term, regardless of the associated definition. Instead, use the full proper name of the document or, in subsequent references, a conventional abbreviation. (See: Rainbow Series.)
廃止予定の用語：説明の上にあるものとして、IDocは関連する定義に関係なく、この用語を使用しないでください。代わりに、文書の完全な正しい名前、または後続の参照では、従来の略語を使用してください。（参照：レインボーシリーズ。）
Deprecated Usage: To improve international comprehensibility of Internet Standards and the Internet Standards Process, IDOCs SHOULD NOT use "cute" synonyms. No matter how clearly understood or popular a nickname may be in one community, it is likely to cause confusion or offense in others. For example, several other information system standards also are called "the Green Book"; the following are some examples: - Each volume of 1992 ITU-T (known at that time as CCITT) standards. - "PostScript Language Program Design", Adobe Systems, Addison-Wesley, 1988. - IEEE 1003.1 POSIX Operating Systems Interface.
廃止予定の使用法：インターネット規格の国際的な総合性を向上させるために、IDocは「かわいい」同義語を使用しないでください。ニックネームがどれほど明確に理解されていても人気があっても、他の人に混乱や犯罪を引き起こす可能性があります。たとえば、他のいくつかの情報システム規格も「緑の本」とも呼ばれます。以下はいくつかの例です。 - 1992年の各ボリュームのITU-T（当時の当時はCCITTとして知られています）規格。 - 「PostScript Language Program Design」、Adobe Systems、Addison-Wesley、1988年 - IEEE 1003.1 POSIXオペレーティングシステムのインタフェース。
- "Smalltalk-80: Bits of History, Words of Advice", Glenn Krasner, Addison-Wesley, 1983. - "X/Open Compatibility Guide". - A particular CD-ROM format developed by Phillips.
- "Smalltalk-80：歴史のビット、アドバイスの言葉"、Glenn Krasner、Addison-Wesley、1983年 - "X / Open Compatibility Guide"。 - Phillipsによって開発された特定のCD-ROM形式。
$ Group Domain of Interpretation (GDOI) (I) An ISAKMP/IKE domain of interpretation for group key management; i.e., a phase 2 protocol in ISAKMP. [R3547] (See: secure multicast.)
$ 解釈のグループドメイン（gdoi）（i）グループ鍵管理のための解釈のISAKMP / IKEドメイン。すなわち、ISAKMPにおけるフェーズ2プロトコル。[R3547]（「セキュアマルチキャスト」を参照）
Tutorial: In this group key management model that extends the ISAKMP standard, the protocol is run between a group member and a "group controller/key server", which establishes security associations [R4301] among authorized group members. The GDOI protocol is itself protected by an ISAKMP phase 1 association.
チュートリアル：ISAKMP規格を拡張するこのグループ鍵管理モデルでは、承認されたグループメンバーの中でセキュリティアソシエーション[R4301]を確立するグループメンバーと「グループコントローラ/キーサーバー」の間でプロトコルが実行されます。GDOIプロトコルは、ISAKMPフェーズ1の関連によって保護されています。
For example, multicast applications may use ESP to protect their data traffic. GDOI carries the needed security association parameters for ESP. In this way, GDOI supports multicast ESP with group authentication of ESP packets using a shared, group key.
たとえば、マルチキャストアプリケーションは、データトラフィックを保護するためにESPを使用することがあります。GdoiはESPのために必要なセキュリティ協会パラメータを運びます。このようにして、GDOIは、共有グループキーを使用してESPパケットのグループ認証でマルチキャストESPをサポートしています。
$ group identity (I) See: secondary definition under "identity".
$ グループID（i）「ID」の下の2次定義を参照してください。
$ group security association (I) "A bundling of [security associations] (SAs) that together define how a group communicates securely. The [group SA] may include a registration protocol SA, a rekey protocol SA, and one or more data security protocol SAs." [R3740]
$ グループセキュリティアソシエーション（I）「セキュリティアソシエーションのバンドリング」（SAS）がグループが安全に通信する方法を定義する。[グループSA]は、登録プロトコルSA、再スリープロトコルSA、および1つまたは複数のデータセキュリティプロトコルを含み得る。SAS」[R3740]
$ GSS-API (I) See: Generic Security Service Application Program Interface.
$ GSS-API（i）：Generic Security Serviceアプリケーションプログラムインタフェースを参照してください。
$ guard (I) A computer system that (a) acts as gateway between two information systems operating under different security policies and (b) is trusted to mediate information data transfers between the two. (See: controlled interface, cross-domain solution, domain, filter. Compare: firewall.)
$ Guard（i）異なるセキュリティポリシーの下で動作する2つの情報システム間のゲートウェイとして機能するコンピュータシステムであり、（B）は2つの間の情報データ転送を仲介することを信頼されています。（制御インターフェース、クロスドメインソリューション、ドメイン、フィルタ。比較：ファイアウォール。）
Usage: Frequently understood to mean that one system is operating at a higher security level than the other, and that the gateway's purpose is to prevent unauthorized disclosure of data from the higher system to the lower. However, the purpose might also be to protect the data integrity, availability, or general system integrity of one system from threats posed by connecting to the other system. The mediation may be entirely automated or may involve "reliable human review".
使用法：1つのシステムが他方のシステムよりも高いセキュリティレベルで動作していることを意味し、ゲートウェイの目的は、より高いシステムからより低いデータの開示を防ぐことです。ただし、その目的は、他のシステムに接続することによって提起された脅威から1つのシステムのデータの整合性、可用性、または一般的なシステムの整合性を保護することもできます。調整は完全に自動化されているか、または「信頼できる人間のレビュー」を含み得る。
$ guest login (I) See: anonymous login.
$ ゲストログイン（i）匿名ログインを参照してください。
$ GULS (I) Generic Upper Layer Security service element (ISO 11586), a five-part standard for the exchange of security information and security-transformation functions that protect confidentiality and integrity of application data.
$ GULS（I）一般的な上層のセキュリティサービス要素（ISO 11586）、セキュリティ情報の交換と、アプリケーションデータの機密性と完全性を保護するセキュリティ変換機能との5部品規格。
$ Gypsy verification environment (O) A methodology, language, and integrated set of software tools developed at the University of Texas for specifying, coding, and verifying software to produce correct and reliable programs. [Cheh]
$ ジプシー検証環境（O）正しい信頼性の高いプログラムを作成するためにソフトウェアを特定、コーディング、検証するためにテキサス大学で開発されたソフトウェアツールの方法論、言語、および統合されたセット。[Cheh]
$ H field (D) See: Deprecated Usage under "Handling Restrictions field".
$ hフィールド（d）：「扱い制限フィールド」の下での廃止予定の使用。
$ hack 1a. (I) /verb/ To work on something, especially to program a computer. (See: hacker.)
$ ハック1A。（i）/動詞/何かに取り組むために、特にコンピュータをプログラムすること。（：ハッカーを参照してください。）
1b. (I) /verb/ To do some kind of mischief, especially to play a prank on, or penetrate, a system. (See: hacker, cracker.)
1b。（i）/動詞/いくつかのいたずらをするために、特にいたずらや浸透を弾くためにシステムを紹介します。（：ハッカー、クラッカー。）
2. (I) /noun/ An item of completed work, or a solution for a problem, that is non-generalizable, i.e., is very specific to the application area or problem being solved.
2. （i）/名詞/完成した作業の項目、または一般的な問題の解決策、すなわち、解決されているアプリケーション領域に非常に固有のものである。
Tutorial: Often, the application area or problem involves computer programming or other use of a computer. Characterizing something as a hack can be a compliment, such as when the solution is minimal and elegant; or it can be derogatory, such as when the solution fixes the problem but leaves the system in an unmaintainable state.
チュートリアル：多くの場合、アプリケーション領域または問題はコンピュータプログラミングまたはコンピュータのその他の使用を含みます。その解決策が最小限でエレガントな場合など、ハックとして何かを特徴付けることができます。あるいは、解決策が問題を解決するがシステムを維持できない状態で残すときなど、軽蔑的なものにすることもできます。
See [Raym] for several other meanings of this term and also definitions of several derivative terms.
この用語の他のいくつかの意味といくつかの派生語の定義についても[RAYM]を参照してください。
$ hacker 1. (I) Someone with a strong interest in computers, who enjoys learning about them, programming them, and experimenting and otherwise working with them. (See: hack. Compare: adversary, cracker, intruder.)
$ ハッカー1.（i）それらについての学習、それらをプログラミングし、そしてその他の方法で働く、コンピュータに強い関心を持っている人。（：ハック。比較：敵対者、クラッカー、侵入者。）
Usage: This first definition is the original meaning of the term (circa 1960); it then had a neutral or positive connotation of "someone who figures things out and makes something cool happen".
使用法：この最初の定義は、この用語の元の意味です（1960年頃）。それはそれから「物事を出して何かを涼しくする人」の中立的または肯定的な意味合いを持っていました。
2. (O) "An individual who spends an inordinate amount of time working on computer systems for other than professional purposes." [NCSSG]
2. （O）「専門の目的以外のためにコンピュータシステムに取り組んでいる過度の時間を費やす個人」[NCSSG]
3. (D) Synonym for "cracker".
3. （d）「クラッカー」の同義語。
Deprecated Usage: Today, the term is frequently (mis)used (especially by journalists) with definition 3.
廃止予定の使用法：今日、この用語は定義3で（特にジャーナリストによって）使用されている（Mis）。
$ handle 1. (I) /verb/ Perform processing operations on data, such as receive and transmit, collect and disseminate, create and delete, store and retrieve, read and write, and compare. (See: access.)
$ ハンドル1.（i）/動詞/の処理操作、受信と送信、統合、作成、削除、保存、および取得、読み書き、および比較など、データの処理操作を実行します。（アクセスを参照してください。）
2. (I) /noun/ An online pseudonym, particularly one used by a cracker; derived from citizens' band radio culture.
2. （i）/名詞/オンライン仮名、特にクラッカーによって使用されるもの。市民バンドラジオカルチャーから派生した。
$ handling restriction (I) A type of access control other than (a) the rule-based protections of mandatory access control and (b) the identity-based protections of discretionary access control; usually involves administrative security.
$ 制限の処理制限（a）必須アクセス制御のルールベースの保護および（b）識別アクセス制御の識別ベースの保護の一種。通常管理セキュリティを含みます。
$ Handling Restrictions field (I) A 16-bit field that specifies a control and release marking in the security option (option type 130) of IP's datagram header format. The valid field values are alphanumeric digraphs assigned by the U.S. Government, as specified in RFC 791.
$ [制限の処理]フィールド（i）IPのデータグラム・ヘッダー・フォーマットのセキュリティー・オプション（オプション・タイプ130）で制御とリリース・マーキングを指定する16ビットフィールド。有効なフィールド値は、RFC 791で指定されているように、米国政府によって割り当てられた英数字のDigraphです。
Deprecated Abbreviation: IDOCs SHOULD NOT use the abbreviation "H field" because it is potentially ambiguous. Instead, use "Handling Restrictions field".
廃止予定の省略形：IDocは潜在的にあいまいなので略語「Hフィールド」を使用しないでください。代わりに、「制限の取り扱い分野」を使用してください。
$ handshake (I) Protocol dialogue between two systems for identifying and authenticating themselves to each other, or for synchronizing their operations with each other.
$ ハンドシェイク（i）互いに自分自身を識別して認証するための2つのシステム間、またはそれらの操作を互いに同期させるための2つのシステム間の対話。
$ Handshake Protocol (I) /TLS/ The TLS Handshake Protocol consists of three parts (i.e., subprotocols) that enable peer entities to agree upon security parameters for the record layer, authenticate themselves to each other, instantiate negotiated security parameters, and report error conditions to each other. [R4346]
$ ハンドシェイクプロトコル（I）/ TLS / TLSハンドシェイクプロトコルは、ピアエンティティがレコードレイヤのセキュリティパラメータに同意する、互いに自分自身を認証し、ネゴシテーションセキュリティパラメータをインスタンス化し、エラー状態を報告することができる3つの部分（サブプロトコル）で構成されています。お互いに。[R4346]
$ harden (I) To protect a system by configuring it to operate in a way that eliminates or mitigates known vulnerabilities. Example: [RSCG]. (See: default account.)
$ 既知の脆弱性を排除または軽減するように動作させるように構成することでシステムを保護するために（i）。例：[RSCG]。（：デフォルトアカウントを参照してください。）
$ hardware (I) The material physical components of an information system. (See: firmware, software.)
$ ハードウェア（i）情報システムの材料物理成分。（「ファームウェア、ソフトウェア」を参照してください。
$ hardware error (I) /threat action/ See: secondary definitions under "corruption", "exposure", and "incapacitation".
$ ハードウェアエラー（I）/脅威の処置/参照：「破損」、「露出」、および「無能力」の下の二次定義。
$ hardware token See: token.
$ ハードウェアトークンは、トークンを参照してください。
$ hash code (D) Synonym for "hash result" or "hash function".
$ ハッシュコード（d）「ハッシュ結果」または「ハッシュ関数」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts in a potentially misleading way. A hash result is not a "code", and a hash function does not "encode" in any sense defined by this glossary. (See: hash value, message digest.)
廃止予定語：IDocsはこの用語を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。ハッシュ結果は「コード」ではなく、ハッシュ関数はこの用語集によって定義された意味で「符号化」しません。（「ハッシュ値、メッセージダイジェスト」を参照してください。
$ hash function 1. (I) A function H that maps an arbitrary, variable-length bit string, s, into a fixed-length string, h = H(s) (called the "hash result"). For most computing applications, it is desirable that given a string s with H(s) = h, any change to s that creates a different string s' will result in an unpredictable hash result H(s') that is, with high probability, not equal to H(s).
$ ハッシュ関数1.（i）任意の可変長ビット文字列S、Sを固定長文字列にマッピングする関数H（「ハッシュ結果」と呼ばれる）。ほとんどのコンピューティングアプリケーションでは、h（s）= hの文字列sを与えられると、異なる文字列s 'を作成するSの変更は、高い確率で、予測不可能なハッシュ結果H（S'）をもたらすでしょう。H（s）に等しくない。
2. (O) "A (mathematical) function which maps values from a large (possibly very large) domain into a smaller range. A 'good' hash function is such that the results of applying the function to a (large) set of values in the domain will be evenly distributed (and apparently at random) over the range." [X509]
2. （O）「多大な）ドメインから値を小さい範囲にマッピングする（数学的）関数。「良い」ハッシュ関数は、関数を（大）の値のセットに適用した結果があります。ドメインは範囲にわたって均等に（そして明らかにランダムに）分配されます。」[X509]
Tutorial: A hash function operates on variable-length input (e.g., a message or a file) and outputs a fixed-length output, which typically is much shorter than most input values. If the algorithm is "good" as described in the "O" definition, then the hash function may be a candidate for use in a security mechanism to detect accidental changes in data, but not necessarily for a mechanism to detect changes made by active wiretapping. (See: Tutorial under "checksum".) Security mechanisms require a "cryptographic hash function" (e.g., MD2, MD4, MD5, SHA-1, Snefru), i.e., a good hash function that also has the one-way property and one of the two collision-free properties: - "One-way property": Given H and a hash result h = H(s), it is hard (i.e., computationally infeasible, "impossible") to find s. (Of course, given H and an input s, it must be relatively easy to compute the hash result H(s).) - "Weakly collision-free property": Given H and an input s, it is hard (i.e., computationally infeasible, "impossible") to find a different input, s', such that H(s) = H(s'). - "Strongly collision-free property": Given H, it is hard to find any pair of inputs s and s' such that H(s) = H(s').
チュートリアル：ハッシュ関数は可変長入力（例えば、メッセージまたはファイル）で動作し、固定長出力を出力します。これは通常ほとんどの入力値よりもはるかに短いです。 「O」定義に記載されているようにアルゴリズムが「良好」である場合、ハッシュ関数は、データの偶発的な変更を検出するためのセキュリティメカニズムでの使用候補であり得るが、必ずしもアクティブなワイヤキャッピングによって行われた変更を検出するためのメカニズムのためにはそうではない。 。セキュリティメカニズムは、「暗号化ハッシュ関数」（例えば、MD2、MD4、MD5、SHA - 1、SNEFRU）、すなわち一方向のプロパティも有する良好なハッシュ関数を必要とする。 2つの衝突のない特性の1つ： - 「一方向性」：Hおよびハッシュ結果H = H = H = H = H = H = H = H = H = H = H = H = H = H = H = H = H = H = H = H）。 （もちろん、入力Sと入力Sは、ハッシュ結果H（S）を計算するのは比較的簡単でなければなりません） - 「弱衝突のないプロパティ」：hと入力Sは難しい（すなわち、計算上） 「不可能」、「不可能」）は、h（s）= h（s '）が異なる入力S'を見つける。 - 「強い衝突のない財産」：hを与えられると、h（s）= h（s '）のような入力SとS'の対を見つけることは困難です。
If H produces a hash result N bits long, then to find an s' where H(s') = H(s) for a specific given s, the amount of computation required is O(2**n); i.e., it is necessary to try on the order of 2 to the power n values of s' before finding a collision. However, to simply find any pair of values s and s' that collide, the amount of computation required is only O(2**(n/2)); i.e., after computing H(s) for 2 to the power n/2 randomly chosen values of s, the probability is greater than 1/2 that two of those values have the same hash result. (See: birthday attack.)
Hが長くハッシュ結果Nビットを生成した場合、特定のSについてのh（s '）= h（s）を見つけるために、必要な計算量はO（2 ** n）である。すなわち、衝突を見つける前に、S 'の電源N値に対して2の順序で試してみる必要がある。ただし、衝突する値SとS 'のペアを単純に見つけるためには、必要な計算量はOだけです（2 **（N / 2））。すなわち、電力N / 2の電力N / 2の間のH（S）を計算した後、Sの電力N / 2の値Sの値をランダムに選択した後、それらの値のうちの2つが同じハッシュ結果を有する。（参照：誕生日攻撃）
$ hash result 1. (I) The output of a hash function. (See: hash code, hash value. Compare: hash value.)
$ ハッシュ結果1.（i）ハッシュ関数の出力。（ハッシュコード、ハッシュ値を参照してください。比較：ハッシュ値を比較してください。）
2. (O) "The output produced by a hash function upon processing a message" (where "message" is broadly defined as "a digital representation of data"). [DSG]
2. （O）「メッセージを処理する際のハッシュ関数によって生成された出力」（「メッセージ」は、「データのデジタル表現」として広く定義されている。[DSG]
Usage: IDOCs SHOULD avoid the unusual usage of "message" that is seen in the "O" definition.
使用法：IDOCは、「O」定義に見られる「メッセージ」の異常な使用を避けるべきです。
$ hash value (D) Synonym for "hash result".
$ ハッシュ値（d）「ハッシュ結果」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term for the output of a hash function; the term could easily be confused with "hashed value", which means the input to a hash function. (See: hash code, hash result, message digest.)
廃止予定の用語：IDOCはハッシュ関数の出力に対してこの用語を使用しないでください。この用語は、「ハッシュ値」と簡単に混同することができ、これはハッシュ関数への入力を意味する。（：ハッシュコード、ハッシュ結果、メッセージダイジェストを参照）
$ HDM (O) See: Hierarchical Development Methodology.
$ HDM（O）階層開発方法論を参照してください。
$ Hierarchical Development Methodology (HDM) (O) A methodology, language, and integrated set of software tools developed at SRI International for specifying, coding, and verifying software to produce correct and reliable programs. [Cheh]
$ 階層開発方法論（HDM）（O）ソフトウェアを作成、コーディング、および信頼性の高いプログラムを作成するために、SRI Internationalで開発されたソフトウェアツールの方法論、言語、および統合されたセット。[Cheh]
$ hierarchical PKI (I) A PKI architecture based on a certification hierarchy. (Compare: mesh PKI, trust-file PKI.)
$ 階層PKI（i）認証階層に基づくPKIアーキテクチャ。（比較：メッシュPKI、信託ファイルPKI）
$ hierarchy management (I) The process of generating configuration data and issuing public-key certificates to build and operate a certification hierarchy. (See: certificate management.)
$ 階層管理（i）コンフィギュレーションデータを生成し、認証階層を構築して運用するための公開鍵証明書の発行プロセス。（証明書管理を参照してください。）
$ hierarchy of trust (D) Synonym for "certification hierarchy".
$ 信頼の階層（D）「証明階層」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts in a potentially misleading way. (See: certification hierarchy, trust, web of trust.)
廃止予定語：IDocsはこの用語を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。（「認証階層、信頼、信頼のWeb」を参照してください。
$ high-assurance guard (O) "An oxymoron," said Lt. Gen. William H. Campbell, former U.S. Army chief information officer, speaking at an Armed Forces Communications and Electronics Association conference.
$ 高級ガード（O）「オキシモロン」は、武装軍のコミュニケーションおよびエレクトロニクス協会会議で話す旧米国陸軍長情報責任者であるGen. William H. Campbellは、述べた。
Usage: IDOCs that use this term SHOULD state a definition for it because the term mixes concepts and could easily be misunderstood.
使用法：この用語を使用するIDOCは、用語が概念をミックスし、簡単に誤解される可能性があるため、定義を定義します。
$ hijack attack (I) A form of active wiretapping in which the attacker seizes control of a previously established communication association. (See: man-in-the-middle attack, pagejacking, piggyback attack.)
$ Hijack Attack（i）攻撃者が以前に確立された通信会の制御を捉えるアクティブな盗聴の形式。（中間攻撃、PageJacking、Piggyback Attack。）
$ HIPAA (N) Health Information Portability and Accountability Act of 1996, a U.S. law (Public Law 104-191) that is intended to protect the privacy of patients' medical records and other health information in all forms, and mandates security for that information, including for its electronic storage and transmission.
$ HIPAA（N）患者の医療記録のプライバシーを保護することを目的とした米国の法律（公的法104-191）の健康情報携帯性と説明責任法（公的法104-191）、その情報のセキュリティを義務付けています。その電子貯蔵および伝送のために含める。
$ HMAC (I) A keyed hash [R2104] that can be based on any iterated cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic strength of HMAC depends on the properties of the selected cryptographic hash. (See: [R2202, R2403, R2404].)
$ HMAC（i）キー付きハッシュ[R2104]は、任意の反復暗号ハッシュ（例えば、MD5またはSHA - 1）に基づくことができるので、HMACの暗号強度は選択された暗号化ハッシュの特性に依存する。（[R2202、R2403、R2404]）
Derivation: Hash-based MAC. (Compare: CMAC.)
派生：ハッシュベースのMac。（比較：CMAC。）
Tutorial: Assume that H is a generic cryptographic hash in which a function is iterated on data blocks of length B bytes. L is the length of the of hash result of H. K is a secret key of length L <= K <= B. The values IPAD and OPAD are fixed strings used as inner and outer padding and defined as follows: IPAD = the byte 0x36 repeated B times, and OPAD = the byte 0x5C repeated B times. HMAC is computed by H(K XOR OPAD, H(K XOR IPAD, inputdata)).
チュートリアル：Hが長さBバイトのデータブロックで関数が繰り返される一般的な暗号化ハッシュであるとします。LはHのハッシュ結果の長さである。kは長さL≦k≦Bの秘密鍵である。値iPadおよびOPADは、内側および外側のパディングとして使用される固定文字列であり、次のように定義されている。ipad = byte0x36繰り返しB回、opad = Byte 0x5C繰り返しB回繰り返されます。HMACはH（K XOR OPAD、H（K XOR iPad、InputData））によって計算されます。
HMAC has the following goals: - To use available cryptographic hash functions without modification, particularly functions that perform well in software and for which software is freely and widely available. - To preserve the original performance of the selected hash without significant degradation. - To use and handle keys in a simple way. - To have a well-understood cryptographic analysis of the strength of the mechanism based on reasonable assumptions about the underlying hash function. - To enable easy replacement of the hash function in case a faster or stronger hash is found or required.
HMACには、次の目標があります。 - 変更することなく利用可能な暗号化ハッシュ関数、特にソフトウェアでうまく機能する機能、そしてどのソフトウェアが自由かつ広く利用可能な関数を使用する。 - 有意な劣化なしに、選択したハッシュの元の性能を維持する。 - 簡単な方法でキーを使用して処理する。 - 基礎となるハッシュ関数についての合理的な仮定に基づくメカニズムの強さをよく理解させること。 - より速いまたは強いハッシュが見つかった場合、または必要な場合には、ハッシュ関数を簡単に交換することができます。
$ honey pot (N) A system (e.g., a web server) or system resource (e.g., a file on a server) that is designed to be attractive to potential crackers and intruders, like honey is attractive to bears. (See: entrapment.)
$ ハニーポット（n）蜂蜜のように魅力的なクラッカーや侵入者にとって魅力的であるように設計されたシステム（例えば、Webサーバ）またはシステムリソース（例えば、サーバ上のファイル）。（注意を参照してください。）
Usage: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, an IDOC SHOULD NOT use this term without providing a definition for it. (See: Deprecated Usage under "Green Book".)
使用法：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を回避するために、IDocはその定義を提供することなくこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ host 1. (I) /general/ A computer that is attached to a communication subnetwork or internetwork and can use services provided by the network to exchange data with other attached systems. (See: end system. Compare: server.)
$ ホスト1.（i）/一般/通信サブネットワークまたはインターネットワークに接続されており、ネットワークによって提供されたサービスを使用して他の接続システムとデータを交換することができます。（Seque System。Compare：Server。）
2. (I) /IPS/ A networked computer that does not forward IP packets that are not addressed to the computer itself. (Compare: router.)
2. （i）/ IPS /コンピュータ自体に対処されていないIPパケットを転送しないネットワークコンピュータ。（比較：ルータ。）
Derivation: As viewed by its users, a host "entertains" them, providing Application-Layer services or access to other computers attached to the network. However, even though some traditional peripheral service devices, such as printers, can now be independently connected to networks, they are not usually called hosts.
派生：そのユーザーによって見て、ホストはそれらを「楽しませる」、アプリケーション層サービスまたはネットワークに接続されている他のコンピュータへのアクセスを提供します。ただし、プリンタなどの従来の周辺機器サービスデバイスは、ネットワークに独立して接続できるため、通常はホストと呼ばれません。
$ HTML (I) See: Hypertext Markup Language.
$ HTML（i）：ハイパーテキストマークアップ言語。
$ HTTP (I) See: Hypertext Transfer Protocol.
$ http（i）：ハイパーテキスト転送プロトコルを参照してください。
$ https (I) When used in the first part of a URL (the part that precedes the colon and specifies an access scheme or protocol), this term specifies the use of HTTP enhanced by a security mechanism, which is usually SSL. (Compare: S-HTTP.)
$ HTTPS（i）URLの最初の部分で使用されている場合（コロンの前にアクセス方式またはプロトコルを指定し、アクセス方式またはプロトコルを指定する部分）、この用語は、通常SSLであるセキュリティメカニズムによってHTTPの使用を指定します。（比較：S-HTTP）
$ human error (I) /threat action/ See: secondary definitions under "corruption", "exposure", and "incapacitation".
$ ヒューマンエラー（I）/脅威の対応/参照：「破損」、「露出」、および「無能力」の下の二次定義。
$ hybrid encryption (I) An application of cryptography that combines two or more encryption algorithms, particularly a combination of symmetric and asymmetric encryption. Examples: digital envelope, MSP, PEM, PGP. (Compare: superencryption.)
$ ハイブリッド暗号化（i）2つ以上の暗号化アルゴリズム、特に対称暗号化と非対称暗号化の組み合わせを組み合わせた暗号化の応用。例：デジタルエンベロープ、MSP、PEM、PGP。（比較：上限顕微構成）
Tutorial: Asymmetric algorithms require more computation than equivalently strong symmetric ones. Thus, asymmetric encryption is not normally used for data confidentiality except to distribute a symmetric key in a hybrid encryption scheme, where the symmetric key is usually very short (in terms of bits) compared to the data file it protects. (See: bulk key.)
チュートリアル：非対称アルゴリズムは、同等の強力な対称性よりも多くの計算を必要とします。したがって、非対称暗号化は通常、対称鍵をハイブリッド暗号化方式で配布すること以外はデータ機密性には使用されず、対称鍵は通常保護するデータファイルと比較して（ビットに関して）非常に短い（ビットに関して）。（：バルクキーを参照してください。）
$ hyperlink (I) In hypertext or hypermedia, an information object (such as a word, a phrase, or an image, which usually is highlighted by color or underscoring) that points (i.e., indicates how to connect) to related information that is located elsewhere and can be retrieved by activating the link (e.g., by selecting the object with a mouse pointer and then clicking).
$ ハイパーテキストまたはハイパーメディア、情報オブジェクト（単語、フレーズ、または画像など、通常は色またはアンダースコアが強調表示されている）のハイパーリンク（つまり、接続方法を示す）他の場所で（たとえば、マウスポインタを持つオブジェクトを選択してからクリックすることで）リンクをアクティブにすることで検索できます。
$ hypermedia (I) A generalization of hypertext; any media that contain hyperlinks that point to material in the same or another data object.
$ ハイパーメディア（I）ハイパーテキストの一般化。同じまたは別のデータオブジェクト内の素材を指すハイパーリンクを含む任意のメディア。
$ hypertext (I) A computer document, or part of a document, that contains hyperlinks to other documents; i.e., text that contains active pointers to other text. Usually written in HTML and accessed using a web browser. (See: hypermedia.)
$ ハイパーテキスト（i）他の文書へのハイパーリンクを含むコンピュータ文書、または文書の一部。すなわち、他のテキストへのアクティブポインタを含むテキスト。通常はHTMLで書かれており、Webブラウザを使用してアクセスされます。（：ハイパーメディアを参照してください。）
$ Hypertext Markup Language (HTML) (I) A platform-independent system of syntax and semantics (RFC 1866) for adding characters to data files (particularly text files) to represent the data's structure and to point to related data, thus creating hypertext for use in the World Wide Web and other applications. (Compare: XML.)
$ HyperText Markup Language（html）（i）データファイル（特にテキストファイル）に文字を追加し、関連データを指すための文字を追加するためのプラットフォームに依存しないシンタックスとセマンティクスシステム（RFC 1866）。ワールドワイドウェブやその他のアプリケーションで。（比較：XML。）
$ Hypertext Transfer Protocol (HTTP) (I) A TCP-based, Application-Layer, client-server, Internet protocol (RFC 2616) that is used to carry data requests and responses in the World Wide Web. (See: hypertext.)
$ HyperText Transfer Protocol（HTTP）（i）ワールドワイドウェブでデータ要求と応答を搬送するために使用されるTCPベースのアプリケーション層、クライアントサーバー、インターネットプロトコル（RFC 2616）。（：ハイパーテキストを参照してください。）
$ IAB (I) See: Internet Architecture Board.
$ IAB（i）インターネットアーキテクチャボードを参照してください。
$ IANA (I) See: Internet Assigned Numbers Authority.
$ IANA（I）：インターネット割り当て番号局。
$ IATF (O) See: Information Assurance Technical Framework.
$ IATF（O）情報保証技術枠組みを参照してください。
$ ICANN (I) See: Internet Corporation for Assigned Names and Numbers.
$ ICANN（i）割り当てられた名前と数字のインターネット社。
$ ICMP (I) See: Internet Control Message Protocol.
$ ICMP（i）インターネット制御メッセージプロトコルを参照してください。
$ ICMP flood (I) A denial-of-service attack that sends a host more ICMP echo request ("ping") packets than the protocol implementation can handle. (See: flooding, smurf.)
$ ICMP Flood（i）プロトコル実装よりもHOSTよりもっとICMPエコー要求（「ping」）パケットを送信するサービス拒否攻撃。（洪水、スミルフを参照）
$ ICRL (N) See: indirect certificate revocation list.
$ icrl（n）：間接証明書失効リストを参照してください。
$ IDEA (N) See: International Data Encryption Algorithm.
$ アイデア（n）：国際データ暗号化アルゴリズムを参照してください。
$ identification (I) An act or process that presents an identifier to a system so that the system can recognize a system entity and distinguish it from other entities. (See: authentication.)
$ 識別（i）システムがシステムエンティティを認識し、他のエンティティと区別できるように、システムに識別子を提示する行為またはプロセス。（認証を参照してください。）
$ identification information (D) Synonym for "identifier"; synonym for "authentication information". (See: authentication, identifying information.)
$ 識別情報（D）「識別子」の同義語。「認証情報」の同義語。（：認証、情報の識別）
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for either of those terms; this term (a) is not as precise as they are and (b) mixes concepts in a potentially misleading way. Instead, use "identifier" or "authentication information", depending on what is meant.
廃止予定の用語：IDocは、この用語をそれらの条項の同義語として使用しないでください。この用語（a）は、それらがそうであるほど正確ではなく、（b）潜在的に誤解を招くような方法で概念を混合する。代わりに、何を意味するのかによって、「識別子」または「認証情報」を使用してください。
$ Identification Protocol (I) A client-server Internet protocol [R1413] for learning the identity of a user of a particular TCP connection.
$ 特定のTCP接続のユーザの身元を学習するための識別プロトコル（i）クライアント - サーバインターネットプロトコル[R1413]。
Tutorial: Given a TCP port number pair, the server returns a character string that identifies the owner of that connection on the server's system. The protocol does not provide an authentication service and is not intended for authorization or access control. At best, it provides additional auditing information with respect to TCP.
チュートリアル：TCPポート番号のペアを考えると、サーバーはサーバーのシステム上のその接続の所有者を識別する文字列を返します。プロトコルは認証サービスを提供しておらず、許可またはアクセス制御を意図していません。せいぜい、それはTCPに関して追加の監査情報を提供します。
$ identifier (I) A data object -- often, a printable, non-blank character string -- that definitively represents a specific identity of a system entity, distinguishing that identity from all others. (Compare: identity.)
$ 識別子（i）データ・オブジェクト - 多くの場合、印刷可能な、非空白文字列 - は、システムエンティティの特定のIDを確定的に表し、そのアイデンティティを他のすべてのものから区別してください。（比較：身分証明書。）
Tutorial: Identifiers for system entities must be assigned very carefully, because authenticated identities are the basis for other security services, such as access control service.
チュートリアル：Accenticated IDは、Access Control Serviceなどの他のセキュリティサービスの基盤であるため、システムエンティティの識別子を非常に慎重に割り当てる必要があります。
$ identifier credential 1. (I) See: /authentication/ under "credential".
$ 識別子の認証情報1.（i）/認証/「信任状」の下にある。
2. (D) Synonym for "signature certificate".
2. （d）「署名証明書」の同義語。
Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.
使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されており、簡単に誤解される可能性があるため、定義を記載する必要があります。
$ identifying information (D) Synonym for "identifier"; synonym for "authentication information". (See: authentication, identification information.)
$ 識別情報（D）「識別子」の同義語。「認証情報」の同義語。（認証、識別情報）を参照してください。
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for either of those terms; this term (a) is not as precise as they are and (b) mixes concepts in a potentially misleading way. Instead, use "identifier" or "authentication information", depending on what is meant.
廃止予定の用語：IDocは、この用語をそれらの条項の同義語として使用しないでください。この用語（a）は、それらがそうであるほど正確ではなく、（b）潜在的に誤解を招くような方法で概念を混合する。代わりに、何を意味するのかによって、「識別子」または「認証情報」を使用してください。
$ identity (I) The collective aspect of a set of attribute values (i.e., a set of characteristics) by which a system user or other system entity is recognizable or known. (See: authenticate, registration. Compare: identifier.)
$ ID（i）システムユーザまたは他のシステムエンティティが認識可能または知られている属性値のセット（すなわち、特性セット）の集合的な側面。（認証、登録を参照してください。比較：識別子。）
Usage: An IDOC MAY apply this term to either a single entity or a set of entities. If an IDOC involves both meanings, the IDOC SHOULD use the following terms and definitions to avoid ambiguity: - "Singular identity": An identity that is registered for an entity that is one person or one process. - "Shared identity": An identity that is registered for an entity that is a set of singular entities (1) in which each member is authorized to assume the identity individually and (2) for which the registering system maintains a record of the singular entities that comprise the set. In this case, we would expect each member entity to be registered with a singular identity before becoming associated with the shared identity. - "Group identity": An identity that is registered for an entity (1) that is a set of entities (2) for which the registering system does not maintain a record of singular entities that comprise the set.
使用法：IDOCは、この用語を単一のエンティティまたは一連のエンティティのいずれかに適用することができます。IDocが意味を伴う場合、IDocは曖昧さを避けるために以下の用語と定義を使用する必要があります。 - 「特徴識別」：一人または1つのプロセスであるエンティティに登録されているアイデンティティ。 - 「共有識別情報」：各メンバーが個別に識別されているものと（2）登録システムが特異の記録を維持することを許可されている一連の単数エンティティ（1）であるエンティティに登録されている識別情報セットを構成するエンティティ。この場合、共有識別情報に関連付けられる前に、各メンバーエンティティが特異的アイデンティティに登録されることを期待します。 - 「グループ識別情報」：登録システムが設定された特異的エンティティの記録を維持しない一連のエンティティ（1）に登録されているID。
Tutorial: When security services are based on identities, two properties are desirable for the set of attributes used to define identities: - The set should be sufficient to distinguish each entity from all other entities, i.e., to represent each entity uniquely. - The set should be sufficient to distinguish each identity from any other identities of the same entity.
チュートリアル：セキュリティサービスがIDに基づいている場合、IDを定義するために使用される属性のセットには2つのプロパティが望ましいです。 - セットは、同じエンティティの他の任意のアイデンティティと区別するのに十分であるべきです。
The second property is needed if a system permits an entity to register two or more concurrent identities. Having two or more identities for the same entity implies that the entity has two separate justifications for registration. In that case, the set of attributes used for identities must be sufficient to represent multiple identities for a single entity.
システムがエンティティが複数の同時アイデンティティを登録できるようにする場合、2番目のプロパティは必要です。同じエンティティに対して2つ以上のアイデンティティを持つことは、エンティティに登録のための2つの別々の正当化があることを意味します。その場合、IDに使用される属性のセットは、単一のエンティティに対して複数のIDを表すのに十分でなければなりません。
Having two or more identities registered for the same entity is different from concurrently associating two different identifiers with the same identity, and also is different from a single identity concurrently accessing the system in two different roles. (See: principal, role-based access control.) When an identity of a user is being registered in a system, the system may require presentation of evidence that proves the identity's authenticity (i.e., that the user has the right to claim or use the identity) and its eligibility (i.e., that the identity is qualified to be registered and needs to be registered).
同じエンティティに対して登録された2つ以上のIDを有することは、2つの異なる識別子を同じ識別情報と同時に関連付けるとは異なり、また2つの異なる役割で同時にシステムにアクセスする単一のIDとは異なる。ユーザーの身元がシステムに登録されている場合、システムは、アイデンティティの信頼性を証明する証拠の提示を提示する必要があります（つまり、ユーザーが主張または使用する権利がある権利を有するIDとその適格性（すなわち、IDが登録され、登録されるべきであると認定されていること）。
The following diagram illustrates how this term relates to some other terms in a PKI system: authentication information, identifier, identifier credential, registration, registered user, subscriber, and user.
次の図は、この用語がPKIシステムの他の用語にどのように関係しているかを示しています。認証情報、識別子、識別子資格、登録、登録ユーザー、加入者、およびユーザー。
Relationships: === one-to-one, ==> one-to-many, <=> many-to-many.
+- - - - - - - - - - - - - - - - - - - - - - - - - - +
| PKI System |
+ - - - - + | +------------------+ +-------------------------+ |
| User, | | |Subscriber, i.e., | | Identity of Subscriber | |
|i.e., one| | | Registered User, | | is system-unique | |
| of the | | | is system-unique | | +---------------------+ | |
|following| | | +--------------+ | | | Subscriber | | |
| | | | | User's core | | | | Identity's | | |
| +-----+ |===| | Registration | |==>| | Registration data | | |
| |human| | | | | data, i.e., | | | |+-------------------+| | |
| |being| | | | | an entity's | | | || same core data || | |
| +-----+ | | | |distinguishing|========|for all Identities || | |
| or | | | | attribute | | | || of the same User || | |
| +-----+ | | | | values | | +===|+-------------------+| | |
| |auto-| | | | +--------------+ | | | +---------------------+ | |
| |mated| | | +------------------+ | +------------|------------+ |
| |pro- | | | | +=======+ | |
| |cess | | | +-------v----|----------------------|------------+ |
| +-----+ | | | +----------v---+ +------------v----------+ | |
| or | | | |Authentication|<===>|Identifier of Identity | | |
|+-------+| | | | Information | | is system-unique | | |
|| a set || | | +--------------+ +-----------------------+ | |
|| of || | | Identifier Credential that associates unit of | |
|| either|| | | Authentication Information with the Identifier | |
|+-------+| | +------------------------------------------------+ |
+ - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - -+
$ identity-based security policy (I) "A security policy based on the identities and/or attributes of users, a group of users, or entities acting on behalf of the users and the resources/objects being accessed." [I7498-2] (See: rule-based security policy.)
$ Identityベースのセキュリティポリシー（i）「ユーザーのID /または属性に基づくセキュリティポリシー、ユーザーのグループ、またはユーザーに代わってアクセスされているリソース/オブジェクトに行動するエンティティ。」[I7498-2]（ルールベースのセキュリティポリシーを参照）
$ identity proofing (I) A process that vets and verifies the information that is used to establish the identity of a system entity. (See: registration.)
$ ID校正（i）システムエンティティの識別情報を確立するために使用される情報を獣医および検証するプロセス。（登録を参照してください。）
$ IDOC (I) An abbreviation used in this Glossary to refer to a document or other item of written material that is generated in the Internet Standards Process (RFC 2026), i.e., an RFC, an Internet-Draft, or some other item of discourse.
$ IDoc（i）この用語集で使用されている略語は、インターネット規格プロセス（RFC 2026）で生成された文書またはその他の書面によるもの、すなわちRFC、インターネットドラフト、またはその他の談話項目を指す。
Deprecated Usage: This abbreviation SHOULD NOT be used in an IDOC unless it is first defined in the IDOC because the abbreviation was invented for this Glossary and is not widely known.
廃止予定の使用法：この省略形はIDocで最初に定義されていない限り、IDOCで使用しないでください。
$ IDS (I) See: intrusion detection system.
$ IDS（i）侵入検知システムを参照してください。
$ IEEE (N) See: Institute of Electrical and Electronics Engineers, Inc.
$ IEEE（N）社：電気電子機器株式会社エンジニア株式会社
$ IEEE 802.10 (N) An IEEE committee developing security standards for LANs. (See: SILS.)
$ IEEE 802.10（n）LANのためのセキュリティ基準を開発するIEEE委員会。（SILSを参照してください。）
$ IEEE P1363 (N) An IEEE working group, Standard for Public-Key Cryptography, engaged in developing a comprehensive reference standard for asymmetric cryptography. Covers discrete logarithm (e.g., DSA), elliptic curve, and integer factorization (e.g., RSA); and covers key agreement, digital signature, and encryption.
$ IEEE P1363（n）非対称暗号化のための包括的な参照規格を開発することに従事し、公開鍵暗号化のためのIEEEワーキンググループ。離散対数（例えば、DSA）、楕円曲線、および整数因数分解（例えば、RSA）をカバー。主な合意、デジタル署名、および暗号化をカバーします。
$ IESG (I) See: Internet Engineering Steering Group.
$ IESG（I）インターネットエンジニアリングステアリンググループを参照してください。
$ IETF (I) See: Internet Engineering Task Force.
$ IETF（I）インターネットエンジニアリングタスクフォース。
$ IKE (I) See: IPsec Key Exchange.
$ IKE（I）IPsecキー交換を参照してください。
$ IMAP4 (I) See: Internet Message Access Protocol, version 4.
$ IMAP4（i）インターネットメッセージアクセスプロトコル、バージョン4を参照してください。
$ IMAP4 AUTHENTICATE (I) An IMAP4 command (better described as a transaction type, or subprotocol) by which an IMAP4 client optionally proposes a mechanism to an IMAP4 server to authenticate the client to the server and provide other security services. (See: POP3.) Tutorial: If the server accepts the proposal, the command is followed by performing a challenge-response authentication protocol and, optionally, negotiating a protection mechanism for subsequent POP3 interactions. The security mechanisms that are used by IMAP4 AUTHENTICATE -- including Kerberos, GSS-API, and S/Key -- are described in [R1731].
IMAP4コマンド（i）IMAP4コマンド（トランザクションタイプ、またはサブプロトコルとして説明されている）を認証（i）IMAP4クライアントが、クライアントをサーバーに認証し、他のセキュリティサービスを提供するためのメカニズムを任意に提案します。（POP3。）チュートリアル：サーバーがプロポーザルを受け入れると、コマンドの後にチャレンジ応答認証プロトコルを実行し、オプションで、後続のPOP3インタラクションの保護メカニズムをネゴシエートします。Kerberos、GSS-API、およびS / Keyを含むIMAP4によって使用されるセキュリティメカニズムは[R1731]に記載されています。
$ impossible (O) Cannot be done in any reasonable amount of time. (See: break, brute force, strength, work factor.)
$ 不可能（O）は任意の妥当な時間ではできません。（断線、ブルート力、強さ、仕事係数）
$ in the clear (I) Not encrypted. (See: clear text.)
$ 明確な（i）暗号化されていません。（テキストをクリアします。）
$ Ina Jo (O) A methodology, language, and integrated set of software tools developed at the System Development Corporation for specifying, coding, and verifying software to produce correct and reliable programs. Usage: a.k.a. the Formal Development Methodology. [Cheh]
$ INA JO（O）システム開発株式会社で開発された方法論、言語、および統合されたソフトウェアツールのセットは、ソフトウェアを作成、符号化、および検証し、正しい信頼性の高いプログラムを作成する。使用法：a.k.a.正式な開発方法論。[Cheh]
$ incapacitation (I) A type of threat action that prevents or interrupts system operation by disabling a system component. (See: disruption.)
$ 無益（i）システムコンポーネントを無効にすることでシステム操作を防止または中断する脅威アクションの一種。（混乱を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Malicious logic": In context of incapacitation, any hardware, firmware, or software (e.g., logic bomb) intentionally introduced into a system to destroy system functions or resources. (See: corruption, main entry for "malicious logic", masquerade, misuse.) - "Physical destruction": Deliberate destruction of a system component to interrupt or prevent system operation. - "Human error": /incapacitation/ Action or inaction that unintentionally disables a system component. (See: corruption, exposure.) - "Hardware or software error": /incapacitation/ Error that unintentionally causes failure of a system component and leads to disruption of system operation. (See: corruption, exposure.) - "Natural disaster": /incapacitation/ Any "act of God" (e.g., fire, flood, earthquake, lightning, or wind) that disables a system component. [FP031 Section 2]
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。（汚職、「悪意のある論理」の主なエントリー、マスカレード、誤用。） - 「物理破壊」：システムコンポーネントの破壊を慎重に破壊するシステムの操作を中断または防止する。 - 「ヒューマンエラー」：/無能/アクションまたは不作為でシステムコンポーネントを無効にします。（汚職、露出。） - 「ハードウェアまたはソフトウェアのエラー」：/無能/エラーが意図せずにシステムコンポーネントの障害を引き起こし、システム操作の中断につながります。（汚職、露出。） - 「自然災害」：/軽減/システム構成要素を無効にする「神の行為」（例えば、火、洪水、地震、雷、風）。[FP031セクション2]
$ incident See: security incident.
$ 事件参照：セキュリティインシデント。
$ INCITS (N) See: "International Committee for Information Technology Standardization" under "ANSI".
$ 「ANSI」の「情報技術標準化のための国際委員会」を参照してください。
$ indicator (N) An action -- either specific, generalized, or theoretical -- that an adversary might be expected to take in preparation for an attack. [C4009] (See: "attack sensing, warning, and response". Compare: message indicator.)
$ インジケーター（n）敵対的、一般化された、または理論的な行動は、敵対者が攻撃に準備すると予想されるかもしれないということです。[C4009]（「攻撃センシング、警告、および応答」を参照してください。比較：メッセージインジケータ。）
$ indirect attack (I) See: secondary definition under "attack". Compare: direct attack.
$ 間接攻撃（i）「攻撃」の下の二次定義を参照してください。比較：直接攻撃。
$ indirect certificate revocation list (ICRL) (N) In X.509, a CRL that may contain certificate revocation notifications for certificates issued by CAs other than the issuer (i.e., signer) of the ICRL.
$ 間接証明書失効リスト（N）（N）X.509では、ICRLの発行者（すなわち署名者）以外のCASによって発行された証明書の証明書失効通知を含むことができるCRL。
$ indistinguishability (I) An attribute of an encryption algorithm that is a formalization of the notion that the encryption of some string is indistinguishable from the encryption of an equal-length string of nonsense. (Compare: semantic security.)
$ 識別性（i）いくつかの文字列の暗号化が等長文字列の暗号化と区別がつかない概念の形式化である暗号化アルゴリズムの属性。（比較：意味セキュリティ。）
$ inference 1. (I) A type of threat action that reasons from characteristics or byproducts of communication and thereby indirectly accesses sensitive data, but not necessarily the data contained in the communication. (See: traffic analysis, signal analysis.)
$ 推論1.（i）通信の特性または副産物からの理由で、それによって機密データにアクセスしたが、必ずしも通信に含まれるデータにアクセスするタイプの脅威行動。（「交通分析、信号解析」を参照）
2. (I) A type of threat action that indirectly gains unauthorized access to sensitive information in a database management system by correlating query responses with information that is already known.
2. （i）クエリ応答をすでに知られている情報と関連付けることによって、データベース管理システム内の機密情報への不正アクセスへの不正アクセスを間接的に獲得するタイプの脅威アクション。
$ inference control (I) Protection of data confidentiality against inference attack. (See: traffic-flow confidentiality.)
$ 推論制御（I）推論攻撃に対するデータ機密性の保護（「トラフィックフロー機密性」を参照）
Tutorial: A database management system containing N records about individuals may be required to provide statistical summaries about subsets of the population, while not revealing sensitive information about a single individual. An attacker may try to obtain sensitive information about an individual by isolating a desired record at the intersection of a set of overlapping queries. A system can attempt to prevent this by restricting the size and overlap of query sets, distorting responses by rounding or otherwise perturbing database values, and limiting queries to random samples. However, these techniques may be impractical to implement or use, and no technique is totally effective. For example, restricting the minimum size of a query set -- that is, not responding to queries for which there are fewer than K or more than N-K records that satisfy the query -- usually cannot prevent unauthorized disclosure. An attacker can pad small query sets with extra records, and then remove the effect of the extra records. The formula for identifying the extra records is called the "tracker". [Denns]
チュートリアル：個人に関する機密情報を明らかにしない一方で、個人に関するNレコードを含むデータベース管理システムが、個人に関する機密情報を明らかにしない一方で、人口のサブセットに関する統計的要約を提供する必要があるかもしれません。攻撃者は、重複する一連のクエリの交差点で所望のレコードを分離することによって、個人に関する機密情報を取得しようとすることができる。システムは、クエリセットのサイズとオーバーラップ、丸め、またはその他の方法でデータベース値を乱したり、クエリをランダムなサンプルに制限することで、これを防ぐことができます。しかしながら、これらの技術は実施または使用が実用的ではない可能性があり、そして技術は全く有効ではない。たとえば、クエリセットの最小サイズを制限します。つまり、クエリを満たすN-Kレコードよりもk以上のクエリに応答しない - 通常、不正な開示を防ぐことはできません。攻撃者は追加のレコードを含む小さなクエリセットを埋めることができ、その後追加のレコードの効果を削除することができます。追加のレコードを識別するための式は「Tracker」と呼ばれます。 [Denns]
$ INFOCON (O) See: information operations condition
$ Infocon（O）情報操作の条件を参照してください
$ informal (N) Expressed in natural language. [CCIB] (Compare: formal, semiformal.)
$ 非公式（n）自然言語で表現されています。[CCIB]（比較：正式、半整数）
$ information 1. (I) Facts and ideas, which can be represented (encoded) as various forms of data.
$ 情報1.（i）さまざまな形式のデータとして表現（符号化）できる事実とアイデア。
2. (I) Knowledge -- e.g., data, instructions -- in any medium or form that can be communicated between system entities.
2. （i）知識 - 例えば、データ、命令 - システムエンティティ間で伝達され得る任意の媒体または形式で。
Tutorial: Internet security could be defined simply as protecting information in the Internet. However, the perceived need to use different protective measures for different types of information (e.g., authentication information, classified information, collateral information, national security information, personal information, protocol control information, sensitive compartmented information, sensitive information) has led to the diversity of terminology listed in this Glossary.
チュートリアル：インターネットセキュリティは、インターネット内の保護情報として定義できます。しかしながら、異なる種類の情報に対して異なる保護措置を使用する必要性（例えば、認証情報、分類情報、担保情報、国家セキュリティ情報、個人情報、プロトコル管理情報、敏感なコンパートメント情報、機密情報）が多様性をもたらした。この用語集に記載されている用語の
$ information assurance (N) /U.S. Government/ "Measures that protect and defend information and information systems by ensuring their availability integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities." [C4009]
$ 情報保証（N）/U.S。政府/「認証、認証、機密性、および否認を確実にすることによって情報や情報システムを保護し損害する措置。これらの対策には、保護、検出、および反応能力を取り入れることによって情報システムの回復を提供することが含まれます。」[C4009]
$ Information Assurance Technical Framework (IATF) (O) A publicly available document [IATF], developed through a collaborative effort by organizations in the U.S. Government and industry, and issued by NSA. Intended for security managers and system security engineers as a tutorial and reference document about security problems in information systems and networks, to improve awareness of tradeoffs among available technology solutions and of desired characteristics of security approaches for particular problems. (See: ISO 17799, [SP14].)
$ 情報保証技術フレームワーク（IATF）（O）公に入手可能な文書[IATF]は、米国政府と産業の組織による共同作業を通じて開発され、NSAによって発行されました。セキュリティマネージャおよびシステムセキュリティエンジニアと、情報システムやネットワークのセキュリティ問題についてのチュートリアルおよびリファレンス文書としてのテクノロジーの問題についてのテレビストリートのセキュリティ上の問題についての文書化、および特定の問題に対するセキュリティアプローチの望ましい特性について。（：ISO 17799、[SP14]参照）
$ information domain (O) See: secondary definition under "domain".
$ 情報ドメイン（O）「ドメイン」の下のセカンダリ定義を参照してください。
$ information domain security policy (O) See: secondary definition under "domain".
$ 情報ドメインセキュリティポリシー（O）「ドメイン」の下のセカンダリ定義。
$ information flow policy (N) /formal model/ A triple consisting of a set of security levels (or their equivalent security labels), a binary operator that maps each pair of security levels into a security level, and a binary relation on the set that selects a set of pairs of levels such that information is permitted to flow from an object of the first level to an object of the second level. (See: flow control, lattice model.)
$ 情報フローポリシー（N）/正式モデル/修正レベルのセキュリティレベル（またはそれらの同等のセキュリティラベル）からなるトリプル、セキュリティレベルの各ペアをセキュリティレベルにマッピングするバイナリ演算子、そのセットのバイナリ関係情報が第1のレベルのオブジェクトから第2のレベルのオブジェクトへのフローを許可されるように、レベルのペアのペアのペアを選択します。（以下を参照してください。格子モデル）
$ information operations condition (INFOCON) (O) /U.S. DoD/ A comprehensive defense posture and response based on the status of information systems, military operations, and intelligence assessments of adversary capabilities and intent. (See: threat)
$ 情報運用条件（Infocon）（O）/U.S。DOD /情報システムの状況、軍事業務、および敵対的能力と意図の諜報学的評価に基づく包括的な防衛姿勢と対応。（：脅威を参照）
Derivation: From DEFCON, i.e., defense condition.
派生：Defcon、すなわち防衛条件から。
Tutorial: The U.S. DoD defines five INFOCON levels: NORMAL (normal activity), ALPHA (increased risk of attack), BRAVO (specific risk of attack), CHARLIE (limited attack), and DELTA (general attack).
チュートリアル：米国のDODは、5つのインフォメンロングレベルを定義します。通常（通常の活動）、アルファ（攻撃のリスクの増加）、Bravo（攻撃の特定のリスク）、チャーリー（限定攻撃）、デルタ（一般的な攻撃）。
$ information security (INFOSEC) (N) Measures that implement and assure security services in information systems, including in computer systems (see: COMPUSEC) and in communication systems (see: COMSEC).
$ Information Security（InfoSec）（n）コンピュータシステム（Compusec）および通信システムを含む、情報システム内のセキュリティサービスを実装し保証すること（COMSECを参照）。
$ information system (I) An organized assembly of computing and communication resources and procedures -- i.e., equipment and services, together with their supporting infrastructure, facilities, and personnel -- that create, collect, record, process, store, transport, retrieve, display, disseminate, control, or dispose of information to accomplish a specified set of functions. (See: system entity, system resource. Compare: computer platform.)
$ 情報システム（i）コンピューティングおよび通信リソースおよび手順の組織化されたアセンブリ、すなわち、支援インフラ、設備、および人員とともに、設備およびサービス - それが作成、収集、記録、プロセス、ストア、輸送、検索、指定された関数のセットを達成するために情報を表示、普及、制御、制御、または廃棄します。（システムエンティティ、システムリソース。比較：コンピュータプラットフォーム。）
$ Information Technology Security Evaluation Criteria (ITSEC) (N) A Standard [ITSEC] jointly developed by France, Germany, the Netherlands, and the United Kingdom for use in the European Union; accommodates a wider range of security assurance and functionality combinations than the TCSEC. Superseded by the Common Criteria.
$ 情報技術セキュリティ評価基準（ITSEC）（N）欧州連合でのフランス、ドイツ、オランダ、イギリスによって共同開発された標準[ITSEC]。TCSECよりも広い範囲のセキュリティ保証と機能の組み合わせに対応します。一般的な基準に置き換えられました。
$ INFOSEC (I) See: information security.
$ InfoSec（i）情報セキュリティを参照してください。
$ ingress filtering (I) A method [R2827] for countering attacks that use packets with false IP source addresses, by blocking such packets at the boundary between connected networks.
$ 入力されたネットワーク間の境界でそのようなパケットをブロックすることによって、誤ったIP送信元アドレスを持つパケットを使用する攻撃に対抗する方法[R2827]。
Tutorial: Suppose network A of an internet service provider (ISP) includes a filtering router that is connected to customer network B, and an attacker in B at IP source address "foo" attempts to send packets with false source address "bar" into A. The false address may be either fixed or randomly changing, and it may either be unreachable or be a forged address that legitimately exists within either B or some other network C. In ingress filtering, the ISP's router blocks all inbound packet that arrive from B with a source address that is not within the range of legitimately advertised addresses for B. This method does not prevent all attacks that can originate from B, but the actual source of such attacks can be more easily traced because the originating network is known.
チュートリアル：インターネットサービスプロバイダ（ISP）のネットワークAには、顧客ネットワークBに接続されているフィルタリングルータが含まれ、IPソースアドレス「Foo」の攻撃者は、誤送信元アドレス「BAR」にパケットを送信しようとします。。偽アドレスは固定またはランダムに変化する可能性があり、到達不能であるか、または著しく存在する鍛造アドレスである可能性があります。入力フィルタリングでは、ISPのルータはBから到着したすべてのインバウンドパケットをブロックします。B.この方法では、Bに応じたすべての攻撃を妨げていない。
$ initialization value (IV) (I) /cryptography/ An input parameter that sets the starting state of a cryptographic algorithm or mode. (Compare: activation data.)
$ 初期化値（iv）/暗号化/暗号化アルゴリズムまたはモードの開始状態を設定する入力パラメータ。（比較：アクティベーションデータ。）
Tutorial: An IV can be used to synchronize one cryptographic process with another; e.g., CBC, CFB, and OFB use IVs. An IV also can be used to introduce cryptographic variance (see: salt) besides that provided by a key.
チュートリアル：IVを使用して、1つの暗号プロセスを別の暗号化プロセスを同期させることができます。例えば、CBC、CFB、およびOFBはIVを使用する。IVはまた、キーが提供するもの以外に、暗号分散（塩を参照）を導入するためにも使用することができる。
$ initialization vector (D) /cryptography/ Synonym for "initialization value".
$ 初期化ベクトル（D）/暗号化/「初期化値」の同義語。
Deprecated Term: To avoid international misunderstanding, IDOCs SHOULD NOT use this term in the context of cryptography because most dictionary definitions of "vector" includes a concept of direction or magnitude, which are irrelevant to cryptographic use.
廃止予定の期間：国際誤解を避けるために、IDOCは暗号化のための概念を含み、これは暗号化の使用とは無関係です。
$ insertion 1. (I) /packet/ See: secondary definition under "stream integrity service".
$ 挿入1.（i）/ packet / see：「Stream Integrity Service」の下のセカンダリ定義。
2. (I) /threat action/ See: secondary definition under "falsification".
2. （i）/脅威の処置/参照：「改ざん」の下の二次定義。
$ inside attack (I) See: secondary definition under "attack". Compare: insider.
$ 内部攻撃（i）「攻撃」の下の二次定義を参照してください。比較：インサイダー。
$ insider 1. (I) A user (usually a person) that accesses a system from a position that is inside the system's security perimeter. (Compare: authorized user, outsider, unauthorized user.)
$ インサイダー1.（i）システムのセキュリティ境界内にある位置からシステムにアクセスするユーザー（通常は人）。（比較：承認されたユーザー、アウトサイダー、不正なユーザー。）
Tutorial: An insider has been assigned a role that has more privileges to access system resources than do some other types of users, or can access those resources without being constrained by some access controls that are applied to outside users. For example, a salesclerk is an insider who has access to the cash register, but a store customer is an outsider.
チュートリアル：インサイダーには、他の種類のユーザーが他の種類のユーザーよりもシステムリソースにアクセスするための特権がある、あるいは、外部ユーザーに適用されるいくつかのアクセスコントロールによって制約されずにそれらのリソースにアクセスできる役割が割り当てられています。たとえば、Salesclerkは、現金登録簿にアクセスできるインサイダーですが、店舗顧客は部外者です。
The actions performed by an insider in accessing the system may be either authorized or unauthorized; i.e., an insider may act either as an authorized user or as an unauthorized user.
システムにアクセスする際のインサイダーによって実行された行動は、許可されているか不正であればよい。すなわち、インサイダーは、許可されたユーザまたは不正なユーザとしても行動することができる。
2. (O) A person with authorized physical access to the system. Example: In this sense, an office janitor is an insider, but a burglar or casual visitor is not. [NRC98]
2. （O）システムへの承認された物理的アクセスを持つ人。例：この意味で、オフィスの商人はインサイダーですが、盗難やカジュアルな訪問者はそうではありません。[NRC98]
3. (O) A person with an organizational status that causes the system or members of the organization to view access requests as being authorized. Example: In this sense, a purchasing agent is an insider but a vendor is not. [NRC98]
3. （o）組織のシステムまたはメンバーが承認されたとしてアクセス要求を表示させる組織状況を持つ人。例：この意味で、購買エージェントはインサイダーですが、ベンダーはそうではありません。[NRC98]
$ inspectable space (O) /EMSEC/ "Three-dimensional space surrounding equipment that process classified and/or sensitive information within which TEMPEST exploitation is not considered practical or where legal authority to identify and/or remove a potential TEMPEST exploitation exists." [C4009] (Compare: control zone, TEMPEST zone.)
$ 検査可能な空間（O）/ EMSEC /「テンペストの搾取が実用的であると見なされない、または潜在的な緊急事態を識別および/または削除する法的権限が存在しない、分類および/または機密性の高い情報を囲む3次元空間。」[C4009]（Compare：Control Zone、Tempest Zone。）
$ Institute of Electrical and Electronics Engineers, Inc. (IEEE) (N) The IEEE is a not-for-profit association of approximately 300,000 individual members in 150 countries. The IEEE produces nearly one third of the world's published literature in electrical engineering, computers, and control technology; holds hundreds of major, annual conferences; and maintains more than 800 active standards, with many more under development. (See: SILS.)
$ 電気電子機器技術研究所（IEEE）（N）IEEEは、150カ国で約30万人の個人会員の非営利団体です。IEEEは、電気工学、コンピュータ、および制御技術において、世界の公表されている文学の約3分の1を生産しています。何百もの主要な年次会議を開催します。そしてより多くの開発中の多くの800以上の活発な標準を維持します。（SILSを参照してください。）
$ integrity See: data integrity, datagram integrity service, correctness integrity, source integrity, stream integrity service, system integrity.
$ Integrity See：データの整合性、データグラムの整合性サービス、正確さの整合性、ソースの整合性、ストリームの整合性サービス、システムの整合性。
$ integrity check (D) A computation that is part of a mechanism to provide data integrity service or data origin authentication service. (Compare: checksum.)
$ 整合性チェック（d）データインテグリティサービスまたはデータオリジナル認証サービスを提供するメカニズムの一部である計算。（Compare：チェックサム。）
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for "cryptographic hash" or "protected checksum". This term unnecessarily duplicates the meaning of other, well-established terms; this term only mentions integrity, even though the intended service may be data origin authentication; and not every checksum is cryptographically protected.
廃止予定語：IDocは、この用語を「暗号化ハッシュ」または「保護チェックサム」の同義語として使用しないでください。この用語は、不必要に他の確立された用語の意味を複製します。意図されたサービスがデータ原点認証になる場合でも、この用語は誠実さだけでは誠実さを想像しています。すべてのチェックサムが暗号的に保護されているわけではありません。
$ integrity label (I) A security label that tells the degree of confidence that may be placed in the data, and may also tell what countermeasures are required to be applied to protect the data from alteration and destruction. (See: integrity. Compare: classification label.)
$ 整合性ラベル（i）データに配置される可能性がある信頼度を伝えるセキュリティラベルであり、変更や破壊からデータを保護するためにどの対策を適用する必要があるかを知ることがあります。（整合性を参照してください。比較：分類ラベル。）
$ intelligent threat (I) A circumstance in which an adversary has the technical and operational ability to detect and exploit a vulnerability and also has the demonstrated, presumed, or inferred intent to do so. (See: threat.)
$ インテリジェントな脅威（i）敵対者が脆弱性を検出し利用するための技術的および運用上の能力を持っている状況であり、それを行うという実証、推定、または推測された意図も持っています。（脅威を参照してください。）
$ interception (I) A type of threat action whereby an unauthorized entity directly accesses sensitive data while the data is traveling between authorized sources and destinations. (See: unauthorized disclosure.)
$ 傍受（i）不正なエンティティが認定された情報源と宛先の間の移動中に、不正なエンティティが機密データに直接アクセスします。（未承認の開示を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Theft": Gaining access to sensitive data by stealing a shipment of a physical medium, such as a magnetic tape or disk, that holds the data. - "Wiretapping (passive)": Monitoring and recording data that is flowing between two points in a communication system. (See: wiretapping.) - "Emanations analysis": Gaining direct knowledge of communicated data by monitoring and resolving a signal that is emitted by a system and that contains the data but was not intended to communicate the data. (See: emanation.)
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「盗難」：磁気テープやディスクなどの物理的媒体の出荷を盗むことによって機密データへのアクセスを取得します。 - 「盗聴（パッシブ）」：通信システム内の2点間に流れる監視および記録データ。（盗聴する。） - 「発言分析」：システムによって発行され、データを含むがデータを通信することを意図していなかった信号を監視および解決することによって、通信データの直接知識を得る。（発症を参照してください。）
$ interference (I) /threat action/ See: secondary definition under "obstruction".
$ 干渉（I）/脅威の処置/参照：「障害物」の下の二次定義。
$ intermediate CA (D) The CA that issues a cross-certificate to another CA. [X509] (See: cross-certification.) Deprecated Term: IDOCs SHOULD NOT use this term because it is not widely known and mixes concepts in a potentially misleading way. For example, suppose that end entity 1 ("EE1) is in one PKI ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). Then, if EE1 constructs the certification path CA1-to-CA2-to-EE2 to validate a certificate of EE2, conventional English usage would describe CA2 as being in the "intermediate" position in that path, not CA1.
$中間CA（d）相互証明書を別のCAに発行するCA。[X509]（以下を参照してください。）廃止予定の用語：IDocは、広く知られていないため、潜在的に誤解を招くような方法で概念を混在させるため、この用語を使用しないでください。例えば、エンドエンティティ1（「EE1）は1つのPKI（「PKI1」）にあると仮定して、エンドエンティティ2（「EE2）は別のPKI（「PKI2」）にあり、そしてPKI1（「CA1」）クロス - PKI2（「CA2」）の根のCAを認証します。次に、EE1がEE2の証明書を検証するためにEE1が認証パスを構築する場合、従来の英語の使用法はCA2ではなくCA2ではなく、そのパス内の「中間」位置にあると説明します。
$ internal controls (I) /COMPUSEC/ Functions, features, and technical characteristics of computer hardware and software, especially of operating systems. Includes mechanisms to regulate the operation of a computer system with regard to access control, flow control, and inference control. (Compare: external controls.)
$ 特にオペレーティングシステムの、コンピュータハードウェアとソフトウェアの内部統制（I）/ Compusec /機能、機能、および技術的特徴。アクセス制御、フロー制御、および推論制御に関してコンピュータシステムの動作を調整するためのメカニズムを含む。（比較：外部コントロール。）
$ International Data Encryption Algorithm (IDEA) (N) A patented, symmetric block cipher that uses a 128-bit key and operates on 64-bit blocks. [Schn] (See: symmetric cryptography.)
$ 国際データ暗号化アルゴリズム（IDEA）（n）128ビットキーを使用して64ビットブロックで動作する特許取得済みの対称ブロック暗号。[シュン]（対称暗号化を参照）
$ International Standard (N) See: secondary definition under "ISO".
$ 国際規格（N）参照：「ISO」の下の二次定義。
$ International Traffic in Arms Regulations (ITAR) (O) Rules issued by the U.S. State Department, by authority of the Arms Export Control Act (22 U.S.C. 2778), to control export and import of defense articles and defense services, including information security systems, such as cryptographic systems, and TEMPEST suppression technology. (See: type 1 product, Wassenaar Arrangement.)
$ 米国国務省によって発行された武器規制（ITAR）（ITAR）（o）米国州部門が発行した規則（22 USC 2778）、情報セキュリティシステムを含む防衛記事および防衛サービスの輸出入および輸入暗号システム、およびテンペスト抑制技術など。（：タイプ1製品、Wassenaarの配置）
$ internet, Internet 1. (I) /not capitalized/ Abbreviation of "internetwork".
$ インターネット、インターネット1.（i）/「インターネットワーク」の資本化/略語。
2. (I) /capitalized/ The Internet is the single, interconnected, worldwide system of commercial, governmental, educational, and other computer networks that share (a) the protocol suite specified by the IAB (RFC 2026) and (b) the name and address spaces managed by the ICANN. (See: Internet Layer, Internet Protocol Suite.)
2. （i）/資本化/インターネットは、IAB（RFC 2026）と（B）との名前と名前とその名前を共有するシングル、インターネンス、政府、教育、およびその他のコンピュータネットワークです。ICANNによって管理されているアドレススペース。（インターネットレイヤー、インターネットプロトコルスイートを参照してください。）
Usage: Use with definite article ("the") when using as a noun. For example, say "My LAN is small, but the Internet is large." Don't say "My LAN is small, but Internet is large."
使用法：名詞として使用するときは、明確な記事（「」）で使用してください。例えば、「私のLANは小さいが、インターネットは大きい」と言う。「私のLANは小さいですが、インターネットが大きい」と言わないでください。
$ Internet Architecture Board (IAB) (I) A technical advisory group of the ISOC, chartered by the ISOC Trustees to provide oversight of Internet architecture and protocols and, in the context of Internet Standards, a body to which decisions of the IESG may be appealed. Responsible for approving appointments to the IESG from among nominees submitted by the IETF nominating committee. (RFC 2026)
$ インターネットアーキテクチャボード（iab）（i）ISOC受託者が監督するためのISOCの受託者が傭し、インターネット規格の文脈では、IESGの決定が上訴される可能性がある体が訴えられているISOCの技術諮問グループ。。IETF指名委員会によって提出された候補者の中からIESGへの予定を承認する責任がある。（RFC 2026）
$ Internet Assigned Numbers Authority (IANA) (I) From the early days of the Internet, the IANA was chartered by the ISOC and the U.S. Government's Federal Network Council to be the central coordination, allocation, and registration body for parameters for Internet protocols. Superseded by ICANN.
$ インターネットの早い頃からインターネットが割り当てられた番号当局（i）（i）インターネットの初期の頃から、ISOCと米国政府の連邦ネットワークカウンシェルは、インターネットプロトコルのパラメータの中心的な調整、割り当て、および登録機関によってチャーターされました。ICANNに置き換えられました。
$ Internet Control Message Protocol (ICMP) (I) An Internet Standard protocol (RFC 792) that is used to report error conditions during IP datagram processing and to exchange other information concerning the state of the IP network.
$ インターネット制御メッセージプロトコル（ICMP）（i）IPデータグラム処理中にエラー状態を報告し、IPネットワークの状態に関する他の情報を交換するために使用されるインターネット標準プロトコル（RFC 792）。
$ Internet Corporation for Assigned Names and Numbers (ICANN) (I) The non-profit, private corporation that has assumed responsibility for the IP address space allocation, protocol parameter assignment, DNS management, and root server system management functions formerly performed under U.S. Government contract by IANA and other entities.
$ 割り当てられた名前と数字（ICANN）のインターネット株式会社（I）米国政府契約の下で行われていたIPアドレス空間割当、プロトコルパラメータの割り当て、DNS管理、およびルートサーバーシステム管理機能を想定している非営利団体。IANAや他のエンティティによって。
Tutorial: The IPS, as defined by the IETF and the IESG, contains numerous parameters, such as Internet addresses, domain names, autonomous system numbers, protocol numbers, port numbers, management information base OIDs, including private enterprise numbers, and many others. The Internet community requires that the values used in these parameter fields be assigned uniquely. ICANN makes those assignments as requested and maintains a registry of the current values.
チュートリアル：IETFとIESGによって定義されているIPSには、インターネットアドレス、ドメイン名、自律システム番号、プロトコル番号、ポート番号、管理情報ベースのOIDなどの多数のパラメータが含まれています。インターネットコミュニティは、これらのパラメータフィールドで使用されている値を一意に割り当てる必要があります。ICANNは、それらの割り当てを要求されているとおりに、現在の値のレジストリを維持します。
ICANN was formed in October 1998, by a coalition of the Internet's business, technical, and academic communities. The U.S. Government designated ICANN to serve as the global consensus entity with responsibility for coordinating four key functions for the Internet: allocation of IP address space, assignment of protocol parameters, management of the DNS, and management of the DNS root server system.
ICANNは1998年10月に、インターネットのビジネス、技術的、および学術的コミュニティの連携によって形成されました。米国政府は、ICANNを指定して、インターネットの4つの重要な機能を調整する責任を持つGlobal Consensusエンティティを担当するように指定されています.IPアドレス空間の割り当て、プロトコルパラメータの割り当て、DNSの管理、およびDNSルートサーバシステムの管理。
$ Internet-Draft (I) A working document of the IETF, its areas, and its working groups. (RFC 2026) (Compare: RFC.) Usage: The term is customarily hyphenated when used either as a adjective or a noun, even though the latter is not standard English punctuation.
$インターネットドラフト（i）IETF、その分野、そしてその作業グループの作業文書。（RFC 2026）の使用法：後者が標準的な英語句読点ではないとしても、形容詞または名詞として使用されている場合は、通常ハイフン化されています。
Tutorial: An Internet-Draft is not an archival document like an RFC is. Instead, an Internet-Draft is a preliminary or working document that is valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use an Internet-Draft as reference material or to cite it other than as a "work in progress". Although most of the Internet-Drafts are produced by the IETF, any interested organization may request to have its working documents published as Internet-Drafts.
チュートリアル：インターネットドラフトは、RFCのようなアーカイブドキュメントではありません。代わりに、インターネットドラフトは、最大6ヶ月間有効である予備または作業文書であり、いつでも他の文書によって更新、交換、または時代遅れにすることができます。インターネットドラフトを参考資料として使用するのは不適切なものです。ほとんどのインターネットドラフトはIETFによって生産されていますが、任意の興味のある組織は、ワーキング文書をインターネットドラフトとして公開することを要求することがあります。
$ Internet Engineering Steering Group (IESG) (I) The part of the ISOC responsible for technical management of IETF activities and administration of the Internet Standards Process according to procedures approved by the ISOC Trustees. Directly responsible for actions along the "standards track", including final approval of specifications as Internet Standards. Composed of IETF Area Directors and the IETF chairperson, who also chairs the IESG. (RFC 2026)
$ インターネットエンジニアリングステアリンググループ（IESG）（i）IETF活動の技術的管理とISOC受託者によって承認された手順に従って、ISOCの技術的管理とインターネット基準の管理を担当します。インターネット標準としての仕様の最終承認を含む、「標準トラック」に沿った行動を直接責任を負う。IESGを務めるIETFエリア取締役とIETF委員長で構成されています。（RFC 2026）
$ Internet Engineering Task Force (IETF) (I) A self-organized group of people who make contributions to the development of Internet technology. The principal body engaged in developing Internet Standards, although not itself a part of the ISOC. Composed of Working Groups, which are arranged into Areas (such as the Security Area), each coordinated by one or more Area Directors. Nominations to the IAB and the IESG are made by a committee selected at random from regular IETF meeting attendees who have volunteered. (RFCs 2026, 3935) [R2323]
$ インターネットエンジニアリングタスクフォース（I）インターネット技術の発展に貢献する自己組織化された人々のグループ。それ自体はISOCの一部ではありませんが、インターネット規格の開発に従事しています。作業団で構成されており、それぞれが1つ以上のエリア取締役によって調整されています。IABおよびIESGへの指名は、ボランティアを受けた通常のIETFミーティング参加者からランダムに選択された委員会によって行われます。（RFCS 2026,3935）[R2323]
$ Internet Key Exchange (IKE) (I) An Internet, IPsec, key-establishment protocol [R4306] for putting in place authenticated keying material (a) for use with ISAKMP and (b) for other security associations, such as in AH and ESP.
$ インターネット鍵交換（IKE）（I）インターネット、IPSec、鍵設立プロトコル[R4306]は、AHやESPなどの他のセキュリティアソシエーションのために、ISAKMPと（B）で使用するためのプレイス認証キーイングマテリアル（A）。
Tutorial: IKE is based on three earlier protocol designs: ISAKMP, OAKLEY, and SKEME.
チュートリアル：IKEは3つの以前のプロトコルデザインに基づいています：ISAKMP、Oakley、およびSkeme。
$ Internet Layer (I) See: Internet Protocol Suite.
$ インターネットレイヤ（i）インターネットプロトコルスイートを参照してください。
$ Internet Message Access Protocol, version 4 (IMAP4) (I) An Internet protocol (RFC 2060) by which a client workstation can dynamically access a mailbox on a server host to manipulate and retrieve mail messages that the server has received and is holding for the client. (See: POP3.)
$ Internet Message Access Protocol、バージョン4（IMAP4）（i）クライアントワークステーションがサーバーホスト上のメールボックスに動的にアクセスしてサーバーが受信して保持しているメールメッセージを操作および取得できるインターネットプロトコル（RFC 2060）。クライアント。（：POP3を参照）
Tutorial: IMAP4 has mechanisms for optionally authenticating a client to a server and providing other security services. (See: IMAP4 AUTHENTICATE.)
チュートリアル：IMAP4には、オプションでクライアントをサーバーに認証し、他のセキュリティサービスを提供するためのメカニズムがあります。（参照：IMAP4認証を参照してください。）
$ Internet Open Trading Protocol (IOTP) (I) An Internet protocol [R2801] proposed as a general framework for Internet commerce, able to encapsulate transactions of various proprietary payment systems (e.g., GeldKarte, Mondex, SET, Visa Cash). Provides optional security services by incorporating various Internet security mechanisms (e.g., MD5) and protocols (e.g., TLS).
$ インターネットオープントレーディングプロトコル（I）インターネットプロトコル[R2801]は、さまざまな独自の支払いシステム（例えば、Geldkarte、Mondex、Set、Visa Cash）のトランザクションをカプセル化することができる、インターネットコマースの一般的なフレームワークとして提案されています。さまざまなインターネットセキュリティメカニズム（例えば、MD5）とプロトコル（例えば、TLS）を組み込むことで、オプションのセキュリティサービスを提供します。
$ Internet Policy Registration Authority (IPRA) (I) An X.509-compliant CA that is the top CA of the Internet certification hierarchy operated under the auspices of the ISOC [R1422]. (See: /PEM/ under "certification hierarchy".)
$ インターネットポリシー登録局（IPRA）（i）ISOCの後援の下で操作されたインターネット認定階層のTOP CAであるX.509準拠のCA。（：/ PEM /「認証階層」の下にある」。）
$ Internet Private Line Interface (IPLI) (O) A successor to the PLI, updated to use TCP/IP and newer military-grade COMSEC equipment (TSEC/KG-84). The IPLI was a portable, modular system that was developed for use in tactical, packet-radio networks. (See: end-to-end encryption.)
$ インターネットプライベートラインインタフェース（IPLI）（O）PLIの後継者は、TCP / IPおよび新しい軍用グレードのCOMSEC機器（TSEC / KG-84）を使用するように更新されました。IPLIは、戦術的なパケット無線ネットワークで使用するために開発された携帯型モジュラシステムであった。（End-to-End Encryptionを参照してください。）
$ Internet Protocol (IP) (I) An Internet Standard, Internet-Layer protocol that moves datagrams (discrete sets of bits) from one computer to another across an internetwork but does not provide reliable delivery, flow control, sequencing, or other end-to-end services that TCP provides. IP version 4 (IPv4) is specified in RFC 791, and IP version 6 (IPv6) is specified in RFC 2460. (See: IP address, TCP/IP.)
$ インターネットプロトコル（IP）（i）インターネットワークを介してデータグラムを移動するインターネット層プロトコル（I）インターネット層（ビットの離散ビット）をインターネットワークにわたって移動させますが、信頼性の高い配信、フロー制御、シーケンス、またはその他のエンドツーへのインターネット層プロトコルがありません。-End TCPが提供するサービス。IPバージョン4（IPv4）はRFC 791で指定され、IPバージョン6（IPv6）はRFC 2460で指定されています。（IPアドレス、TCP / IPを参照）
Tutorial: If IP were used in an OSIRM stack, IP would be placed at the top of Layer 3, above other Layer 3 protocols in the stack.
チュートリアル：IPがOSIRRスタックで使用されている場合、IPはスタック内の他のレイヤ3プロトコルの上にあるレイヤ3の上部に配置されます。
In any IPS stack, IP is always present in the Internet Layer and is always placed at the top of that layer, on top of any other protocols that are used in that layer. In some sense, IP is the only protocol specified for the IPS Internet Layer; other protocols used there, such as AH and ESP, are just IP variations.
IPSスタックでは、IPは常にインターネット層に存在し、そのレイヤで使用される他のプロトコルの上に常にそのレイヤの上部に配置されます。ある意味では、IPはIPSインターネットレイヤに指定された唯一のプロトコルです。AHやESPなど、そこで使用される他のプロトコルは単なるIPバリエーションです。
$ Internet Protocol security See: IP Security Protocol.
$ インターネットプロトコルセキュリティ：IPセキュリティプロトコルを参照してください。
$ Internet Protocol Security Option (IPSO) (I) Refers to one of three types of IP security options, which are fields that may be added to an IP datagram for carrying security information about the datagram. (Compare: IPsec.)
$ インターネットプロトコルセキュリティオプション（IPSO）（i）は、データグラムに関するセキュリティ情報を伝送するためにIPデータグラムに追加される可能性があるフィールドである3種類のIPセキュリティオプションのうちの1つを指します。（比較：IPSEC。）
Deprecated Usage: IDOCs SHOULD NOT use this term without a
modifier to indicate which of the following three types is meant:
- "DoD Basic Security Option" (IP option type 130): Defined for
use on U.S. DoD common-use data networks. Identifies the DoD
classification level at which the datagram is to be protected
and the protection authorities whose rules apply to the
datagram. (A "protection authority" is a National Access
Program (e.g., GENSER, SIOP-ESI, SCI, NSA, Department of
Energy) or Special Access Program that specifies protection
rules for transmission and processing of the information
contained in the datagram.) [R1108]
- "DoD Extended Security Option" (IP option type 133): Permits
additional security labeling information, beyond that present
in the Basic Security Option, to be supplied in the datagram to
meet the needs of registered authorities. [R1108]
- "Common IP Security Option" (CIPSO) (IP option type 134):
Designed by TSIG to carry hierarchic and non-hierarchic
security labels. (Formerly called "Commercial IP Security
Option"; a version 2.3 draft was published 9 March 1993 as an
Internet-Draft but did not advance to RFC form.) [CIPSO]
$ Internet Protocol Suite (IPS) (I) The set of network communication protocols that are specified by the IETF, and approved as Internet Standards by the IESG, within the oversight of the IAB. (See: OSIRM Security Architecture. Compare: OSIRM.)
$ Internet Protocol Suite（IPS）（i）IETFによって指定され、IESGによってIESGによってインターネット規格として承認された一連のネットワーク通信プロトコルのセット。（OSIRDセキュリティアーキテクチャを参照してください。比較：Osirm。）
Usage: This set of protocols is popularly known as "TCP/IP" because TCP and IP are its most basic and important components.
使用法：TCPとIPは最も基本的で重要なコンポーネントであるため、このプロトコルのセットは「TCP / IP」として一般的に知られています。
For clarity, this Glossary refers to IPS protocol layers by name and capitalizes those names, and refers to OSIRM protocol layers by number.
明確にするために、この用語集は名前によるIPSプロトコルレイヤーを指し、それらの名前を大動力化し、OSIRRプロトコル層を番号別に参照します。
Tutorial: The IPS does have architectural principles [R1958], but there is no Internet Standard that defines a layered IPS reference model like the OSIRM. Still, Internet community literature has referred (inconsistently) to IPS layers since early in the Internet's development [Padl].
チュートリアル：IPSはアーキテクチャの原則[R1958]を持っていますが、OSIRMのような階層化されたIPS参照モデルを定義するインターネット標準はありません。それでも、インターネットコミュニティの文献は、インターネットの開発の早い時期からIPS層に（矛盾する）を参照しています[PADL]。
This Glossary treats the IPS as having five protocol layers -- Application, Transport, Internet, Network Interface, and Network Hardware (or Network Substrate) -- which are illustrated in the following diagram:
この用語集は、IPSを5つのプロトコル層 - アプリケーション、トランスポート、インターネット、ネットワークインタフェース、およびネットワークハードウェア（またはネットワーク基板）を有するものとして扱うもので、次の図に示されている。
OSIRM Layers Examples IPS Layers Examples
------------------ --------------- --------------- --------------
Message Format: P2 [X420] Message Format: ARPA (RFC 822)
+----------------+ +-------------+
|7.Application | P1 [X419] | Application | SMTP (RFC 821)
+----------------+ - - - - - - | |
|6.Presentation | [I8823] | |
+----------------+ - - - - - - | |
|5.Session | [I8327] +-------------+
+----------------+ - - - - - - | Transport | TCP (RFC 793)
|4.Transport | TP4 [I8073] | |
+----------------+ - - - - - - +-------------+
|3.Network | CLNP [I8473] | Internet | IP (RFC 791)
| | +-------------+
| | | Network | IP over IEEE
+----------------+ - - - - - - | Interface | 802 (RFC 1042)
|2.Data Link | +-------------+
| | LLC [I8802-2] - Network - The IPS does
| | MAC [I8802-3] - Hardware - not include
+----------------+ - (or Network - standards for
|1.Physical | Baseband - Substrate) - this layer.
+----------------+ Signaling [Stal] + - - - - - - +
The diagram approximates how the five IPS layers align with the seven OSIRM layers, and it offers examples of protocol stacks that provide roughly equivalent electronic mail service over a private LAN that uses baseband signaling.
この図は、5つのIPS層が7つのOSIRR層と整列する方法を近似し、ベースバンドシグナリングを使用するプライベートLANを介して大幅に等価な電子メールサービスを提供するプロトコルスタックの例を提供します。
- IPS Application Layer: The user runs an application program. The program selects the data transport service it needs -- either a sequence of data messages or a continuous stream of data -- and hands application data to the Transport Layer for delivery.
- IPSアプリケーションレイヤ：ユーザーはアプリケーションプログラムを実行します。プログラムは、それが必要とするデータ転送サービスまたはデータの連続的なデータストリーム、および配信のためにトランスポート層へのアプリケーションデータのいずれかを選択する。
- IPS Transport Layer: This layer divides application data into packets, adds a destination address to each, and communicates them end-to-end -- from one application program to another -- optionally regulating the flow and ensuring reliable (error-free and sequenced) delivery.
- IPSトランスポート層：このレイヤーはアプリケーションデータをパケットに分割し、それぞれに宛先アドレスを追加し、1つのアプリケーションプログラムから別のアプリケーションプログラムへのエンドツーエンドから別のアプリケーションプログラムへと通信します。）配達。
- IPS Internet Layer: This layer carries transport packets in IP datagrams. It moves each datagram independently, from its source computer to its addressed destination computer, routing the datagram through a sequence of networks and relays and selecting appropriate network interfaces en route.
- IPSインターネットレイヤー：このレイヤーはIPデータグラムのトランスポートパケットを運びます。各データグラムは、各データグラムをソースコンピュータからアドレス指定された宛先コンピュータに移動し、データグラムを一連のネットワークを介してルーティングし、ルートを適切なネットワークインタフェースを選択して選択します。
- IPS Network Interface Layer: This layer accepts datagrams for transmission over a specific network. This layer specifies interface conventions for carrying IP over OSIRM Layer 3 protocols and over Media Access Control sublayer protocols of OSIRM Layer 2. An example is IP over IEEE 802 (RFD 1042).
- IPSネットワークインタフェースレイヤ：このレイヤは特定のネットワークを介した送信のためのデータグラムを受け入れます。このレイヤーは、IPオーバーオフィスレイヤ3プロトコルおよびOver Media Access Controlサブレイヤプロトコルを搬送するためのインタフェース規則を指定します。例はIEEE802（RFD 1042）の上にIPです。
- IPS Network Hardware Layer: This layer consists of specific, physical communication media. However, the IPS does not specify its own peer-to-peer protocols in this layer. Instead, the layering conventions specified by the Network Interface Layer use Layer 2 and Layer 3 protocols that are specified by bodies other than the IETF. That is, the IPS addresses *inter*-network functions and does not address *intra*-network functions.
- IPSネットワークハードウェアレイヤ：このレイヤは、特定の物理的な通信媒体で構成されています。ただし、IPSはこのレイヤーに独自のピアツーピアプロトコルを指定しません。代わりに、ネットワークインタフェース層で指定された階層化規則は、IETF以外のボディによって指定されたレイヤ2とレイヤ3プロトコルを使用します。つまり、IPSは* INTER * -NENTWORK関数であり、* INTRA * -NENTWORK関数をアドレス指定しません。
The two models are most dissimilar in the upper layers, where the IPS model does not include Session and Presentation layers. However, this omission causes fewer functional differences between the models than might be imagined, and the differences have relatively few security implications:
2つのモデルは上層の中で最も異なるものです。ここで、IPSモデルにはセッションとプレゼンテーションレイヤが含まれていません。ただし、この漏れは想像されているものよりもモデル間の機能的な違いが少なくなり、差異は比較的セキュリティの影響をほとんどありません。
- Formal separation of OSIRM Layers 5, 6, and 7 is not needed in implementations; the functions of these layers sometimes are mixed in a single software unit, even in protocols in the OSI suite.
- 吸収層5,6、および7の形式的な分離は実装においては必要とされない。これらのレイヤーの機能は、OSIスイート内のプロトコルでさえも、単一のソフトウェアユニットで混在することがあります。
- Some OSIRM Layer 5 services -- for example, connection termination -- are built into TCP, and the remaining Layer 5 and 6 functions are built into IPS Application-Layer protocols where needed.
- OSIRMレイヤ5サービス - たとえば、接続終了 - TCPに組み込まれており、残りのレイヤ5と6つの機能は必要に応じてIPSアプリケーション層プロトコルに組み込まれています。
- The OSIRM does not place any security services in Layer 5 (see: OSIRM Security Architecture).
- OSIRRはセキュリティサービスをレイヤ5に配置しません（OSIRDセキュリティアーキテクチャーを参照）。
- The lack of an explicit Presentation Layer in the IPS sometimes makes it simpler to implement security in IPS applications. For example, a primary function of Layer 6 is to convert data between internal and external forms, using a transfer syntax to unambiguously encode data for transmission. If an OSIRM application encrypts data to protect against disclosure during transmission, the transfer encoding must be done before the encryption. If an application does encryption, as is done in OSI message handling and directory service protocols, then Layer 6 functions must be replicated in Layer 7. [X400, X500].
- IPS内の明示的なプレゼンテーション層の欠如は、IPSアプリケーションでセキュリティを実装する方が簡単になります。例えば、レイヤ6の主な関数は、伝達のためのデータを明確に符号化するための転送シンタックスを使用して、内部および外部形式の間でデータを変換することである。OSIRRアプリケーションが送信中に開示から保護するためにデータを暗号化する場合、転送エンコーディングは暗号化の前に行われなければなりません。アプリケーションがOSIメッセージ処理およびディレクトリサービスプロトコルで行われるように、アプリケーションが暗号化した場合は、レイヤ6の機能をレイヤ7で複製する必要があります。[X400、X500]。
The two models are most alike at the top of OSIRM Layer 3, where the OSI Connectionless Network Layer Protocol (CLNP) and the IPS IP are quite similar. Connection-oriented security services offered in OSIRM Layer 3 are inapplicable in the IPS, because the IPS Internet Layer lacks the explicit, connection-oriented service offered in the OSIRM.
2つのモデルはOSIRMレイヤ3の上部に最も似ています。ここで、OSIコネクションレスネットワークレイヤプロトコル（CLNP）とIPS IPは非常に似ています。OSIRMレイヤ3で提供される接続指向のセキュリティサービスは、IPSインターネットレイヤーには、OSIRMで提供されている明示的な接続指向サービスが不足しているため、IPSでは使用できません。
$ Internet Security Association and Key Management Protocol (ISAKMP) (I) An Internet IPsec protocol [R2408] to negotiate, establish, modify, and delete security associations, and to exchange key generation and authentication data, independent of the details of any specific key generation technique, key establishment protocol, encryption algorithm, or authentication mechanism.
$ インターネットセキュリティアソシエーションおよび鍵管理プロトコル（I）セキュリティアソシエーションをネゴシエーション、確立、変更、削除、および鍵生成、認証データを交換するためのインターネットIPSecプロトコル[R2408]テクニック、キー確立プロトコル、暗号化アルゴリズム、または認証メカニズム。
Tutorial: ISAKMP supports negotiation of security associations for protocols at all IPS layers. By centralizing management of security associations, ISAKMP reduces duplicated functionality within each protocol. ISAKMP can also reduce connection setup time, by negotiating a whole stack of services at once. Strong authentication is required on ISAKMP exchanges, and a digital signature algorithm based on asymmetric cryptography is used within ISAKMP's authentication component.
チュートリアル：ISAKMPは、すべてのIPSレイヤのプロトコルのセキュリティアソシエーションのネゴシエーションをサポートしています。セキュリティアソシエーションの管理を集中化することで、ISAKMPは各プロトコル内の重複した機能を削減します。ISAKMPは、一度にサービスのスタック全体を交渉することによって、接続設定時間を短縮することもできます。ISAKMP交換には強い認証が必要であり、非対称暗号化に基づくデジタル署名アルゴリズムがISAKMPの認証コンポーネント内で使用されます。
ISAKMP negotiations are conducted in two "phases": - "Phase 1 negotiation". A phase 1 negotiation establishes a security association to be used by ISAKMP to protect its own protocol operations. - "Phase 2 negotiation". A phase 2 negotiation (which is protected by a security association that was established by a phase 1 negotiation) establishes a security association to be used to protect the operations of a protocol other than ISAKMP, such as ESP.
ISAKMP交渉は2つの「フェーズ」で行われます。 - 「フェーズ1ネゴシエーション」。フェーズ1ネゴシエーションは、独自のプロトコル操作を保護するためにISAKMPによって使用されるセキュリティアソシエーションを確立します。 - 「フェーズ2ネゴシエーション」フェーズ2ネゴシエーション（フェーズ1ネゴシエーションによって確立されたセキュリティアソシエーションによって保護されている）は、ESPなどのISAKMP以外のプロトコルの動作を保護するために使用されるセキュリティアソシエーションを確立します。
$ Internet Society (ISOC) (I) A professional society concerned with Internet development (including technical Internet Standards); with how the Internet is and can be used; and with social, political, and technical issues that result. The ISOC Board of Trustees approves appointments to the IAB from among nominees submitted by the IETF nominating committee. (RFC 2026)
$ インターネット社会（ISOC）（I）インターネット開発に関する専門社会（技術インターネット規格を含む）。インターネットがどのようにして使用できるかそしてそれが社会的、政治的、そして技術的な問題を抱えています。ISOC受託会社は、IETF指名委員会によって提出された候補者の中からIABへの予定を承認します。（RFC 2026）
$ Internet Standard (I) A specification, approved by the IESG and published as an RFC, that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. (RFC 2026) (Compare: RFC.) Tutorial: The "Internet Standards Process" is an activity of the ISOC and is organized and managed by the IAB and the IESG. The process is concerned with all protocols, procedures, and conventions used in or by the Internet, whether or not they are part of the IPS. The "Internet Standards Track" has three levels of increasing maturity: Proposed Standard, Draft Standard, and Standard. (Compare: ISO, W3C.)
$ INTERNT STANDARD（I）IESGによって承認され、安定的かつよく理解されているRFCとして公開されている仕様は、技術的に有能であり、実質的な運用経験を持つ複数の、独立した、および相互運用可能な実装を有し、かなりのパブリックサポートを享受しています。インターネットの一部またはすべての部分には認識できるように認識できます。（RFC 2026）チュートリアル：「インターネット規格プロセス」はISOCの活動であり、IABとIESGによって編成され管理されています。このプロセスは、IPSの一部であるかどうかにかかわらず、インターネット内またはインターネットによって使用されるすべてのプロトコル、手順、および規則に関係しています。「インターネット規格追跡」には、3つのレベルの成熟度が高い：提案された標準、ドラフト標準、および標準。（比較：ISO、W3C。）
$ internetwork (I) A system of interconnected networks; a network of networks. Usually shortened to "internet". (See: internet, Internet.)
$ インターネットワーク（i）相互接続されたネットワークのシステム。ネットワークのネットワーク通常「インターネット」に短縮されます。（：インターネット、インターネットを参照）
Tutorial: An internet can be built using OSIRM Layer 3 gateways to implement connections between a set of similar subnetworks. With dissimilar subnetworks, i.e., subnetworks that differ in the Layer 3 protocol service they offer, an internet can be built by implementing a uniform internetwork protocol (e.g., IP) that operates at the top of Layer 3 and hides the underlying subnetworks' heterogeneity from hosts that use communication services provided by the internet. (See: router.)
チュートリアル：インターネットは、OSIRMレイヤ3ゲートウェイを使用して、一連の類似サブネットワーク間の接続を実装することができます。異なるサブネットワーク、すなわち、それらが提供するレイヤ3プロトコルサービスが異なるサブネットワークを使用して、インターネットは、レイヤ3の上部に動作し、下にあるサブネットワークの異質性を隠して統一されたインターネットワークプロトコル（例えば、IP）を実装することによって構築することができる。インターネットによって提供される通信サービスを使用するホスト。（ルータを参照してください。）
$ intranet (I) A computer network, especially one based on Internet technology, that an organization uses for its own internal (and usually private) purposes and that is closed to outsiders. (See: extranet, VPN.)
$ イントラネット（i）コンピュータネットワーク、特にインターネット技術に基づくインターネット技術に基づくものであり、組織はそれ自身の内部（そして通常は民間）の目的で使い、そこから部外者に閉じられています。（参照：ExtraNet、VPN）
$ intruder (I) An entity that gains or attempts to gain access to a system or system resource without having authorization to do so. (See: intrusion. Compare: adversary, cracker, hacker.)
$ intruder（i）承認を行うことなく、システムまたはシステムリソースへのアクセスを得ようとするエンティティ。（侵入を参照してください。比較：敵対者、クラッカー、ハッカー。）
$ intrusion 1. (I) A security event, or a combination of multiple security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system or system resource without having authorization to do so. (See: IDS.)
$ 侵入1.（i）侵入者が利益を得るセキュリティ事件を構成するセキュリティイベント、または複数のセキュリティイベントの組み合わせは、許可を実行することなくシステムまたはシステムリソースにアクセスしようとしたセキュリティインシデントを構成する。（参照：IDSを参照）
2. (I) A type of threat action whereby an unauthorized entity gains access to sensitive data by circumventing a system's security protections. (See: unauthorized disclosure.)
2. （i）不正なエンティティがシステムのセキュリティ保護を回避することによって、不正なエンティティが機密データへのアクセスを取得する一種の脅威行動。（未承認の開示を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Trespass": Gaining physical access to sensitive data by circumventing a system's protections. - "Penetration": Gaining logical access to sensitive data by circumventing a system's protections.
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「TRESPASS」：システムの保護を回避することによって機密データへの物理的アクセスを取得します。 - 「侵入」：システムの保護を回避することで、機密データへの論理的なアクセスを取得します。
- "Reverse engineering": Acquiring sensitive data by disassembling and analyzing the design of a system component. - "Cryptanalysis": Transforming encrypted data into plain text without having prior knowledge of encryption parameters or processes. (See: main entry for "cryptanalysis".)
- 「リバースエンジニアリング」：システムコンポーネントの設計を分解して分析することで、機密データを取得します。 - "cryptanalysis"：暗号化パラメータやプロセスに関する事前の知識を持たずに、暗号化データをプレーンテキストに変換します。（「Cryptanalysis」のメインエントリを参照してください。）
$ intrusion detection (I) Sensing and analyzing system events for the purpose of noticing (i.e., becoming aware of) attempts to access system resources in an unauthorized manner. (See: anomaly detection, IDS, misuse detection. Compare: extrusion detection.) [IDSAN, IDSSC, IDSSE, IDSSY]
$ 侵入検知（i）気付きの目的のためのシステムイベントを検知し分析すること（すなわち、認識することになることになる）システムリソースに不正な方法でアクセスすることを試みる。（参照：異常な検出、ID、誤用検出。比較：押出検出）[IDSAN、IDSSC、IDSSE、IDSSY]
Usage: This includes the following subtypes: - "Active detection": Real-time or near-real-time analysis of system event data to detect current intrusions, which result in an immediate protective response. - "Passive detection": Off-line analysis of audit data to detect past intrusions, which are reported to the system security officer for corrective action. (Compare: security audit.)
使用法：これには、次のサブタイプが含まれます。 - 「アクティブ検出」：現在の侵入を検出するためのシステムイベントデータのリアルタイムまたはリアルタイム分析。これにより、即時保護応答が発生します。 - 「パッシブ検出」：監査データのオフライン分析過去の侵入を検出するための監査データの分析。（比較：セキュリティ監査。）
$ intrusion detection system (IDS) 1. (N) A process or subsystem, implemented in software or hardware, that automates the tasks of (a) monitoring events that occur in a computer network and (b) analyzing them for signs of security problems. [SP31] (See: intrusion detection.)
$ 侵入検知システム（IDS）1.（n）コンピュータネットワークで発生する（a）監視イベントのタスクを自動化し、セキュリティ上の問題の兆候を分析する（B）を分析する、ソフトウェアまたはハードウェアで実装されたプロセスまたはサブシステム。[SP31]（侵入検知を参照）
2. (N) A security alarm system to detect unauthorized entry. [DC6/9].
2. （n）不正なエントリを検出するためのセキュリティアラームシステム。[DC6 / 9]。
Tutorial: Active intrusion detection processes can be either host-based or network-based: - "Host-based": Intrusion detection components -- traffic sensors and analyzers -- run directly on the hosts that they are intended to protect. - "Network-based": Sensors are placed on subnetwork components, and analysis components run either on subnetwork components or hosts.
チュートリアル：アクティブな侵入検知プロセスは、ホストベースまたはネットワークベースのいずれかです。 - "Host-Based"：侵入検知コンポーネント - トラフィックセンサーとアナライザ - 保護することを意図しているホスト上で直接実行します。 - 「ネットワークベース」：センサーはサブネットワークコンポーネントに配置され、分析コンポーネントはサブネットワークコンポーネントまたはホストで実行されます。
$ invalidity date (N) An X.509 CRL entry extension that "indicates the date at which it is known or suspected that the [revoked certificate's private key] was compromised or that the certificate should otherwise be considered invalid." [X509].
$ 無効日（N）X.509 CRLエントリ拡張機能は、「無効な証明書の秘密鍵」が危険にさらされているか、証明書が無効と見なされるべきであると証明書が知られている日付を示すCRLエントリ拡張機能。[X509]。
Tutorial: This date may be earlier than the revocation date in the CRL entry, and may even be earlier than the date of issue of earlier CRLs. However, the invalidity date is not, by itself, sufficient for purposes of non-repudiation service. For example, to fraudulently repudiate a validly generated signature, a private key holder may falsely claim that the key was compromised at some time in the past.
チュートリアル：この日付は、CRLエントリの失効日より早く、以前のCRLの発行日よりも早くなる可能性があります。ただし、無効な日付は、否認防止サービスの目的で十分ではありません。例えば、有効に生成された署名を不正に否認するために、秘密鍵ホルダーは、そのキーが過去にしばらく妥協したと誤って主張することができる。
$ IOTP (I) See: Internet Open Trading Protocol.
$ IOTP（i）インターネットオープントレーディングプロトコルを参照してください。
$ IP (I) See: Internet Protocol.
$ IP（i）インターネットプロトコルを参照してください。
$ IP address (I) A computer's internetwork address that is assigned for use by IP and other protocols.
$ IPアドレス（i）IPおよび他のプロトコルで使用するために割り当てられているコンピュータのインターネットワークアドレス。
Tutorial: An IP version 4 address (RFC 791) has four 8-bit parts and is written as a series of four decimal numbers separated by periods. Example: The address of the host named "rosslyn.bbn.com" is 192.1.7.10.
チュートリアル：IPバージョン4アドレス（RFC 791）には4つの8ビットの部分があり、ピリオドで区切られた4つの10進数の4つの10進数として書かれています。例： "rosslyn.bbn.com"という名前のホストのアドレスは192.1.7.10です。
An IP version 6 address (RFC 2373) has eight 16-bit parts and is written as eight hexadecimal numbers separated by colons. Examples: 1080:0:0:0:8:800:200C:417A and FEDC:BA98:7654:3210:FEDC:BA98:7654:3210.
IPバージョン6アドレス（RFC 2373）は8つの16ビットの部分を持ち、コロンで区切られた8つの16進数として書き込まれます。例：1080：0：0：0：8：800：200C：417AおよびFREDC：BA98：7654：3210：Fedc：BA98：7654：3210。
$ IP Security Option (I) See: Internet Protocol Security Option.
$ IPセキュリティオプション（i）インターネットプロトコルセキュリティオプションを参照してください。
$ IP Security Protocol (IPsec) 1a. (I) The name of the IETF working group that is specifying an architecture [R2401, R4301] and set of protocols to provide security services for IP traffic. (See: AH, ESP, IKE, SAD, SPD. Compare: IPSO.)
$ IPセキュリティプロトコル（IPsec）1A。（i）Architecture [R2401、R4301]を指定しているIETFワーキング・グループの名前、およびIPトラフィック用のセキュリティー・サービスを提供するためのプロトコルのセット。（AH、ESP、IKE、SAD、SPD。比較：IPSO。）
1b. (I) A collective name for the IP security architecture [R4301] and associated set of protocols (primarily AH, ESP, and IKE).
1b。（i）IPセキュリティアーキテクチャの集合名[R4301]および関連するプロトコルのセット（主にAH、ESP、およびIKE）。
Usage: In IDOCs that use the abbreviation "IPsec", the letters "IP" SHOULD be in uppercase, and the letters "sec" SHOULD NOT.
使用法：略語「IPsec」を使用するIDocでは、文字「IP」を大文字にしておく必要があり、「sec」の文字はしてはいけません。
Tutorial: The security services provided by IPsec include access control service, connectionless data integrity service, data origin authentication service, protection against replays (detection of the arrival of duplicate datagrams, within a constrained window), data confidentiality service, and limited traffic-flow confidentiality. IPsec specifies (a) security protocols (AH and ESP), (b) security associations (what they are, how they work, how they are managed, and associated processing), (c) key management (IKE), and (d) algorithms for authentication and encryption. Implementation of IPsec is optional for IP version 4, but mandatory for IP version 6. (See: transport mode, tunnel mode.)
チュートリアル：IPsecによって提供されるセキュリティサービスには、アクセス制御サービス、コネクションレスデータ整合性サービス、データ原点認証サービス、再生に対する保護（重複データグラムの到着の検出）、データ機密保持サービス、および限られたトラフィックフロー機密性IPsecは、（a）セキュリティプロトコル（AHとESP）、（B）セキュリティアソシエーション（それらがどのようなもの、それらがどのように機能し、それらがどのように管理し、関連処理、および関連処理）、（C）キー管理（IKE）、および（D）を指定します。認証と暗号化のためのアルゴリズムIPSecの実装はIPバージョン4の場合はオプションですが、IPバージョン6に必須です。（転送モード、トンネルモードを参照）。
$ IPLI (I) See: Internet Private Line Interface.
$ IPLI（I）インターネットプライベートラインインターフェースを参照してください。
$ IPRA (I) See: Internet Policy Registration Authority.
$ IPRA（I）：インターネットポリシー登録局。
$ IPS (I) See: Internet Protocol Suite.
$ IPS（i）インターネットプロトコルスイートを参照してください。
$ IPsec (I) See: IP Security Protocol.
$ IPsec（i）IPセキュリティプロトコルを参照してください。
$ IPSO (I) See: Internet Protocol Security Option.
$ IPSO（i）インターネットプロトコルセキュリティオプションを参照してください。
$ ISAKMP (I) See: Internet Security Association and Key Management Protocol.
$ ISAKMP（i）インターネットセキュリティ協会と鍵管理プロトコルを参照してください。
$ ISO (I) International Organization for Standardization, a voluntary, non-treaty, non-governmental organization, established in 1947, with voting members that are designated standards bodies of participating nations and non-voting observer organizations. (Compare: ANSI, IETF, ITU-T, W3C.)
$ ISO（i）1947年に設立された標準化、非政府機関、標準化されていない非政府機関、参加していない諸国会議員と非投票されていないオブザーバー組織である投票会員を備えた国際機関。（比較：ANSI、IETF、ITU-T、W3C。）
Tutorial: Legally, ISO is a Swiss, non-profit, private organization. ISO and the IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in developing international standards through ISO and IEC technical committees that deal with particular fields of activity. Other international governmental and non-governmental organizations, in liaison with ISO and IEC, also take part. (ANSI is the U.S. voting member of ISO. ISO is a class D member of ITU-T.)
チュートリアル：合法的に、ISOはスイス、非営利の民間機関です。ISOとIEC（国際電気技術委員会）は、世界規模の標準化のための専門システムを形成します。ISOまたはIECのメンバーである国民団体は、特定の活動分野を扱うISOおよびIEC技術委員会を通じて国際基準の開発に参加しています。ISOとIECとの連絡先の他の国際政府および非政府機関もまた参加しています。（ANSIはISOの米国投票メンバーです。ISOはITU-TのクラスDメンバーです。）
The ISO standards development process has four levels of increasing maturity: Working Draft (WD), Committee Draft (CD), Draft International Standard (DIS), and International Standard (IS). (Compare: "Internet Standards Track" under "Internet Standard".) In information technology, ISO and IEC have a joint technical committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are circulated to national bodies for voting, and publication as an IS requires approval by at least 75% of the national bodies casting a vote.
ISO規格開発プロセスには、成熟度の4つのレベルが増加しています。（比較：「インターネット規格」の下の「インターネット標準トラック」。ANは、投票をキャストする国立体の少なくとも75％の承認が必要です。
$ ISO 17799 (N) An International Standard that is a code of practice, derived from Part 1 of British Standard 7799, for managing the security of information systems in an organization. This standard does not provide definitive or specific material on any security topic. It provides general guidance on a wide variety of topics, but typically does not go into depth. (See: IATF, [SP14].)
$ ISO 17799（N）組織内の情報システムのセキュリティを管理するための、イギリス標準7799のパート1から導出された実践規範である国際規格。この規格は、あらゆるセキュリティトピックに決定的な資料または特定の資料を提供しません。それは多種多様なトピックに関する一般的なガイダンスを提供しますが、通常は深さにはなりません。（：IATF、[SP14]参照）
$ ISOC (I) See: Internet Society.
$ ISOC（I）インターネット社会。
$ issue (I) /PKI/ Generate and sign a digital certificate (or a CRL) and, usually, distribute it and make it available to potential certificate users (or CRL users). (See: certificate creation.)
$ デジタル証明書（またはCRL）/ PKI /生成と署名し、通常、それを分散させ、それを潜在的な証明書ユーザー（またはCRLユーザー）に利用できるようにします。（証明書の作成を参照してください。）
Usage: The term "issuing" is usually understood to refer not only to creating a digital certificate (or a CRL) but also to making it available to potential users, such as by storing it in a repository or other directory or otherwise publishing it. However, the ABA [DSG] explicitly limits this term to the creation process and excludes any related publishing or distribution process.
使用法：「発行」という用語は、通常、デジタル証明書（またはCRL）を作成するだけでなく、それをリポジトリまたは他のディレクトリに格納すること、またはそれを公開するなど、潜在的なユーザーが利用できるようにすることも一般的に理解されています。ただし、ABA [DSG]はこの用語を作成プロセスに明示的に制限し、関連する公開または配布プロセスを除外します。
$ issuer 1. (I) /certificate, CRL/ The CA that signs a digital certificate or CRL.
$ 発行者1.（i）/証明書、CRL /デジタル証明書またはCRLに署名するCA。
Tutorial: An X.509 certificate always includes the issuer's name. The name may include a common name value.
チュートリアル：X.509証明書には常に発行者の名前が含まれています。名前は共通の名前値を含み得る。
2. (O) /payment card, SET/ "The financial institution or its agent that issues the unique primary account number to the cardholder for the payment card brand." [SET2]
2. （O）/支払いカード、設定/「決算カードブランドのカード保有者に固有の一次口座番号を発行する金融機関またはその代理人」。[SET2]
Tutorial: The institution that establishes the account for a cardholder and issues the payment card also guarantees payment for authorized transactions that use the card in accordance with card brand regulations and local legislation. [SET1]
チュートリアル：カード保有者のアカウントを確立し、支払いカードを発行する機関は、カードブランドの規制や地域の法律に従ってカードを使用する認定取引の支払いも保証します。[SET1]
$ ITAR (O) See: International Traffic in Arms Regulations.
$ ITAR（O）武器規制の国際交通。
$ ITSEC (N) See: Information Technology System Evaluation Criteria.
$ ITSEC（N）：情報技術システム評価基準を参照してください。
$ ITU-T (N) International Telecommunications Union, Telecommunication Standardization Sector (formerly "CCITT"), a United Nations treaty organization that is composed mainly of postal, telephone, and telegraph authorities of the member countries and that publishes standards called "Recommendations". (See: X.400, X.500.)
$ ITU-T（N）国際電気通信連合、電気通信標準化セクター（以前は「CCITT」）、加盟国の郵便番号、電話、電信当局から構成され、「勧告」と呼ばれる標準を発行する組織。（X.400、X.500を参照）
Tutorial: The Department of State represents the United States. ITU-T works on many kinds of communication systems. ITU-T cooperates with ISO on communication protocol standards, and many Recommendations in that area are also published as an ISO standard with an ISO name and number.
チュートリアル：州部はアメリカ合衆国を代表しています。ITU-Tは多くの種類の通信システムで動作します。ITU-Tは、通信プロトコル標準のISOと協力し、その地域の多くの推奨事項もISOの名前と番号を持つISO規格として公開されています。
$ IV (I) See: initialization value.
$ iv（i）初期化値を参照してください。
$ jamming (N) An attack that attempts to interfere with the reception of broadcast communications. (See: anti-jam, denial of service. Compare: flooding.)
$ Jamming（n）ブロードキャスト通信の受信を妨害しようとする攻撃。（検索：アンチジャム、サービス拒否。比較：フラッディング。）
Tutorial: Jamming uses "interference" as a type of "obstruction" intended to cause "disruption". Jamming a broadcast signal is typically done by broadcasting a second signal that receivers cannot separate from the first one. Jamming is mainly thought of in the context of wireless communication, but also can be done in some wired technologies, such as LANs that use contention techniques to share a broadcast medium.
チュートリアル：Jammingは、「中断」を引き起こすことを意図した「障害物」の種類として「干渉」を使用しています。ブロードキャスト信号をジャミングすることは、通常、受信機が最初のものとは分離できない第2の信号をブロードキャストすることによって行われる。ジャミングは主に無線通信の文脈で考えられるが、放送媒体を共有するために競合技術を使用するLANのようないくつかの有線技術でも行うことができる。
$ KAK (D) See: key-auto-key. (Compare: KEK.)
$ KAK（D）キーオートキーを参照してください。（Compare：KEK。）
$ KDC (I) See: Key Distribution Center.
$ KDC（i）キー配布センターを参照してください。
$ KEA (N) See: Key Exchange Algorithm.
$ KEA（N）参照：鍵交換アルゴリズム。
$ KEK (I) See: key-encrypting key. (Compare: KAK.)
$ KEK（i）キー暗号化キーを参照してください。（Compare：Kak。）
$ Kerberos (I) A system developed at the Massachusetts Institute of Technology that depends on passwords and symmetric cryptography (DES) to implement ticket-based, peer entity authentication service and access control service distributed in a client-server network environment. [R4120, Stei] (See: realm.)
$ Kerberos（i）マサチューセッツ州テクノロジーで開発されたシステムは、パスワードと対称暗号化（DES）に依存し、クライアントサーバーネットワーク環境で配布されたチケットベースのピアエンティティ認証サービスとアクセス制御サービスを実装するためのシステムです。[R4120、STEI]（レルム参照）
Tutorial: Kerberos was originally developed by Project Athena and is named for the mythical three-headed dog that guards Hades. The system architecture includes authentication servers and ticket-granting servers that function as an ACC and a KDC.
チュートリアル：KerberosはもともとProject Athenaによって開発され、ハデスを守る神話の3頭の犬の名称です。システムアーキテクチャには、ACCとKDCとして機能する認証サーバーとチケット付与サーバーが含まれています。
RFC 4556 describes extensions to the Kerberos specification that modify the initial authentication exchange between a client and the KDC. The extensions employ public-key cryptography to enable the client and KDC to mutually authenticate and establish shared, symmetric keys that are used to complete the exchange. (See: PKINIT.)
RFC 4556は、クライアントとKDC間の初期認証交換を変更するKerberos仕様への拡張機能を説明しています。拡張機能は、クライアントとKDCが相互に認証され、交換を完了するために使用されている共有対称キーを相互に認証し確立できるようにするために公開鍵暗号化を使用します。（Pkinitを参照してください。）
$ kernel (I) A small, trusted part of a system that provides services on which the other parts of the system depend. (See: security kernel.)
$ カーネル（i）システムの他の部分が依存するサービスを提供するシステムの小さく信頼できる部分。（セキュリティカーネルを参照してください。）
$ Kernelized Secure Operating System (KSOS) (O) An MLS computer operating system, designed to be a provably secure replacement for UNIX Version 6, and consisting of a security kernel, non-kernel security-related utility programs, and optional UNIX application development and support environments. [Perr]
$ カーネル化セキュアオペレーティングシステム（KSO）（o）UNIXバージョン6のための証明された安全な置き換え、セキュリティカーネル、非カーネルセキュリティ関連ユーティリティプログラム、およびオプションのUNIXアプリケーション開発からなるように設計されたMLSコンピュータオペレーティングシステム。サポート環境[Perr]
Tutorial: KSOS-6 was the implementation on a SCOMP. KSOS-11 was the implementation by Ford Aerospace and Communications Corporation on the DEC PDP-11/45 and PDP-11/70 computers.
チュートリアル：KSOS-6はSCOMPの実装でした。KSOS-11は、DEC PDP-11/45およびPDP-11/70コンピュータ上のFord AerospaceおよびCommunications Corporationによる実装でした。
$ key 1a. (I) /cryptography/ An input parameter used to vary a transformation function performed by a cryptographic algorithm. (See: private key, public key, storage key, symmetric key, traffic key. Compare: initialization value.)
$ キー1A。（i）/暗号化/暗号化アルゴリズムによって実行される変換関数を変えるために使用される入力パラメータ。（秘密鍵、公開鍵、記憶鍵、対称鍵、交通キー。比較：初期化値）
1b. (O) /cryptography/ Used in singular form as a collective noun referring to keys or keying material. Example: A fill device can be used transfer key between two cryptographic devices.
1b。（O）/暗号化/キーワードまたはキーイング材料を参照する集合名詞として、単数形で使用されています。例：塗りつぶし装置は、2つの暗号化装置間で転送キーを使用することができます。
2. (I) /anti-jam/ An input parameter used to vary a process that determines patterns for an anti-jam measure. (See: frequency hopping, spread spectrum.)
2. （i）/アンチジャム/アンチジャムメジャーのパターンを決定するプロセスを変更するために使用される入力パラメータ。（周波数ホッピング、スペクトルスペクトルを参照）
Tutorial: A key is usually specified as a sequence of bits or other symbols. If a key value needs to be kept secret, the sequence of symbols that comprise it should be random, or at least pseudorandom, because that makes the key harder for an adversary to guess. (See: brute-force attack, cryptanalysis, strength.)
チュートリアル：通常、ビットまたは他のシンボルのシーケンスとして指定されます。キー値を秘密にする必要がある場合、それを構成するシンボルのシンボルはランダムであるべきであるか、少なくとも疑似ランダムであるべきです。（ブルートフォース攻撃、クリプターシス、強度を参照してください。）
$ key agreement (algorithm or protocol) 1. (I) A key establishment method (especially one involving asymmetric cryptography) by which two or more entities, without prior arrangement except a public exchange of data (such as public keys), each can generate the same key value. That is, the method does not send a secret from one entity to the other; instead, both entities, without prior arrangement except a public exchange of data, can compute the same secret value, but that value cannot be computed by other, unauthorized entities. (See: Diffie-Hellman-Merkle, key establishment, KEA, MQV. Compare: key transport.)
$ 主な合意（アルゴリズムまたはプロトコル）1.（i）公衆のデータ（公開鍵など）を除く、2つ以上のエンティティが2つ以上のエンティティを除いて、それぞれが生成することができる重要な確立方法（特に非対称暗号化）。同じキー値です。つまり、このメソッドは1つのエンティティから秘密を他のエンティティに送信しません。代わりに、公衆のデータ交換以外の事前の配置なしに、同じ秘密の値を計算することはできますが、その値は他の不正なエンティティによって計算することはできません。（参照：Diffie-Hellman-Merkle、Kea、Kea、MQV。比較：キートランスポート。）
2. (O) "A method for negotiating a key value on line without transferring the key, even in an encrypted form, e.g., the Diffie-Hellman technique." [X509] (See: Diffie-Hellman-Merkle.)
2. （O）「暗号化された形でも、キーを転送せずに線上のキー値を交渉する方法、例えばDiffie-Hellman技術。[X509]（参照：Diffie-Hellman-Merkle。）
3. (O) "The procedure whereby two different parties generate shared symmetric keys such that any of the shared symmetric keys is a function of the information contributed by all legitimate participants, so that no party [alone] can predetermine the value of the key." [A9042]
3. （O） "2つの異なる当事者が共有対称キーを生成する手順は、共有対称キーのいずれかがすべての正規参加者から寄与された情報の関数であるため、パーティーはキーの値を事前に決定できない。[A9042]
Example: A message originator and the intended recipient can each use their own private key and the other's public key with the Diffie-Hellman-Merkle algorithm to first compute a shared secret value and, from that value, derive a session key to encrypt the message.
例：メッセージ発信者と意図された受信者は、最初に共有秘密値を計算し、その値からメッセージを暗号化するためにセッションキーを導出するために、Diffie-Hellman-Merkleアルゴリズムを使用してそれぞれ独自の秘密鍵とその他の公開鍵を使用することができます。。
$ key authentication (N) "The assurance of the legitimate participants in a key agreement [i.e., in a key-agreement protocol] that no non-legitimate party possesses the shared symmetric key." [A9042]
$ 鍵認証（N）「正当な契約での正当な参加者の保証[すなわち契約契約プロトコル]では、非正規党が共有対称鍵を所有していない。」[A9042]
$ key-auto-key (KAK) (D) "Cryptographic logic [i.e., a mode of operation] using previous key to produce key." [C4009, A1523] (See: CTAK, /cryptographic operation/ under "mode".)
$ キーオートキー（KAK）（D） "暗号ロジック[すなわち操作モード]キーを作成するための前キーを使用する。」[C4009、A1523]（CTAK、/暗号操作/「モード」の下）
Deprecated Term: IDOCs SHOULD NOT use this term; it is neither well-known nor precisely defined. Instead, use terms associated with modes that are defined in standards, such as CBC, CFB, and OFB.
廃止予定語：IDocsはこの用語を使用しないでください。それはよく知られていないことも正確に定義されていません。代わりに、CBC、CFB、OFBなどの標準で定義されているモードに関連付けられています。
$ key center (I) A centralized, key-distribution process (used in symmetric cryptography), usually a separate computer system, that uses master keys (i.e., KEKs) to encrypt and distribute session keys needed by a community of users.
$ Key Center（i）集中型の鍵配布プロセス（対称暗号で使用されている）、通常は別々のコンピュータシステム（すなわち、keks）を使用して、ユーザのコミュニティによって必要とされるセッションキーを暗号化および配布する。
Tutorial: An ANSI standard [A9017] defines two types of key center: "key distribution center" and "key translation center".
チュートリアル：ANSI標準[A9017]は、「キー配布センター」と「キー変換センター」の2種類のキーセンターを定義しています。
$ key confirmation (N) "The assurance [provided to] the legitimate participants in a key establishment protocol that the [parties that are intended to share] the symmetric key actually possess the shared symmetric key." [A9042]
$ 鍵確認（N）「対称鍵を実際に共有対称鍵を持っている締約国」が主要な鍵を持つ重要な設立プロトコルの正当な参加者の保証。」[A9042]
$ key distribution (I) A process that delivers a cryptographic key from the location where it is generated to the locations where it is used in a cryptographic algorithm. (See: key establishment, key management.)
$ 鍵配布（i）暗号化アルゴリズムで使用されている場所に生成された場所から暗号鍵を配信するプロセス。（参照：主要設立、鍵管理。）
$ key distribution center (KDC) 1. (I) A type of key center (used in symmetric cryptography) that implements a key-distribution protocol to provide keys (usually, session keys) to two (or more) entities that wish to communicate securely. (Compare: key translation center.)
$ キー配布センター（KDC）1.（i）キーサイズ（通常はセッションキー）を確実に通信したい2つの（または複数の）エンティティに提供するためのキー配信プロトコルを実装するキーセンター（対称暗号で使用されています）。（Compare：鍵換算センター）
2. (N) "COMSEC facility generating and distributing key in electrical form." [C4009]
2. （n） "COMSEC施設電気的形式のキーを生成し配布する。[C4009]
Tutorial: A KDC distributes keys to Alice and Bob, who (a) wish to communicate with each other but do not currently share keys, (b) each share a KEK with the KDC, and (c) may not be able to generate or acquire keys by themselves. Alice requests the keys from the KDC. The KDC generates or acquires the keys and makes two identical sets. The KDC encrypts one set in the KEK it shares with Alice, and sends that encrypted set to Alice. The KDC encrypts the second set in the KEK it shares with Bob, and either (a) sends that encrypted set to Alice for her to forward to Bob or (b) sends it directly to Bob (although the latter option is not supported in the ANSI standard [A9017]).
チュートリアル：KDCはAliceとBobにキーを配布します。（a）は互いに通信したいが現在キーを共有していないが（b）KDCでKDCを共有し、（c）を生成できない場合があります。自分で鍵を獲得してください。Alice KDCからキーを要求します。KDCはキーを生成または取得し、2つの同一のセットを作成します。KDCは、Aliceで共有するKEKに1セットを暗号化し、その暗号化セットをAliceに送信します。KDCはBOBと共有しているKEKのセットを暗号化し、（a）がBOBに転送するために暗号化されたセットをAliceに送信するか（b）を直接BOBに送信する（後者のオプションはサポートされていませんが）。ANSI規格[A9017]）。
$ key encapsulation (N) A key recovery technique for storing knowledge of a cryptographic key by encrypting it with another key and ensuring that only certain third parties called "recovery agents" can perform the decryption operation to retrieve the stored key. Key encapsulation typically permits direct retrieval of a secret key used to provide data confidentiality. (Compare: key escrow.)
$ キーカプセル化（n）暗号鍵の知識を別の鍵で暗号化し、「回復エージェント」と呼ばれる特定の第三者のみが復号化操作を実行して格納キーを取得できるようにすることができるようにするための重要な回復技術。主なカプセル化は通常、データ機密性を提供するために使用される秘密鍵の直接検索を可能にします。（Compare：Key Escrow。）
$ key-encrypting key (KEK) (I) A cryptographic key that (a) is used to encrypt other keys (either DEKs or other TEKs) for transmission or storage but (b) (usually) is not used to encrypt application data. Usage: Sometimes called "key-encryption key".
$ キー暗号化キー（kek）（i）（a）を使用して、伝送または記憶用の他のキー（DEKSまたは他のTEKS）を暗号化するために使用される、（通常）アプリケーションデータの暗号化には使用されません。使用法：「キー暗号化キー」と呼ばれることもあります。
$ key escrow (N) A key recovery technique for storing knowledge of a cryptographic key or parts thereof in the custody of one or more third parties called "escrow agents", so that the key can be recovered and used in specified circumstances. (Compare: key encapsulation.)
$ キーエスクロー（N）「エスクローエージェント」と呼ばれる1つ以上の第三者の親権における暗号鍵またはその一部の知識を記憶するための重要な回復技術が、鍵を回収して特定の状況で使用することができる。（Compare：キーカプセル化。）
Tutorial: Key escrow is typically implemented with split knowledge techniques. For example, the Escrowed Encryption Standard [FP185] entrusts two components of a device-unique split key to separate escrow agents. The agents provide the components only to someone legally authorized to conduct electronic surveillance of telecommunications encrypted by that specific device. The components are used to reconstruct the device-unique key, and it is used to obtain the session key needed to decrypt communications.
チュートリアル：主なエスクローは通常、分割知識技術で実装されています。たとえば、ESCLOWED暗号化標準[FP185]は、デバイス固有の分割キーの2つのコンポーネントを区別して、ESCLOWエージェントを委任します。エージェントは、その特定の装置によって暗号化された電気通信の電子監視を行うことを合法的に承認された誰かにのみコンポーネントを提供します。コンポーネントはデバイス固有キーを再構築するために使用され、通信を復号化するのに必要なセッションキーを取得するために使用されます。
$ key establishment (algorithm or protocol) 1. (I) A procedure that combines the key-generation and key-distribution steps needed to set up or install a secure communication association.
$ 主要確立（アルゴリズムまたはプロトコル）1。（i）安全な通信アソシエーションの設定またはインストールに必要なキー生成手順と鍵配布手順を組み合わせた手順。
2. (I) A procedure that results in keying material being shared among two or more system entities. [A9042, SP56]
2. （i）キー化材料が2つ以上のシステムエンティティ間で共有されている手順。[A9042、SP56]
Tutorial: The two basic techniques for key establishment are "key agreement" and "key transport".
チュートリアル：主要設立のための2つの基本的な技術は「鍵合意」と「鍵輸送」です。
$ Key Exchange Algorithm (KEA) (N) A key-agreement method [SKIP, R2773] that is based on the Diffie-Hellman-Merkle algorithm and uses 1024-bit asymmetric keys. (See: CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.)
$ 鍵交換アルゴリズム（KEA）（n）Diffie-Hellman-Merkleアルゴリズムに基づいて、1024ビットの非対称キーを使用するキー契約方法[Skip、R2773]。（Capstone、Clipper、Fortezza、Skipjack。）
Tutorial: KEA was developed by NSA and formerly classified at the U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that KEA had been declassified.
チュートリアル：KEAはNSAによって開発され、以前は米国のDOD「秘密」レベルで分類されていました。1998年6月23日、NSAはKEAが分解されたことを発表しました。
$ key generation (I) A process that creates the sequence of symbols that comprise a cryptographic key. (See: key management.)
$ 鍵生成（i）暗号鍵を構成するシンボルのシンボルを作成するプロセス。（：鍵管理を参照してください。）
$ key generator 1. (I) An algorithm that uses mathematical rules to deterministically produce a pseudorandom sequence of cryptographic key values.
$ キージェネレータ1.（i）数学的規則を使用して、暗号鍵値の擬似乱数シーケンスを決定するためのアルゴリズム。
2. (I) An encryption device that incorporates a key-generation mechanism and applies the key to plain text to produce cipher text (e.g., by exclusive OR-ing (a) a bit-string representation of the key with (b) a bit-string representation of the plaintext).
（i）キー生成メカニズムを組み込んで暗号化された暗号化装置をプレーンテキストに適用して暗号テキストを作成する（例えば、（B）aを用いて鍵のビット文字列表現（例えば、）。平文のビット文字列表現）
$ key length (I) The number of symbols (usually stated as a number of bits) needed to be able to represent any of the possible values of a cryptographic key. (See: key space.)
$ キー長さ（i）暗号鍵の可能な値を表すことができるのに必要なシンボル数（通常はビット数として述べた）。（参照：キースペース。）
$ key lifetime 1. (D) Synonym for "cryptoperiod".
$ 主な有効期間1.（d）「暗号化合権」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 1 because a key's cryptoperiod may be only a part of the key's lifetime. A key could be generated at some time prior to when its cryptoperiod begins and might not be destroyed (i.e., zeroized) until some time after its cryptoperiod ends.
廃止予定の定義：鍵の暗号化合備が鍵の一部の一部にすぎない可能性があるため、IDocは定義1でこの用語を使用しないでください。その暗号化が開始されたときの鍵は、その暗号化が開始されてから破壊されない（すなわち、ゼロ化された）、その暗号化が終了するまでには破壊されない可能性がある（すなわち、ゼロ化された）。
2. (O) /MISSI/ An attribute of a MISSI key pair that specifies a time span that bounds the validity period of any MISSI X.509 public-key certificate that contains the public component of the pair. (See: cryptoperiod.)
2. （O）/ MISSI / PAINのパブリックコンポーネントを含むMissi X.509公開鍵証明書の有効期間を制限する期間を指定するMissi Keyペアの属性。（以下を参照してください。暗号化。）
$ key loader (N) Synonym for "fill device".
$ キーローダー（N）「デバイスを入力する」の同義語。
$ key loading and initialization facility (KLIF) (N) A place where ECU hardware is activated after being fabricated. (Compare: CLEF.)
$ キーロードと初期化ファシリティ（KLIF）（n）製造後にECUハードウェアが起動される場所。（比較：音部記号）
Tutorial: Before going to its KLIF, an ECU is not ready to be fielded, usually because it is not yet able to receive DEKs. The KLIF employs trusted processes to complete the ECU by installing needed data such as KEKs, seed values, and, in some cases, cryptographic software. After KLIF processing, the ECU is ready for deployment.
チュートリアル：KLIFに進む前に、ECUはフィールド化する準備ができていません。通常はDeksをまだ受け取ることができないためです。KLIFは、KEKS、シード値、および場合によっては暗号化ソフトウェアなどの必要なデータをインストールすることで、信頼されたプロセスを採用してECUを完成させます。KLIF処理の後、ECUは展開の準備ができています。
$ key management 1a. (I) The process of handling keying material during its life cycle in a cryptographic system; and the supervision and control of that process. (See: key distribution, key escrow, keying material, public-key infrastructure.)
$ 鍵管理1A。（i）暗号システムにおけるライフサイクル中のキー化材料を処理するプロセス。そしてその過程の監督と管理。（参照：鍵配布、鍵エスクロー、キーイング品目、公開鍵インフラストラクチャー。）
Usage: Usually understood to include ordering, generating, storing, archiving, escrowing, distributing, loading, destroying, auditing, and accounting for the material.
使用法：通常、注文、生成、保管、アーカイブ、急成長、分配、積載、破壊、監査、および材料の会計を含むと理解されています。
1b. (O) /NIST/ "The activities involving the handling of cryptographic keys and other related security parameters (e.g., IVs, counters) during the entire life cycle of the keys, including their generation, storage, distribution, entry and use, deletion or destruction, and archiving." [FP140, SP57]
1b。（O）/ NIST /「鍵の生涯サイクル全体の暗号鍵やその他の関連セキュリティパラメータ（例えば、IVS、カウンター）の取り扱いを含む活動。破壊、そしてアーカイブ。」[FP140、SP57]
2. (O) /OSIRM/ "The generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy." [I7498-2]
2. （O）/ OSIRR /「セキュリティポリシーに従ってキーの世代、ストレージ、配布、削除、アーカイブ、およびアプリケーションのアプリケーション。」[I7498-2]
$ Key Management Protocol (KMP) (N) A protocol to establish a shared symmetric key between a pair (or a group) of users. (One version of KMP was developed by SDNS, and another by SILS.) Superseded by ISAKMP and IKE.
$ 鍵管理プロトコル（KMP）（n）ペア（またはグループ）の間に共有対称鍵を確立するためのプロトコル。（KMPの1つのバージョンはSDNSによって開発されました。これはSILSによって開発されました。）ISAKMPとIKEに置き換えられました。
$ key material (D) Synonym for "keying material".
$ キーマテリアル（D）「キーイングマテリアル」の同義語。
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for "keying material".
廃止予定の使用法：IDOCは、この用語を「キーイング品目」の同義語として使用しないでください。
$ key pair (I) A set of mathematically related keys -- a public key and a private key -- that are used for asymmetric cryptography and are generated in a way that makes it computationally infeasible to derive the private key from knowledge of the public key. (See: Diffie-Hellman-Merkle, RSA.)
$ キーペア（i）数学的に関連するキー - 公開鍵と秘密鍵のセット - 非対称暗号化に使用され、公開鍵の知識から秘密鍵を導出することができないようにする方法で生成されます。。（参照：Diffie-Hellman-Merkle、RSA。）
Tutorial: A key pair's owner discloses the public key to other system entities so they can use the key to (a) encrypt data, (b) verify a digital signature, or (c) generate a key with a key-agreement algorithm. The matching private key is kept secret by the owner, who uses it to (a') decrypt data, (b') generate a digital signature, or (c') generate a key with a key-agreement algorithm.
チュートリアル：主なペアの所有者は、（a）暗号化データにキーを使用できるように、（b）デジタル署名を検証すること、または（c）キー契約アルゴリズムを使用してキーを生成するように、他のシステムエンティティに公開鍵を開示しています。一致する秘密鍵は、それを（A '）復号化データに使用する所有者によって秘密にされ、（B'）デジタル署名を生成する、または（C '）キー合意アルゴリズムを持つキーを生成します。
$ key recovery 1. (I) /cryptanalysis/ A process for learning the value of a cryptographic key that was previously used to perform some cryptographic operation. (See: cryptanalysis, recovery.)
$ キー回復1.（i）/暗号解読/以前に暗号化操作を実行するために以前に使用された暗号鍵の値を学習するためのプロセス。（参照：暗号解析、回復。）
2. (I) /backup/ Techniques that provide an intentional, alternate means to access the key used for data confidentiality service in an encrypted association. [DoD4] (Compare: recovery.)
2. （i）/バックアップ/テクニック、暗号化された関連付けでデータ機密保持サービスに使用される鍵にアクセスするための意図的な代替手段を提供する。[DOD4]（比較：回復）
Tutorial: It is assumed that the cryptographic system includes a primary means of obtaining the key through a key-establishment algorithm or protocol. For the secondary means, there are two classes of key recovery techniques: key encapsulation and key escrow.
チュートリアル：暗号化システムは、鍵確立アルゴリズムまたはプロトコルを介して鍵を取得する主な手段を含むと仮定されています。二次的な手段では、キーカプセル化とキーescrowの2つのクラスのキー回復手法があります。
$ key space (I) The range of possible values of a cryptographic key; or the number of distinct transformations supported by a particular cryptographic algorithm. (See: key length.)
$ キースペース（i）暗号鍵の可能な値の範囲。または特定の暗号化アルゴリズムによってサポートされている別個の変換の数。（参照の長さを参照してください。）
$ key translation center (I) A type of key center that implements a key-distribution protocol (based on symmetric cryptography) to convey keys between two (or more) parties who wish to communicate securely. (Compare: key distribution center.)
$ キー換算センター（i）確実に通信したい2つの（またはそれ以上）の関係者の間のキーを伝えるための鍵配布プロトコル（対称暗号化に基づく）を実装するキーセンターの一種。（比較：鍵配布センター。）
Tutorial: A key translation center transfers keys for future communication between Bob and Alice, who (a) wish to communicate with each other but do not currently share keys, (b) each share a KEK with the center, and (c) have the ability to generate or acquire keys by themselves. Alice generates or acquires a set of keys for communication with Bob. Alice encrypts the set in the KEK she shares with the center and sends the encrypted set to the center. The center decrypts the set, reencrypts the set in the KEK it shares with Bob, and either (a) sends that reencrypted set to Alice for her to forward to Bob or (b) sends it directly to Bob (although direct distribution is not supported in the ANSI standard [A9017]).
チュートリアル：BobとAliceの間の将来の通信のための鍵を転送します。自分で鍵を生成または取得する機能。アリスはボブとの通信のための鍵のセットを生成または取得する。Aliceは、SETがCenterと共有するKEKに設定され、暗号化されたセットを中央に送信します。センターはセットを復号化し、Bobと共有するKEKのセットを再現します。また、LeenCryptedセットをBOBまたは（B）に転送するためにAliceに設定されたセットを送信します（直接配布はサポートされていません。ANSI規格[A9017]）。
$ key transport (algorithm or protocol) 1. (I) A key establishment method by which a secret key is generated by a system entity in a communication association and securely sent to another entity in the association. (Compare: key agreement.)
$ キートランスポート（アルゴリズムまたはプロトコル）1。（i）通信会においてシステムエンティティによって秘密鍵が生成され、その関連付けの他のエンティティに安全に送信される重要な確立方法。（Compare：主意契約）
Tutorial: Either (a) one entity generates a secret key and securely sends it to the other entity, or (b) each entity generates a secret value and securely sends it to the other entity, where the two values are combined to form a secret key. For example, a message originator can generate a random session key and then use the RSA algorithm to encrypt that key with the public key of the intended recipient.
チュートリアル：（a）1つのエンティティは秘密鍵を生成し、それを他のエンティティに安全に送信するか、または（b）各エンティティは秘密の値を生成し、それを他のエンティティに安全に送信します。キー。たとえば、メッセージ発信者はランダムセッションキーを生成してから、RSAアルゴリズムを使用して、そのキーを意図した受信者の公開鍵で暗号化できます。
2. (O) "The procedure to send a symmetric key from one party to other parties. As a result, all legitimate participants share a common symmetric key in such a way that the symmetric key is determined entirely by one party." [A9042]
2. （O） "1つの当事者から他の当事者に対称鍵を送信する手順。その結果、対称鍵が完全に一人の当事者によって決定されるように、すべての正規参加者が共通の対称鍵を共有しています。」[A9042]
$ key update 1. (I) Derive a new key from an existing key. (Compare: rekey.)
$ キーアップデート1.（i）既存のキーから新しいキーを導き出します。（比較：リリーキー）
2. (O) Irreversible cryptographic process that modifies a key to produce a new key. [C4009]
2. （O）新しいキーを作成するためのキーを変更する不可逆暗号化プロセス。[C4009]
$ key validation 1. (I) "The procedure for the receiver of a public key to check that the key conforms to the arithmetic requirements for such a key in order to thwart certain types of attacks." [A9042] (See: weak key)
$ 重要な検証1.（i）「公開鍵の受信者の手順は、特定の種類の攻撃を妨げるためにそのようなキーの算術要件に準拠していることを確認するための手順。[A9042]（参照：弱キー参照）
2. (D) Synonym for "certificate validation".
2. （d）「証明書検証」の同義語。
Deprecated Usage: IDOCs SHOULD NOT use the term as a synonym for "certificate validation"; that would unnecessarily duplicate the meaning of the latter term and mix concepts in a potentially misleading way. In validating an X.509 public-key certificate, the public key contained in the certificate is normally treated as an opaque data object.
廃止予定の使用法：IDOCは「証明書検証」の同義語として用語を使用しないでください。それは、後者の用語の意味を不必要に複製し、潜在的に誤解を招くような方法で概念を組み合わせます。X.509公開鍵証明書を検証する際には、証明書に含まれている公開鍵は通常不透明なデータオブジェクトとして扱われます。
$ keyed hash (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a hash result is varied by a second input parameter that is a cryptographic key. (See: checksum.)
$ キー付きハッシュ（i）ハッシュ結果へのマッピングが暗号鍵である第2の入力パラメータによって変化する暗号化ハッシュ（例えば、R1828]）。（チェックサムを参照してください。）
Tutorial: If the input data object is changed, a new, corresponding hash result cannot be correctly computed without knowledge of the secret key. Thus, the secret key protects the hash result so it can be used as a checksum even when there is a threat of an active attack on the data. There are two basic types of keyed hash: - A function based on a keyed encryption algorithm. Example: Data Authentication Code. - A function based on a keyless hash that is enhanced by combining (e.g., by concatenating) the input data object parameter with a key parameter before mapping to the hash result. Example: HMAC.
チュートリアル：入力データオブジェクトが変更された場合、新しい対応するハッシュ結果を秘密鍵の知識なしに正しく計算することはできません。したがって、秘密鍵はハッシュ結果を保護しているため、データに積極的な攻撃の脅威がある場合でもチェックサムとして使用できます。キー付きハッシュの2つの基本的なタイプがあります。 - キー付き暗号化アルゴリズムに基づく関数。例：データ認証コード。 - ハッシュ結果にマッピングする前に、入力データオブジェクトパラメータを鍵パラメータと組み合わせることによって（例えば、連結することにより）組み合わせることによって拡張されたキーレスハッシュに基づく関数。例：HMAC。
$ keying material 1. (I) Data that is needed to establish and maintain a cryptographic security association, such as keys, key pairs, and IVs.
$ キーイング素材1.（i）キー、キーペア、IVSなどの暗号化セキュリティアソシエーションを確立して維持するために必要なデータ。
2. (O) "Key, code, or authentication information in physical or magnetic form." [C4009] (Compare: COMSEC material.)
2. （O）「身体的または磁気的形式のキー」、コード、または認証情報。」[C4009]（比較：COMSEC資料）
$ keying material identifier (KMID) 1. (I) An identifier assigned to an item of keying material.
$ キーイング品目識別子（KMID）1。（i）キーイング材料の項目に割り当てられた識別子。
2. (O) /MISSI/ A 64-bit identifier that is assigned to a key pair when the public key is bound in a MISSI X.509 public-key certificate.
2. （O）/ MISSI / A64ビット識別子公開鍵がMissi X.509公開鍵証明書にバインドされているときに鍵ペアに割り当てられている識別子。
$ Khafre (N) A patented, symmetric block cipher designed by Ralph C. Merkle as a plug-in replacement for DES. [Schn]
$ Khafre（n）Ralph C.Merkleによって設計された特許取得済みの対称ブロック暗号は、DESのプラグイン置き換えとして。[シュン]
Tutorial: Khafre was designed for efficient encryption of small amounts of data. However, because Khafre does not precompute tables used for encryption, it is slower than Khufu for large amounts of data.
チュートリアル：Khafreは少量のデータの効率的な暗号化のために設計されました。ただし、Khafreは暗号化に使用されるテーブルを事前計算するものではないため、大量のデータのためにKHUFUより遅いです。
$ Khufu (N) A patented, symmetric block cipher designed by Ralph C. Merkle as a plug-in replacement for DES. [Schn]
$ Khufu（n）Ralph Cによって設計された特許取得済み対称ブロック暗号は、DESのプラグイン置き換えとして。[シュン]
Tutorial: Khufu was designed for fast encryption of large amounts of data. However, because Khufu precomputes tables used in encryption, it is less efficient than Khafre for small amounts of data.
チュートリアル：Khufuは大量のデータの高速暗号化のために設計されました。ただし、KHUFUが暗号化に使用されるテーブルを事前に事前に処理しているため、少量のデータに対してKhafreよりも効率的です。
$ KLIF (N) See: key loading and initialization facility.
$ KLIF（N）キーホードおよび初期化機能を参照してください。
$ KMID (I) See: keying material identifier.
$ kmid（i）キーイング材料識別子を参照してください。
$ known-plaintext attack (I) A cryptanalysis technique in which the analyst tries to determine the key from knowledge of some plaintext-ciphertext pairs (although the analyst may also have other clues, such as knowing the cryptographic algorithm).
$ 既知の平文攻撃（i）アナリストがいくつかの平文 - 暗号文ペアの知識からの鍵を決定しようとする暗号解析技術（アナリストは、暗号化アルゴリズムを知るなどの他の手がかりも持っているかもしれません）。
$ kracker (O) Old spelling for "cracker".
$ KRACKER（O）「クラッカー」のための古いスペル。
$ KSOS, KSOS-6, KSOS-11 (O) See: Kernelized Secure Operating System.
$ KSOS、KSOS-6、KSOS-11（O）：カーネル化セキュアオペレーティングシステム。
$ L2F (N) See: Layer 2 Forwarding Protocol.
$ L2F（n）参照：レイヤ2転送プロトコルを参照してください。
$ L2TP (N) See: Layer 2 Tunneling Protocol.
$ L2TP（N）レイヤ2トンネリングプロトコルを参照してください。
$ label See: time stamp, security label.
$ レーベル参照：タイムスタンプ、セキュリティラベル。
$ laboratory attack (O) "Use of sophisticated signal recovery equipment in a laboratory environment to recover information from data storage media." [C4009]
$ 実験室攻撃（O）「データ記憶媒体から情報を回復するための実験室環境における洗練された信号回復装置の使用」[C4009]
$ LAN (I) Abbreviation for "local area network" [R1983]. (See: [FP191].)
$ LAN（i）「ローカルエリアネットワーク」[R1983]の略語。（[参照] [FP191]を参照）
$ land attack (I) A denial-of-service attack that sends an IP packet that (a) has the same address in both the Source Address and Destination Address fields and (b) contains a TCP SYN packet that has the same port number in both the Source Port and Destination Port fields.
$ Land Attact（i）送信元アドレスフィールドと宛先アドレスフィールドの両方で（a）が同じアドレスを持つIPパケットを送信するサービス拒否攻撃、（B）には同じポート番号が含まれているTCP SYNパケットが含まれています。ソースポートと宛先ポートフィールドの両方です。
Derivation: This single-packet attack was named for "land", the program originally published by the cracker who invented this exploit. Perhaps that name was chosen because the inventor thought of multi-packet (i.e., flooding) attacks as arriving by sea.
派生：このシングルパケット攻撃は、この悪用を発明したクラッカーによって最初に公開されたプログラムである「土地」と名付けられました。発明者は海によって到着したようなマルチパケット（すなわち洪水）攻撃を考えたので、その名前が選択された。
$ Language of Temporal Ordering Specification (LOTOS) (N) A language (ISO 8807-1990) for formal specification of computer network protocols; describes the order in which events occur.
$ コンピュータネットワークプロトコルの正式な仕様のための時間的順序付け仕様書（NOLOS）（N）言語（ISO 8807-1990）。イベントが発生する順序を説明します。
$ lattice (I) A finite set together with a partial ordering on its elements such that for every pair of elements there is a least upper bound and a greatest lower bound.
$ 格子（i）要素の一対の要素に対して最小上限および最大の下限があるように、その要素上の部分的な順序付けと共に有限セット。
Example: A lattice is formed by a finite set S of security levels -- i.e., a set S of all ordered pairs (x,c), where x is one of a finite set X of hierarchically ordered classification levels X(1), non-hierarchical categories C(1), ..., C(M) -- together with the "dominate" relation. Security level (x,c) is said to "dominate" (x',c') if and only if (a) x is greater (higher) than or equal to x' and (b) c includes at least all of the elements of c'. (See: dominate, lattice model.)
例：格子は、セキュリティレベルの有限セットSによって形成されます - すなわち、すべての順序付けられたペアのセットS（x、c）。ここで、xは階層的に順序付けられた分類レベルx（1）の有限セットxの1つです。非階層カテゴリC（1）、...、C（M） - 「支配的」の関係と共に。セキュリティレベル（x、c）は、（a）xがx '以上（b）c以上の場合に限り、（a）xが少なくともすべてを含む場合に限り、「dominate」（x'、c '）と言われている。C 'の要素（以下を参照してください。格子モデル。）
Tutorial: Lattices are used in some branches of cryptography, both as a basis for hard computational problems upon which cryptographic algorithms can be defined, and also as a basis for attacks on cryptographic algorithms.
チュートリアル：格子は、暗号化アルゴリズムが定義できるハード計算上の問題の基礎として、また暗号化アルゴリズムに対する攻撃の基礎としても、暗号のいくつかの分岐で使用されます。
$ lattice model 1. (I) A description of the semantic structure formed by a finite set of security levels, such as those used in military organizations. (See: dominate, lattice, security model.) 2. (I) /formal model/ A model for flow control in a system, based on the lattice that is formed by the finite security levels in a system and their partial ordering. [Denn]
$格子モデル1.（i）軍事組織で使用されているもののような有限セットセットによって形成された意味構造の説明。（（記配、格子、セキュリティモデル）2。システム内の有限のセキュリティレベルとその部分的な順序によって形成される格子に基づく、システム内のフロー制御のためのモデル[Denn]
$ Law Enforcement Access Field (LEAF) (N) A data item that is automatically embedded in data encrypted by devices (e.g., CLIPPER chip) that implement the Escrowed Encryption Standard.
$ 法執行機関アクセスフィールド（リーフ）（n）預託された暗号化規格を実装する装置（例えば、クリッパーチップ）によって暗号化されたデータに自動的に埋め込まれるデータ項目。
$ Layer 1, 2, 3, 4, 5, 6, 7 (N) See: OSIRM.
$ レイヤ1,2,3,4,5,6,7（n）参照：OSIRM。
$ Layer 2 Forwarding Protocol (L2F) (N) An Internet protocol (originally developed by Cisco Corporation) that uses tunneling of PPP over IP to create a virtual extension of a dial-up link across a network, initiated by the dial-up server and transparent to the dial-up user. (See: L2TP.)
$ レイヤ2転送プロトコル（n）PPPを介したPPPのトンネリングを使用して、ダイヤルアップサーバによって開始されたネットワーク全体でのダイヤルアップリンクの仮想拡張を作成するインターネットプロトコル（Cisco Corporationによって開発されました）。ダイヤルアップユーザーに透過します。（：L2TPを参照してください。）
$ Layer 2 Tunneling Protocol (L2TP) (N) An Internet client-server protocol that combines aspects of PPTP and L2F and supports tunneling of PPP over an IP network or over frame relay or other switched network. (See: VPN.)
$ レイヤ2トンネリングプロトコル（L2TP）（n）PPTPとL2Fの側面を組み合わせたインターネットクライアント - サーバプロトコルで、IPネットワークまたはフレームリレーまたは他のスイッチドネットワークを介してPPPのトンネリングをサポートします。（：VPNを参照してください。）
Tutorial: PPP can in turn encapsulate any OSIRM Layer 3 protocol. Thus, L2TP does not specify security services; it depends on protocols layered above and below it to provide any needed security.
チュートリアル：PPPは次にOSIRMレイヤ3プロトコルをカプセル化できます。したがって、L2TPはセキュリティサービスを指定しません。それは必要なセキュリティを提供するために上下にレイヤーされたプロトコルによって異なります。
$ LDAP (I) See: Lightweight Directory Access Protocol.
$ LDAP（i）軽量ディレクトリアクセスプロトコルを参照してください。
$ least common mechanism (I) The principle that a security architecture should minimize reliance on mechanisms that are shared by many users.
$ 少なくとも共通のメカニズム（i）セキュリティアーキテクチャが多くのユーザーによって共有されているメカニズムへの依存を最小限に抑えるべきであるという原則。
Tutorial: Shared mechanisms may include cross-talk paths that permit a breach of data security, and it is difficult to make a single mechanism operate in a correct and trusted manner to the satisfaction of a wide range of users.
チュートリアル：共有メカニズムには、データセキュリティの違反を許可するクロストークパスが含まれている場合があります。これは、単一のメカニズムを正しいかつ信頼できる方法で幅広いユーザーの満足度にすることは困難です。
$ least privilege (I) The principle that a security architecture should be designed so that each system entity is granted the minimum system resources and authorizations that the entity needs to do its work. (Compare: economy of mechanism, least trust.) Tutorial: This principle tends to limit damage that can be caused by an accident, error, or unauthorized act. This principle also tends to reduce complexity and promote modularity, which can make certification easier and more effective. This principle is similar to the principle of protocol layering, wherein each layer provides specific, limited communication services, and the functions in one layer are independent of those in other layers.
$最小権限（i）各システムエンティティに各システムエンティティが最小システムリソースと承認を与えられるように設計されるべきという原則は、エンティティがその作業を行う必要があることを認識しています。（比較：メカニズムの経済、最小信頼）チュートリアル：この原則は、事故、誤差、または不正行為によって引き起こされる可能性がある損害を制限する傾向があります。この原則はまた、複雑さを減らし、モジュール性を促進する傾向があり、これは認証を容易にそしてより効果的にすることができる。この原理はプロトコル階層化の原理と似ており、各層は特定の制限された通信サービスを提供し、1つの層の機能は他の層のものとは無関係である。
$ least trust (I) The principle that a security architecture should be designed in a way that minimizes (a) the number of components that require trust and (b) the extent to which each component is trusted. (Compare: least privilege, trust level.)
$ 最小信頼（i）セキュリティアーキテクチャが（a）信頼を必要とするコンポーネントの数を最小化するような方法で設計されるべきであるという原則は、（b）各コンポーネントが信頼される範囲を占めています。（比較：最小特権、信頼レベル。）
$ legacy system (I) A system that is in operation but will not be improved or expanded while a new system is being developed to supersede it.
$ Legacy System（i）操作中のシステムではなく、新しいシステムが提供されている間は改善または拡大されません。
$ legal non-repudiation (I) See: secondary definition under "non-repudiation".
$ 法的な否認（i）「非否認」の下の二次定義。
$ leap of faith 1. (I) /general security/ Operating a system as though it began operation in a secure state, even though it cannot be proven that such a state was established (i.e., even though a security compromise might have occurred at or before the time when operation began).
$ （i）/一般セキュリティ/システムの運用は、このような状態が確立されたことが証明されていても、安全な状態で運用を開始しました（つまり、セキュリティの妥協が発生した場合でも操作が始まった時の前に）。
2. (I) /COMSEC/ The initial part, i.e., the first communication step, or steps, of a protocol that is vulnerable to attack (especially a man-in-the-middle attack) during that part but, if that part is completed without being attacked, is subsequently not vulnerable in later steps (i.e., results in a secure communication association for which no man-in-the-middle attack is possible).
2. （i）/ comsec /初期部分、すなわち、その部分の間の攻撃（特に中間攻撃）の脆弱なプロトコルの最初の通信ステップ、またはステップ。攻撃されることなく、その後後のステップで脆弱ではない（すなわち、中間攻撃が可能でない安全な通信協会をもたらす）。
Usage: This term is listed in English dictionaries, but their definitions are broad and can be interpreted in many ways in Internet contexts. Similarly, the definition stated here can be interpreted in several ways. Therefore, IDOCs that use this term (especially IDOCs that are protocol specifications) SHOULD state a more specific definition for it.
使用法：この用語は英語辞書に記載されていますが、その定義は広く、インターネットコンテキストでさまざまな方法で解釈できます。同様に、ここに記載されている定義はいくつかの方法で解釈できます。したがって、この用語を使用するIDoc（特にプロトコル仕様であるIDoc）は、それについてより具体的な定義を述べるべきです。
Tutorial: In a protocol, a leap of faith typically consists of accepting a claim of peer identity, data origin, or data integrity without authenticating that claim. When a protocol includes such a step, the protocol might also be designed so that if a man-in-the-middle attack succeeds during the vulnerable first part, then the attacker must remain in the middle for all subsequent exchanges or else one of the legitimate parties will be able to detect the attack.
チュートリアル：プロトコルでは、信仰の飛躍は通常、その主張を認証することなく、ピアアイデンティティ、データの原点、またはデータの整合性の主張を受け入れることからなる。プロトコルがそのようなステップを含むとき、プロトコルはまた、中間的な攻撃が脆弱な最初の部分の間に成功した場合、攻撃者はその後のすべての交換のために中央に残っている必要があります。合法的な締約国は攻撃を検出することができます。
$ level of concern (N) /U.S. DoD/ A rating assigned to an information system that indicates the extent to which protective measures, techniques, and procedures must be applied. (See: critical, sensitive, level of robustness.)
$ 懸念レベル（N）/ U.S。DOD /保護対策、技術、および手順を適用しなければならない範囲を示す情報システムに割り当てられた評価。（批判的、敏感な、堅牢性のレベルを参照してください。）
$ level of robustness (N) /U.S. DoD/ A characterization of (a) the strength of a security function, mechanism, service, or solution and (b) the assurance (or confidence) that it is implemented and functioning. [Cons, IATF] (See: level of concern.)
$ 堅牢性のレベル（N）/U。DOD /（a）セキュリティ機能、メカニズム、サービス、または解決策の強さ、および（B）それが実装され機能している保証（または自信）の強さ。[短所、IATF]（懸念のレベルを参照してください。）
$ Liberty Alliance (O) An international consortium of more than 150 commercial, nonprofit, and governmental organizations that was created in 2001 to address technical, business, and policy problems of identity and identity-based Web services and develop a standard for federated network identity that supports current and emerging network devices.
$ Liberty Alliance（o）IDとIDベースのWebサービスの技術的、ビジネス、およびポリシーの問題に対処し、連合ネットワークIDの標準を開発するために、2001年に開発された150以上のコマーシャル、非営利金、および政府機関の国際コンソーシアム。電流と新興国のネットワークデバイスをサポートします。
$ Lightweight Directory Access Protocol (LDAP) (I) An Internet client-server protocol (RFC 3377) that supports basic use of the X.500 Directory (or other directory servers) without incurring the resource requirements of the full Directory Access Protocol (DAP).
$ 軽量ディレクトリアクセスプロトコル（I）フルディレクトリアクセスプロトコル（DAP）のリソース要件を招くことなく、X.500ディレクトリ（または他のディレクトリサーバ）の基本的な使用をサポートするインターネットクライアント - サーバプロトコル（RFC 3377）。。
Tutorial: Designed for simple management and browser applications that provide simple read/write interactive directory service. Supports both simple authentication and strong authentication of the client to the directory server.
チュートリアル：簡単な読み書き対話型ディレクトリサービスを提供する簡単な管理とブラウザアプリケーション用に設計されています。単純認証とクライアントの強力な認証とディレクトリサーバーへの認証の両方をサポートします。
$ link 1a. (I) A communication facility or physical medium that can sustain data communications between multiple network nodes, in the protocol layer immediately below IP. (RFC 3753)
$ リンク1a。（i）IPの直下のプロトコル層に、複数のネットワークノード間でデータ通信を維持することができる通信機能または物理媒体。（RFC 3753）
1b. (I) /subnetwork/ A communication channel connecting subnetwork relays (especially one between two packet switches) that is implemented at OSIRM Layer 2. (See: link encryption.)
1b。（i）/サブネットワーク/ A OSIRMレイヤ2で実装されているサブネットワークリレー（特に2つのパケットスイッチの間の1つ）を接続する通信チャネル（特にリンク暗号化を参照）
Tutorial: The relay computers assume that links are logically passive. If a computer at one end of a link sends a sequence of bits, the sequence simply arrives at the other end after a finite time, although some bits may have been changed either accidentally (errors) or by active wiretapping.
チュートリアル：リレーコンピュータは、リンクが論理的に受動的であると仮定します。リンクの一端のコンピュータが一連のビットを送信すると、一部のビットが誤って誤って変更されている可能性があるが、一部のビットが誤ってまたはアクティブなワイビングによって変更された可能性がある。
2. (I) /World Wide Web/ See: hyperlink.
2. （i）/ワールドワイドウェブ/参照：ハイパーリンク。
$ link encryption (I) Stepwise (link-by-link) protection of data that flows between two points in a network, provided by encrypting data separately on each network link, i.e., by encrypting data when it leaves a host or subnetwork relay and decrypting when it arrives at the next host or relay. Each link may use a different key or even a different algorithm. [R1455] (Compare: end-to-end encryption.)
$ リンク暗号化（I）段階的（リンクバイリンク）ネットワーク内の2つの点間を流れるデータの保護各ネットワークリンクで個別にデータを暗号化することによって、すなわちホストまたはサブネットワークの中継と復号化を残すときにデータを暗号化することによって提供されるデータの保護それが次のホストまたは中継に到着するとき。各リンクは異なるキーまたは異なるアルゴリズムを使用することができます。[R1455]（比較：エンドツーエンドの暗号化）
$ liveness (I) A property of a communication association or a feature of a communication protocol that provides assurance to the recipient of data that the data is being freshly transmitted by its originator, i.e., that the data is not being replayed, by either the originator or a third party, from a previous transmission. (See: fresh, nonce, replay attack.)
$ Livity（i）データがその発信者によって新たに送信されているデータの受信者に保証を提供するコミュニケーションプロトコルの特徴、すなわちデータが再生されていないこと、すなわちオリジネータによってデータが再生されていない以前の送信からの第三者または第三者。（参照：新鮮な、ノンス、リプレイ攻撃。）
$ logic bomb (I) Malicious logic that activates when specified conditions are met. Usually intended to cause denial of service or otherwise damage system resources. (See: Trojan horse, virus, worm.)
$ 論理爆弾（i）指定された条件が満たされたときに起動する悪意のあるロジック。通常、サービス拒否またはその他の方法でシステムリソースを損傷することを目的としています。（調べてください：トロイの木馬、ウイルス、ワーム。）
$ login 1a. (I) An act by which a system entity establishes a session in which the entity can use system resources. (See: principal, session.)
$ ログイン1A。（i）システムエンティティがシステムリソースを使用できるセッションを確立するための行為。（：プリンシパル、セッション。）
1b. (I) An act by which a system user has its identity authenticated by the system. (See: principal, session.)
1b。（i）システムユーザーがシステムによって認証されているACT。（：プリンシパル、セッション。）
Usage: Usually understood to be accomplished by providing an identifier and matching authentication information (e.g., a password) to a security mechanism that authenticates the user's identity; but sometimes refers to establishing a connection with a server when no authentication or specific authorization is involved.
使用法：通常、ユーザーの身元を認証するセキュリティメカニズムに識別子を提供し、照合認証情報（たとえばパスワード）を提供することによって達成されると理解されていました。しかし、認証や特定の許可が含まれていないときにサーバーとの接続を確立することを指すことがあります。
Derivation: Refers to "log" file, a security audit trail that records (a) security events, such as the beginning of a session, and (b) the names of the system entities that initiate events.
派生：「ログ」ファイル、セッションの先頭などのセキュリティイベント、および（b）イベントを開始するシステムエンティティの名前を記録するセキュリティ監査証跡を指します。
$ long title (O) /U.S. Government/ "Descriptive title of [an item of COMSEC material]." [C4009] (Compare: short title.)
$ 長いタイトル（O）/U.S。政府/「ComSec資料の項目の説明的なタイトル」。[C4009]（比較：ショートタイトル。）
$ low probability of detection (I) Result of TRANSEC measures used to hide or disguise a communication.
$ 通信を隠すか偽装するために使用される経験措置の検出の低い確率。
$ low probability of intercept (I) Result of TRANSEC measures used to prevent interception of a communication.
$ 通信の傍受を防ぐために使用される傍受措置の傍受の低い可能性。
$ LOTOS (N) See: Language of Temporal Ordering Specification.
$ Lotos（N）は、時間的注文仕様書の言語を参照してください。
$ MAC (N) See: mandatory access control, Message Authentication Code.
$ Mac（N）は、必須のアクセス制御、メッセージ認証コードを参照してください。
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because this abbreviation is ambiguous.
廃止予定の使用法：この用語を使用するIDocは、この略語があいまいであるため、定義を定義します。
$ magnetic remanence (N) Magnetic representation of residual information remaining on a magnetic medium after the medium has been cleared. [NCS25] (See: clear, degauss, purge.)
$ 磁気残留物（N）媒体の後に磁性媒質上に残っている残留情報の磁気表現がクリアされた。[NCS25]（参照：クリア、デガウス、パージ。）
$ main mode (I) See: /IKE/ under "mode".
$ メインモード（I）/ IKE /「モード」の下にある：
$ maintenance hook (N) "Special instructions (trapdoors) in software allowing easy maintenance and additional feature development. Since maintenance hooks frequently allow entry into the code without the usual checks, they are a serious security risk if they are not removed prior to live implementation." [C4009] (See: back door.)
$ メンテナンスフック（n） "ソフトウェアでの特別な指示（トラプト）は、メンテナンスと追加機能の開発を可能にします。メンテナンスフックは通常の小切手なしにコードへのエントリを頻繁に許可するため、実装の前に削除されない場合は重大なセキュリティリスクです。。」[C4009]（参照：バックドア）
$ malicious logic (I) Hardware, firmware, or software that is intentionally included or inserted in a system for a harmful purpose. (See: logic bomb, Trojan horse, spyware, virus, worm. Compare: secondary definitions under "corruption", "incapacitation", "masquerade", and "misuse".)
$ 悪意のある論理（i）故意に有害な目的のためにシステムに故意に含まれているかまたは挿入されているハードウェア、ファームウェア、またはソフトウェア。（論理爆弾、トロイの木馬、スパイウェア、ウイルス、ワーム。比較：「汚職」、「軽減」、「マスカレード」、「誤用」の下の二次定義。）
$ malware (D) A contraction of "malicious software". (See: malicious logic.)
$ マルウェア（d）「悪意のあるソフトウェア」の縮小。（悪意のある論理を参照してください。）
Deprecated Term: IDOCs SHOULD NOT use this term; it is not listed in most dictionaries and could confuse international readers.
廃止予定語：IDocsはこの用語を使用しないでください。それはほとんどの辞書にリストされておらず、国際的な読者を混同することができます。
$ MAN (I) metropolitan area network.
$ man（i）首都圏ネットワーク。
$ man-in-the-middle attack (I) A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication association. (See: hijack attack, piggyback attack.)
$ Man-in-The-Middle Attact（i）攻撃者が通信会に関与するエンティティの1つ以上のエンティティとして通信データをマスカレードに切り替えて選択的に変更するアクティブな盗聴攻撃の形式。（：ハイジャック攻撃、ピギーバック攻撃）
Tutorial: For example, suppose Alice and Bob try to establish a session key by using the Diffie-Hellman-Merkle algorithm without data origin authentication service. A "man in the middle" could (a) block direct communication between Alice and Bob and then (b) masquerade as Alice sending data to Bob, (c) masquerade as Bob sending data to Alice, (d) establish separate session keys with each of them, and (e) function as a clandestine proxy server between them to capture or modify sensitive information that Alice and Bob think they are sending only to each other.
チュートリアル：たとえば、AliceとBobがデータオリジナル認証サービスなしでdiffie-hellman-merkleアルゴリズムを使用してセッションキーを確立しようとしているとします。「中央の男」（a）アリスとボブとの間の直接通信をブロックすることができ、次に（b）BOBへのデータ送信データをAliceとしてのアリスをアリスに送信すると（C）マスカレードとしてマスカレード、（d）、（d）では別々のセッションキーを確立します。それらの各々は、それらの間のクランディスプロキシサーバとして機能し、アリスとボブが互いに送信していると思う機密情報をキャプチャまたは変更する。
$ manager (I) A person who controls the service configuration of a system or the functional privileges of operators and other users. (See: administrative security. Compare: operator, SSO, user.)
$ マネージャー（i）システムのサービス構成または演算子やその他のユーザーの機能特権を管理する人。（管理セキュリティを参照してください。比較：演算子、SSO、ユーザー。）
$ mandatory access control 1. (I) An access control service that enforces a security policy based on comparing (a) security labels, which indicate how sensitive or critical system resources are, with (b) security clearances, which indicate that system entities are eligible to access certain resources. (See: discretionary access control, MAC, rule-based security policy.)
$ 必須アクセス制御1.（i）システムエンティティが適格であることを示す（B）身体の区切りまたは重要なシステムリソースを示すセキュリティラベルの比較（a）セキュリティラベルの比較に基づくセキュリティポリシーを強制するアクセス制御サービス。特定のリソースにアクセスするには。（任意のアクセス制御、MAC、ルールベースのセキュリティポリシー）
Derivation: This kind of access control is called "mandatory" because an entity that has clearance to access a resource is not permitted, just by its own volition, to enable another entity to access that resource.
派生：この種のアクセス制御は、リソースにアクセスするためのクリアランスを持つエンティティが、それ自身のボディィションだけで、別のエンティティがそのリソースにアクセスできるようにするために許可されていないため、「必須」と呼ばれます。
2. (O) "A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity." [DoD1]
2. （O）「オブジェクトに含まれる情報の感度（ラベルで表されるような）に基づいてオブジェクトへのアクセスを制限する手段と、この感度の情報にアクセスするための対象の正式な承認（すなわちクリアランス）。[DOD1]
$ manipulation detection code (D) Synonym for "checksum".
$ 操作検出コード（D）「チェックサム」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for "checksum"; the word "manipulation" implies protection against active attacks, which an ordinary checksum might not provide. Instead, if such protection is intended, use "protected checksum" or some particular type thereof, depending on which is meant. If such protection is not intended, use "error detection code" or some specific type of checksum that is not protected.
廃止予定の用語：IDocは、この用語を「チェックサム」の同義語として使用しないでください。「操作」という言葉は、通常のチェックサムが提供されない可能性があるアクティブ攻撃に対する保護を意味します。代わりに、そのような保護が意図されている場合は、「保護されたチェックサム」またはその特定の種類を使用しています。そのような保護が意図されていない場合は、「エラー検出コード」または保護されていない特定の種類のチェックサムを使用してください。
$ marking See: time stamp, security marking.
$ マーキング：タイムスタンプ、セキュリティマーキング。
$ MARS (O) A symmetric, 128-bit block cipher with variable key length (128 to 448 bits), developed by IBM as a candidate for the AES.
$ MARS（O）AESの候補としてIBMによって開発された可変キー長（128~448ビット）を有する対称的な128ビットブロック暗号。
$ Martian (D) /slang/ A packet that arrives unexpectedly at the wrong address or on the wrong network because of incorrect routing or because it has a non-registered or ill-formed IP address. [R1208]
$ 間違ったルーティングや登録されていないIPアドレスがあるため、または誤ったネットワークで誤って到着するパケットまたは誤ったネットワークで予期せずに到着するパケット。[R1208]
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ masquerade (I) A type of threat action whereby an unauthorized entity gains access to a system or performs a malicious act by illegitimately posing as an authorized entity. (See: deception.)
$ 不正なエンティティがシステムへのアクセスを取得するか、許可されたエンティティとして不正にポーズすることで悪意のある行為を実行する脅威行動の一種（i）。（詐欺を参照してください。）
Usage: This type of threat action includes the following subtypes: - "Spoof": Attempt by an unauthorized entity to gain access to a system by posing as an authorized user. - "Malicious logic": In context of masquerade, any hardware, firmware, or software (e.g., Trojan horse) that appears to perform a useful or desirable function, but actually gains unauthorized access to system resources or tricks a user into executing other malicious logic. (See: corruption, incapacitation, main entry for "malicious logic", misuse.)
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「悪意のある論理」：有用なまたは望ましい機能を実行するように見える任意のハードウェア、ファームウェア、またはソフトウェア（例えば、トロイの木馬）のコンテキストでは、実際にシステムリソースへの不正アクセスまたはユーザが他の悪意のある実行にユーザをトリックする論理。（参照：汚職、無能力、「悪意のある論理」のメインエントリー、誤用。
$ MCA (O) See: merchant certification authority.
$ MCA（o）マーチャント認証局を参照してください。
$ MD2 (N) A cryptographic hash [R1319] that produces a 128-bit hash result, was designed by Ron Rivest, and is similar to MD4 and MD5 but slower.
$ MD2（n）128ビットハッシュ結果を生成する暗号化ハッシュ[R1319]は、RON RIVESTによって設計され、MD4とMD5と似ていますが、遅くなります。
Derivation: Apparently, an abbreviation of "message digest", but that term is deprecated by this Glossary.
派生：明らかに、「メッセージダイジェスト」の略語ですが、その用語はこの用語集によって推奨されています。
$ MD4 (N) A cryptographic hash [R1320] that produces a 128-bit hash result and was designed by Ron Rivest. (See: Derivation under "MD2", SHA-1.)
$ MD4（n）128ビットハッシュ結果を生み出し、RON Rivestによって設計された暗号化ハッシュ[R1320]。（「MD2」の「派生」、SHA-1。）
$ MD5 (N) A cryptographic hash [R1321] that produces a 128-bit hash result and was designed by Ron Rivest to be an improved version of MD4. (See: Derivation under "MD2".)
$ MD5（n）128ビットハッシュ結果を生成し、RON Rivestによって設計され、RON RivestがMD4の改良版であるように設計されています。（「MD2」の「派生」）
$ merchant (O) /SET/ "A seller of goods, services, and/or other information who accepts payment for these items electronically." [SET2] A merchant may also provide electronic selling services and/or electronic delivery of items for sale. With SET, the merchant can offer its cardholders secure electronic interactions, but a merchant that accepts payment cards is required to have a relationship with an acquirer. [SET1, SET2]
$ 商人（o）/ set / "これらの商品の支払いを受け入れる商品、サービス、および/またはその他の情報の売り手。」[SET2]商人はまた、電子販売サービスおよび/または販売のための電子供給を提供することができる。セットでは、マーチャントはそのカード保有者をセキュア電子的な相互作用を提供することができますが、入金カードを受け入れるマーチャントは、取得者との関係を持つことが必要です。[SET1、SET2]
$ merchant certificate (O) /SET/ A public-key certificate issued to a merchant. Sometimes used to refer to a pair of such certificates where one is for digital signature use and the other is for encryption.
$ 商人証明書（o）/ set /販売者に発行された公開鍵証明書。一方のそのような証明書のペアを指すために使用されることもあり、もう1つは暗号化のためのものです。
$ merchant certification authority (MCA) (O) /SET/ A CA that issues digital certificates to merchants and is operated on behalf of a payment card brand, an acquirer, or another party according to brand rules. Acquirers verify and approve requests for merchant certificates prior to issuance by the MCA. An MCA does not issue a CRL, but does distribute CRLs issued by root CAs, brand CAs, geopolitical CAs, and payment gateway CAs. [SET2]
$ マーチャント認証局（MCA）（O）/ SET / A CAは商務省にデジタル証明書を発行し、ブランドルールによると、支払いカードブランド、取得者、または他の当事者に代わって運営されています。Acquirersは、MCAによる発行前のマーチャント証明書の要求を検証して承認します。MCAはCRLを発行しませんが、root CAS、ブランドのCAS、地域CAS、および支払いゲートウェイCASによって発行されたCRLを配布しています。[SET2]
$ mesh PKI (I) A non-hierarchical PKI architecture in which there are several trusted CAs rather than a single root. Each certificate user bases path validations on the public key of one of the trusted CAs, usually the one that issued that user's own public-key certificate. Rather than having superior-to-subordinate relationships between CAs, the relationships are peer-to-peer, and CAs issue cross-certificates to each other. (Compare: hierarchical PKI, trust-file PKI.)
$ メッシュPKI（i）単一の根本ではなく、いくつかの信頼できるCASがある非階層型PKIアーキテクチャ。各証明書ユーザーは、信頼できるCAのうちの1つの公開鍵でパス検証を基本させます。通常、そのユーザー自身の公開鍵証明書を発行したものです。CAS間に優れた関係を持つのではなく、関係はピアツーピア、CASの発行は互いに交差証明書です。（比較：階層型PKI、信頼ファイルPKI）
$ Message Authentication Code (MAC), message authentication code 1. (N) /capitalized/ A specific ANSI standard for a checksum that is computed with a keyed hash that is based on DES. [A9009] Usage: a.k.a. Data Authentication Code, which is a U.S. Government standard. [FP113] (See: MAC.)
$ メッセージ認証コード（MAC）、メッセージ認証コード1.（N）/資本化/ DESに基づくキー付きハッシュで計算されるチェックサムの特定のANSI規格。[A9009]使用法：a.k.a.米国政府規格であるデータ認証コード。[FP113]（Macを参照）
2. (D) /not capitalized/ Synonym for "error detection code".
2. （d）/資本化されていない/「エラー検出コード」の同義語。
Deprecated Term: IDOCs SHOULD NOT use the uncapitalized form "message authentication code". Instead, use "checksum", "error detection code", "hash", "keyed hash", "Message Authentication Code", or "protected checksum", depending on what is meant. (See: authentication code.)
廃止予定語：IDocは、Uncapitalizedフォーム「メッセージ認証コード」を使用しないでください。代わりに、「チェックサム」、「エラー検出コード」、「hash」、「鍵付きハッシュ」、「メッセージ認証コード」、「保護されたチェックサム」を使用しています。（認証コードを参照してください。）
The uncapitalized form mixes concepts in a potentially misleading way. The word "message" is misleading because it implies that the mechanism is particularly suitable for or limited to electronic mail (see: Message Handling Systems). The word "authentication" is misleading because the mechanism primarily serves a data integrity function rather than an authentication function. The word "code" is misleading because it implies that either encoding or encryption is involved or that the term refers to computer software.
不安定な形式は潜在的に誤解を招くような方法で概念を混在させます。「メッセージ」という単語は、そのメカニズムが電子メールに特に適しているか、または制限されていることを意味するので誤解を招くこと（メッセージ処理システムを参照）。メカニズムは主に認証機能ではなくデータ整合性関数を提供するため、「認証」という単語が誤解を招くことです。「コード」という単語は、エンコードまたは暗号化のいずれかが関与しているか、またはその用語がコンピュータソフトウェアを指すことを意味するので誤解を招くことです。
$ message digest (D) Synonym for "hash result". (See: cryptographic hash.)
$ メッセージダイジェスト（D）「ハッシュ結果」の同義語。（参照：暗号化ハッシュ。）
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for "hash result"; this term unnecessarily duplicates the meaning of the other, more general term and mixes concepts in a potentially misleading way. The word "message" is misleading because it implies that the mechanism is particularly suitable for or limited to electronic mail (see: Message Handling Systems).
廃止予定の用語：IDocは、この用語を「ハッシュ結果」の同義語として使用しないでください。この用語は、不必要に他の一般的な用語で、潜在的に誤解を招くような方法で概念を混ざります。「メッセージ」という単語は、そのメカニズムが電子メールに特に適しているか、または制限されていることを意味するので誤解を招くこと（メッセージ処理システムを参照）。
$ message handling system (D) Synonym for the Internet electronic mail system.
$ メッセージ処理システム（D）インターネット電子メールシステムの同義語。
Deprecated Term: IDOCs SHOULD NOT use this term, because it could be confused with Message Handling System. Instead, use "Internet electronic mail" or some other, more specific term.
廃止予定の用語：IDOCは、メッセージ処理システムと混同される可能性があるため、この用語を使用しないでください。代わりに、「インターネット電子メール」やその他の特定の用語を使用してください。
$ Message Handling System (O) An ITU-T system concept that encompasses the notion of electronic mail but defines more comprehensive OSI systems and services that enable users to exchange messages on a store-and-forward basis. (The ISO equivalent is "Message Oriented Text Interchange System".) (See: X.400.)
$ メッセージ処理システム（O）電子メールの概念を網羅するが、ユーザが店頭でメッセージを交換できるようにするより包括的なOSIシステムおよびサービスを定義するITU - Tシステムの概念。（ISO等価物は「メッセージ指向のテキスト交換システム」です。）（X.400を参照）
$ message indicator 1. (D) /cryptographic function/ Synonym for "initialization value". (Compare: indicator.)
$ メッセージインジケータ1.（D）/暗号化機能/「初期化値」の同義語。（比較してください。）
2. (D) "Sequence of bits transmitted over a communications system for synchronizing cryptographic equipment." [C4009]
2. （d）暗号化装置を同期させるための通信システムを介して送信されるビットのシーケンス。」[C4009]
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for "initialization value"; the term mixes concepts in a potentially misleading way. The word "message" is misleading because it suggests that the mechanism is specific to electronic mail. (See: Message Handling System.)
廃止予定の用語：IDOCは、この用語を「初期化値」の同義語として使用しないでください。この用語は潜在的に誤解を招くような方法でミックスされます。「メッセージ」という言葉は、そのメカニズムが電子メールに固有のものであることを示唆しているため、誤解を招くことです。（メッセージ処理システムを参照してください。）
$ message integrity check $ message integrity code (MIC) (D) Synonyms for some form of "checksum".
$ メッセージの整合性チェック$ Message Integrity Code（MIC）（D）「チェックサム」の形式の同義語。
Deprecated Term: IDOCs SHOULD NOT use these terms for any form of checksum. Instead, use "checksum", "error detection code", "hash", "keyed hash", "Message Authentication Code", or "protected checksum", depending on what is meant.
廃止予定語：IDocsは、任意の形式のチェックサムについてこれらの用語を使用しないでください。代わりに、「チェックサム」、「エラー検出コード」、「hash」、「鍵付きハッシュ」、「メッセージ認証コード」、「保護されたチェックサム」を使用しています。
These two terms mix concepts in potentially misleading ways. The word "message" is misleading because it suggests that the mechanism is particularly suitable for or limited to electronic mail. The word "integrity" is misleading because the checksum may be used to perform a data origin authentication function rather than an integrity function. The word "code" is misleading because it suggests either that encoding or encryption is involved or that the term refers to computer software.
これら2つの用語は、潜在的に誤解を招く方法で概念を混在させます。「メッセージ」という言葉は、そのメカニズムが電子メールに特に適しているか、または制限されていることを示唆しているため、誤解を招くことです。チェックサムを使用して、整合性関数ではなくデータ原点認証機能を実行することができるので、「整合性」という単語が誤解を招くことです。「コード」という単語は、エンコードまたは暗号化が含まれているか、またはその用語がコンピュータソフトウェアを指すことを示唆しているため、誤解を招くことです。
$ Message Security Protocol (MSP) (N) A secure message handling protocol [SDNS7] for use with X.400 and Internet mail protocols. Developed by NSA's SDNS program and used in the U.S. DoD's Defense Message System.
$ Message Security Protocol（MSP）（N）X.400およびインターネットメールプロトコルで使用するための安全なメッセージ処理プロトコル[SDNS7]。NSAのSDNSプログラムによって開発され、米国のDODの防衛メッセージシステムで使用されています。
$ meta-data (I) Descriptive information about a data object; i.e., data about data, or data labels that describe other data. (See: security label. Compare: metadata)
$ メタデータ（i）データオブジェクトに関する記述情報。すなわち、データに関するデータ、または他のデータを記述するデータラベル。（検診ラベルを参照してください。比較：メタデータ）
Tutorial: Meta-data can serve various management purposes: - System management: File name, type, size, creation date. - Application management: Document title, version, author. - Usage management: Data categories, keywords, classifications.
チュートリアル：メタデータはさまざまな管理目的で役立ちます。 - システム管理：ファイル名、種類、サイズ、作成日。 - アプリケーション管理：文書のタイトル、バージョン、著者。 - 使用方法管理：データカテゴリ、キーワード、分類。
Meta-data can be associated with a data object in two basic ways: - Explicitly: Be part of the data object (e.g., a header field of a data file or packet) or be linked to the object. - Implicitly: Be associated with the data object because of some other, explicit attribute of the object.
メタデータは、次の2つの基本的な方法でデータオブジェクトに関連付けることができます。 - 明示的に：データオブジェクトの一部（例えば、データファイルまたはパケットのヘッダフィールド）またはオブジェクトにリンクされている。 - 暗黙的に：オブジェクトの他の、明示的な属性のためにデータオブジェクトに関連付けます。
$ metadata, Metadata(trademark), METADATA(trademark) (D) Proprietary variants of "meta-data". (See: SPAM(trademark).) Deprecated Usage: IDOCs SHOULD NOT use these unhypenated forms; IDOCs SHOULD use only the uncapitalized, hyphenated "meta-data". The terms "Metadata" and "METADATA" are claimed as registered trademarks (numbers 1,409,260 and 2,185,504) owned by The Metadata Company, originally known as Metadata Information Partners, a company founded by Jack Myers. The status of "metadata" is unclear.
$メタデータ、メタデータ（商標）、メタデータ（商標）（d）「メタデータ」の独自の亜種。（SPAM（商標）を参照）廃止予定の使用法：IDOCはこれらの不正な形式を使用しないでください。IDocは、キャピタライズされていないハイフネーションの「メタデータ」のみを使用する必要があります。「メタデータ」と「メタデータ」という用語は、Metadata Information Partners、Metadata Information Partners、Jack Myersが設立された会社として知られている登録商標（1,409,260,2,185,504）として主張されています。「メタデータ」のステータスは不明です。
$ MHS (N) See: message handling system.
$ MHS（n）メッセージ処理システムを参照してください。
$ MIC (D) See: message integrity code.
$ MIC（d）メッセージ整合性コードを参照してください。
$ MIME (I) See: Multipurpose Internet Mail Extensions.
$ MIME（I）：多目的インターネットメール拡張。
$ MIME Object Security Services (MOSS) (I) An Internet protocol [R1848] that applies end-to-end encryption and digital signature to MIME message content, using symmetric cryptography for encryption and asymmetric cryptography for key distribution and signature. MOSS is based on features and specifications of PEM. (See: S/MIME.)
$ MIMEオブジェクトセキュリティサービス（MOSS）（i）鍵配布と署名のための暗号化および非対称暗号化のための対称暗号化を使用して、エンドツーエンドの暗号化とデジタル署名をMIMEメッセージ内容に適用するインターネットプロトコル[R1848]。MOSSはPEMの特徴と仕様に基づいています。（S / MIMEを参照してください。）
$ Minimum Interoperability Specification for PKI Components (MISPC) (N) A technical description to provide a basis for interoperation between PKI components from different vendors; consists primarily of a profile of certificate and CRL extensions and a set of transactions for PKI operation. [SP15]
$ PKIコンポーネント（MISPC）の最小相互運用仕様（N）異なるベンダからのPKIコンポーネント間の相互運用の基礎を提供するための技術的な説明。主に証明書とCRL拡張機能とPKI操作の一連のトランザクションを主に構成します。[SP15]
$ misappropriation (I) A type of threat action whereby an entity assumes unauthorized logical or physical control of a system resource. (See: usurpation.)
$ 不正使用（I）エンティティがシステムリソースの不正な論理的または物理的制御を想定している脅威動作の一種。（：usurpation。）
Usage: This type of threat action includes the following subtypes: - Theft of data: Unauthorized acquisition and use of data contained in a system. - Theft of service: Unauthorized use of a system service. - Theft of functionality: Unauthorized acquisition of actual hardware, firmware, or software of a system component.
使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - データの盗難：不正な取得とシステムに含まれるデータの使用。 - サービスの盗難：システムサービスの不正使用。 - 機能の盗難システムコンポーネントの実際のハードウェア、ファームウェア、またはソフトウェアの不正な取得。
$ MISPC (N) See: Minimum Interoperability Specification for PKI Components.
$ MISPC（N）PKIコンポーネントの最小相互運用性仕様。
$ MISSI (O) Multilevel Information System Security Initiative, an NSA program to encourage development of interoperable, modular products for constructing secure network information systems in support of a wide variety of U.S. Government missions. (See: MSP, SP3, SP4.)
$ MISSI（O）マルチレベル情報システムセキュリティイニシアチブ、さまざまな米国政府のミッションをサポートするための安全なネットワーク情報システムを構築するための相互運用可能なモジュラー製品の開発を促進するためのNSAプログラム。（：MSP、SP3、SP4を参照してください。）
$ MISSI user (O) /MISSI/ A system entity that is the subject of one or more MISSI X.509 public-key certificates issued under a MISSI certification hierarchy. (See: personality.)
$ Missi User（O）/ Missi / Missi認証階層の下で発行された1つ以上のMissi X.509公開鍵証明書の主題であるシステムエンティティ。（人格を参照してください。）
Tutorial: MISSI users include both end users and the authorities that issue certificates. A MISSI user is usually a person but may be a machine or other automated process. Machines that are required to operate nonstop may be issued their own certificates to avoid downtime needed to exchange the FORTEZZA cards of machine operators at shift changes.
チュートリアル：Missiユーザーには、エンドユーザーと証明書を発行する権限の両方が含まれています。Missiユーザーは通常人ですが、機械やその他の自動プロセスでもよい。オペレーションに必要なマシンは、マシンオペレータのFortezzaカードをシフト変更時に交換するために必要な停止時間を回避するために、独自の証明書を発行することができます。
$ mission (I) A statement of a (relatively long-term) duty or (relatively short-term) task that is assigned to an organization or system, indicates the purpose and objectives of the duty or task, and may indicate the actions to be taken to achieve it.
$ ミッション（i）組織やシステムに割り当てられている（比較的長期的な）義務または（比較的短期的な）課題の声明は、義務またはタスクの目的と目的を示し、行動の行動を示している可能性があります。それを達成するために取られた。
$ mission critical (I) A condition of a system service or other system resource such that denial of access to, or lack of availability of, the resource would jeopardize a system user's ability to perform a primary mission function or would result in other serious consequences. (See: Critical. Compare: mission essential.)
$ ミッションクリティカル（i）リソースへのアクセス拒否、またはその利用可能性の欠如がシステムユーザーの主要な任務機能を実行するか、またはその他の重大な影響をもたらすようなシステムサービスまたは他のシステムリソースの状態。（重要：重要な。比較：ミッション不可欠なもの）
$ mission essential (O) /U.S. DoD/ Refers to materiel that is authorized and available to combat, combat support, combat service support, and combat readiness training forces to accomplish their assigned missions. [JP1] (Compare: mission critical.)
$ ミッション不可欠な（O）/U.S。DOD /承認され、戦闘支援、戦闘サービスサポート、および彼らの割り当てられた任務を達成するための戦闘準備訓練力を承認し、承認されたマテリアルを指します。[JP1]（比較：ミッションクリティカル）
$ misuse 1. (I) The intentional use (by authorized users) of system resources for other than authorized purposes. Example: An authorized system administrator creates an unauthorized account for a friend. (See: misuse detection.)
$ 誤用1.（i）許可された目的以外のシステムリソースの意図的な使用（許可ユーザーによる）。例：許可されたシステム管理者は、友達の不正なアカウントを作成します。（誤用検知を参照してください。）
2. (I) A type of threat action that causes a system component to perform a function or service that is detrimental to system security. (See: usurpation.) Usage: This type of threat action includes the following subtypes: - "Tampering": /misuse/ Deliberately altering a system's logic, data, or control information to cause the system to perform unauthorized functions or services. (See: corruption, main entry for "tampering".) - "Malicious logic": /misuse/ Any hardware, firmware, or software intentionally introduced into a system to perform or control execution of an unauthorized function or service. (See: corruption, incapacitation, main entry for "malicious logic", masquerade.) - "Violation of authorizations": Action by an entity that exceeds the entity's system privileges by executing an unauthorized function. (See: authorization.)
2.（i）システムコンポーネントがシステムセキュリティに有害である機能またはサービスを実行するための脅威アクションの種類。使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「改ざん」：/誤用/意図的にシステムのロジック、データ、または制御情報を変更して、システムに不正な機能またはサービスを実行させる。（汚職、「改ざん」の主なエントリー。） - 「悪意のあるロジック」：/誤用/任意のハードウェア、ファームウェア、またはソフトウェアは、意図的に、不正な機能またはサービスの実行を実行または制御するためにシステムに導入されます。（参照：破損、無益、「悪意のある論理」の主なエントリー、マスカレード） - 「承認の違反」：不正な機能を実行することで、エンティティのシステム権限を超えるエンティティによるアクション。（承認を参照してください。）
$ misuse detection (I) An intrusion detection method that is based on rules that specify system events, sequences of events, or observable properties of a system that are believed to be symptomatic of security incidents. (See: IDS, misuse. Compare: anomaly detection.)
$ 誤用検出（i）システムイベント、イベントのシーケンス、またはセキュリティインシデントの症状であると考えられるシステムの観察可能なプロパティを指定する規則に基づく侵入検知方法。（IDS、誤用。比較：異常検出を参照してください。）
$ MLS (I) See: multilevel secure
$ MLS（i）：Multilevel Secure.
$ mobile code 1a. (I) Software that originates from a remote server, is transmitted across a network, and is loaded onto and executed on a local client system without explicit initiation by the client's user and, in some cases, without that user's knowledge. (Compare: active content.)
$ モバイルコード1A。（i）リモートサーバから発生するソフトウェアは、ネットワークを介して送信され、クライアントのユーザによる明示的な開始なしで、そして場合によってはそのユーザの知識がなければ、ローカルクライアントシステム上でロードされ実行される。（比較：アクティブコンテンツ。）
Tutorial: One form of mobile code is active content in a file that is transferred across a network.
チュートリアル：1つの形式のモバイルコードは、ネットワーク間で転送されるファイル内のアクティブなコンテンツです。
1b. (O) /U.S. DoD/ "Software modules obtained from remote systems, transferred across a network, and then downloaded and executed on local systems without explicit installation or execution by the recipient." [JP1]
1b。（O）/U.S。リモートシステムから取得されたDOD /「ソフトウェアモジュールは、ネットワークを介して転送し、その後、受信者による明示的なインストールまたは実行なしでローカルシステムでダウンロードして実行しました。」[JP1]
2a. (O) /U.S. DoD/ Technology that enables the creation of executable information that can be delivered to an information system and directly executed on any hardware/software architecture that has an appropriate host execution environment.
2A。（O）/U.S。情報システムに配信できる実行可能情報の作成を可能にし、適切なホスト実行環境を持つ任意のハードウェア/ソフトウェアアーキテクチャで直接実行できるようにするDODテクノロジ。
2b. (O) "Programs (e.g., script, macro, or other portable instruction) that can be shipped unchanged to a heterogeneous collection of platforms and executed with identical semantics" [SP28]. (See: active content.)
2b。（O）プログラム（例えば、スクリプト、マクロ、またはその他の携帯用命令）は、プラットフォームの異種コレクションと同一のセマンティクスで実行されて実行することができるプログラム（SP28]。（検証コンテンツを参照してください。）
Tutorial: Mobile code might be malicious. Using techniques such as "code signing" and a "sandbox" can reduce the risks of receiving and executing mobile code.
チュートリアル：モバイルコードは悪意があるかもしれません。「コード署名」や「サンドボックス」などの手法を使用すると、モバイルコードの受信と実行のリスクを軽減できます。
$ mode $ mode of operation 1. (I) /cryptographic operation/ A technique for enhancing the effect of a cryptographic algorithm or adapting the algorithm for an application, such as applying a block cipher to a sequence of data blocks or a data stream. (See: CBC, CCM, CMAC, CFB, CTR, ECB, OFB.)
$ モード$動作モード1.（i）/暗号化操作/暗号化アルゴリズムの効果を高めるため、またはブロック暗号を一連のデータブロックまたはデータストリームに適用するなど、アプリケーションのアルゴリズムを適応させる技術。（CBC、CCM、CMAC、CFB、CTR、ECB、OFB）
2. (I) /system operation/ A type of security policy that states the range of classification levels of information that a system is permitted to handle and the range of clearances and authorizations of users who are permitted to access the system. (See: compartmented security mode, controlled security mode, dedicated security mode, multilevel security mode, partitioned security mode, system-high security mode. Compare: protection level.)
2. （i）/システム操作/システムが処理することが許可されている情報の分類レベルの範囲およびシステムにアクセスすることが許可されているユーザーのクリアランスおよび許可の範囲を記載するセキュリティポリシーの種類。（コンパートメントセキュリティモード、制御セキュリティモード、専用セキュリティモード、マルチレベルセキュリティモード、パーティションセキュリティモード、区分セキュリティモード、システムハイセキュリティモード。コンペア：保護レベル）
3. (I) /IKE/ IKE refers to its various types of ISAKMP-scripted exchanges of messages as "modes". Among these are the following: - "Main mode": One of IKE's two phase 1 modes. (See: ISAKMP.) - "Quick mode": IKE's only phase 2 mode. (See: ISAKMP.)
3. （i）/ IKE / IKEは、その様々なタイプのISAKMPスクリプトメッセージのメッセージの「モード」として指します。これらの中には、次のものがあります。 - 「メインモード」：IKEの2フェーズ1モードの1つ。（isakmp。） - "クイックモード"：IKEの唯一のフェーズ2モード。（参照：ISAKMP）
$ model See: formal model, security model.
$ モデル：正式モデル、セキュリティモデル。
$ modulus (I) The defining constant in modular arithmetic, and usually a part of the public key in asymmetric cryptography that is based on modular arithmetic. (See: Diffie-Hellman-Merkle, RSA.)
$ モジュラー算術演算における定数定義、通常はモジュラー算術に基づく非対称暗号化における公開鍵の一部。（参照：Diffie-Hellman-Merkle、RSA。）
$ Mondex (O) A smartcard-based electronic money system that incorporates cryptography and can be used to make payments via the Internet. (See: IOTP.)
$ Mondex（O）暗号化を組み込んで、インターネットを介して支払いをするために使用することができるスマートカードベースの電子マネーシステム。（参照：iotp。）
$ Morris Worm (I) A worm program that flooded the ARPANET in November 1988, causing problems for thousands of hosts. [R1135] (See: community risk, worm)
$ Morris Worm（i）1988年11月にアルパネに浸水したウォームプログラムで、何千ものホストに問題が発生しました。[R1135]（参照：コミュニティリスク、ワーム）
$ MOSS (I) See: MIME Object Security Services.
$ MOSS（i）MIMEオブジェクトセキュリティサービスを参照してください。
$ MQV (N) A key-agreement protocol [Mene] that was proposed by A.J. Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the Diffie-Hellman-Merkle algorithm.
$ MQV（n）A.Jによって提案された契約契約プロトコル[Mene]1995年のMenezes、M. Qu、およびS.A.バンストーンおよびDiffie-Hellman-Merkleアルゴリズムに基づいています。
$ MSP (N) See: Message Security Protocol.
$ MSP（N）：メッセージセキュリティプロトコルを参照してください。
$ multicast security See: secure multicast
$ マルチキャストセキュリティ参照：セキュアマルチキャスト
$ Multics (N) MULTiplexed Information and Computing Service, an MLS computer timesharing system designed and implemented during 1965-69 by a consortium including Massachusetts Institute of Technology, General Electric, and Bell Laboratories, and later offered commercially by Honeywell.
$ Multics（n）多重化情報およびコンピューティングサービス、マサチューセッツ工業大学、一般的な電気、ベルラブラティト研究所を含むコンソーシアムによって設計および実施されたMLSコンピュータのタイムシェアシステム。
Tutorial: Multics was one of the first large, general-purpose, operating systems to include security as a primary goal from the inception of the design and development and was rated in TCSEC Class B2. Its many innovative hardware and software security mechanisms (e.g., protection ring) were adopted by later systems.
チュートリアル：Multicsは、設計と開発の開始からの主な目標としてセキュリティを含む最初の大規模で汎用のオペレーティングシステムの1つでした。そしてTCSECクラスB2で評価されました。その多くの革新的なハードウェアとソフトウェアセキュリティメカニズム（例えば保護リング）が後のシステムによって採用されました。
$ multilevel secure (MLS) (I) Describes an information system that is trusted to contain, and maintain separation between, resources (particularly stored data) of different security levels. (Examples: BLACKER, CANEWARE, KSOS, Multics, SCOMP.)
$ MultileVel Secure（MLS）（i）は、さまざまなセキュリティレベルのリソース（特に格納されたデータ）を含むと信頼されている情報システムを説明しています。（例：ブラック、カヌワレ、KSO、マルチス、SCOMP）
Usage: Usually understood to mean that the system permits concurrent access by users who differ in their access authorizations, while denying users access to resources for which they lack authorization.
使用法：通常、システムがアクセス許可が異なるユーザーによる同時アクセスを許可し、ユーザーが許可を欠いているリソースへのアクセスを拒否することを意味すると理解されていました。
$ multilevel security mode 1. (N) A mode of system operation wherein (a) two or more security levels of information are allowed to be to be handled concurrently within the same system when some users having access to the system have neither a security clearance nor need-to-know for some of the data handled by the system and (b) separation of the users and the classified material on the basis, respectively, of clearance and classification level are dependent on operating system control. (See: /system operation/ under "mode", need to know, protection level, security clearance. Compare: controlled mode.) Usage: Usually abbreviated as "multilevel mode". This term was defined in U.S. Government policy regarding system accreditation, but the term is also used outside the Government.
$ MULTILEVELセキュリティモード1.（a）システムにアクセスできるユーザーがセキュリティクリアランスも持たない場合は、（a）システムの2つ以上のセキュリティレベルの情報を同時に処理することができます。システムによって処理されたデータのいくつかについても（b）クリアランスおよび分類レベルの一部のデータの分離は、オペレーティングシステムの制御に依存しています。（/システム操作/「モード」の「モード」、保護レベル、セキュリティクリアランス。比較：制御モード。）使用法：通常「マルチレベルモード」と略記します。この用語はシステム認定に関する米国政府政策において定義されていましたが、この用語は政府外でも使用されています。
2. (O) A mode of system operation in which all three of the following statements are true: (a) Some authorized users do not have a security clearance for all the information handled in the system. (b) All authorized users have the proper security clearance and appropriate specific access approval for the information to which they have access. (c) All authorized users have a need-to-know only for information to which they have access. [C4009] (See: formal access approval, protection level.)
2. （o）次の3つのステートメントのうちの3つすべてが当てはまるシステム操作のモード（a）一部の許可ユーザーは、システム内で処理されているすべての情報に対してセキュリティクリアランスを持たない。（b）許可されたすべてのユーザーは、アクセス権がある情報について適切なセキュリティクリアランスと適切な特定のアクセス承認を得ています。（c）許可されたユーザーはすべてアクセスできる情報のみが必要です。[C4009]（「正式なアクセス承認、保護レベル」を参照）
$ Multipurpose Internet Mail Extensions (MIME) (I) An Internet protocol (RFC 2045) that enhances the basic format of Internet electronic mail messages (RFC 822) (a) to enable character sets other than U.S. ASCII to be used for textual headers and content and (b) to carry non-textual and multi-part content. (See: S/MIME.)
$ 多目的インターネットメール拡張（MIME）（i）インターネット電子メールメッセージの基本フォーマット（RFC 822）（a）を有効にするインターネットプロトコル（RFC 822）（a）テキストヘッダやコンテンツに使用するためのASCII以外の文字セットを有効にする（b）非テキストでマルチパートの内容を搬送する。（S / MIMEを参照してください。）
$ mutual suspicion (I) The state that exists between two interacting system entities in which neither entity can trust the other to function correctly with regard to some security requirement.
$ 相互疑い（i）2つの対話型システムエンティティ間に存在する状態は、セキュリティ要件に関して他のエンティティも正しく機能することができる。
$ name (I) Synonym for "identifier".
$ 名前（i） "識別子"の同義語。
$ naming authority (O) /U.S. DoD/ An organizational entity responsible for assigning DNs and for assuring that each DN is meaningful and unique within its domain. [DoD9]
$ 命名権限（O）/U.S。DOD / DNSの割り当てを担当し、各DNがそのドメイン内で意味のある独自のものであることを担当する組織エンティティ。[DOD9]
$ National Computer Security Center (NCSC) (O) A U.S. DoD organization, housed in NSA, that has responsibility for encouraging widespread availability of trusted systems throughout the U.S. Federal Government. It has established criteria for, and performed evaluations of, computer and network systems that have a TCB. (See: Rainbow Series, TCSEC.)
$ National Computer Security Center（NCSC）（O）NSAに収容されている米国のDOD組織で、米国連邦政府全体で信頼できるシステムの広範な在庫状況を奨励する責任があります。TCBを持つコンピュータシステムとネットワークシステムの評価を確立しました。（：Rainbow Series、TCSEC。）
$ National Information Assurance Partnership (NIAP) (N) A joint initiative of NIST and NSA to enhance the quality of commercial products for information security and increase consumer confidence in those products through objective evaluation and testing methods.
$ 国家情報保証パートナーシップ（NIAP）（N）情報セキュリティのための商品の品質を高め、客観的な評価とテスト方法を通じて消費者の信頼を高めるためのNSAとNSAの共同イニシアチブ。
Tutorial: NIAP is registered, through the U.S. DoD, as a National Performance Review Reinvention Laboratory. NIAP functions include the following: - Developing tests, test methods, and other tools that developers and testing laboratories may use to improve and evaluate security products. - Collaborating with industry and others on research and testing programs. - Using the Common Criteria to develop protection profiles and associated test sets for security products and systems. - Cooperating with the NIST National Voluntary Laboratory Accreditation Program to develop a program to accredit private-sector laboratories for the testing of information security products using the Common Criteria. - Working to establish a formal, international mutual recognition scheme for a Common Criteria-based evaluation.
チュートリアル：NIAPは、米国のDODを通じて、国家業績評価革新検査室として登録されています。NIAP機能には、次のものがあります。 - 開発テスト、テスト方法、および開発者およびテスト技術者がセキュリティ製品を改善し評価するために使用できるようにすることができる。 - 研究や試験プログラムに関する業界やその他の協力。 - セキュリティ製品およびシステムの保護プロファイルと関連テストセットを開発するための一般的な基準を使用します。 - 一般的な基準を使用して情報セキュリティ製品をテストするための民間部品研究所を認定するためのプログラムを開発するためのNIST National Voluntary Laboratory Accreditationプログラムと協力します。 - 一般的な基準に基づく評価のための正式な国際的な相互認識スキームを確立すること。
$ National Institute of Standards and Technology (NIST) (N) A U.S. Department of Commerce organization that promotes U.S. economic growth by working with industry to develop and apply technology, measurements, and standards. Has primary U.S. Government responsibility for INFOSEC standards for sensitive unclassified information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, NSA.)
$ 国立標準技術研究所（NIST）（NS）（N）米国の経済成長を推進する商務省統合学科、技術、測定、および規格を開発および適用する。敏感な未分類情報のためのInfoSec規格に対する主要な米国政府の責任があります。（ANSI、DES、DSA、DSS、FIPS、NIAP、NSA）
$ National Reliability and Interoperability Council (NRIC) (N) An advisory committee chartered by the U.S. Federal Communications Commission (FCC), with participation by network service providers and vendors, to provide recommendations to the FCC for assuring reliability, interoperability, robustness, and security of wireless, wireline, satellite, cable, and public data communication networks.
$ 国家信頼性と相互運用審議会（NRIC）（N）（N）米国連邦通信委員会（FCC）が傭し、ネットワークサービスプロバイダーとベンダーによる参加により、信頼性、相互運用性、堅牢性、およびセキュリティを保証するためのFCCへの推奨事項を提供する。無線、有線、衛星、ケーブル、および公共データ通信ネットワークの。
$ national security (O) /U.S. Government/ The national defense or foreign relations of the United States of America.
$ 国家安全保障（O）/U.S。政府/アメリカ合衆国の国家防衛または外交関係。
$ National Security Agency (NSA) (N) A U.S. DoD organization that has primary U.S. Government responsibility for INFOSEC standards for classified information and for sensitive unclassified information handled by national security systems. (See: FORTEZZA, KEA, MISSI, national security system, NIAP, NIST, SKIPJACK.)
$ 国家セキュリティエージェンシー（NSA）（N）分類された情報のためのINFOSEC規格および国家セキュリティシステムによって処理される敏感な未分類の情報に対する主要な米国政府の責任を持つ米国のDOD組織。（：Fortezza、Kea、Missi、National Security System、NIAP、NIST、Skipjack。）
$ national security information (O) /U.S. Government/ Information that has been determined, pursuant to Executive Order 12958 or any predecessor order, to require protection against unauthorized disclosure. [C4009]
$ 国家セキュリティ情報（O）/U.S。政府/執行命令12958またはあらゆる事前命令に従って、不正な開示に対する保護を必要とするために決定された政府/情報。[C4009]
$ national security system (O) /U.S. Government/ Any Government-operated information system for which the function, operation, or use (a) involves intelligence activities; (b) involves cryptologic activities related to national security; (c) involves command and control of military forces; (d) involves equipment that is an integral part of a weapon or weapon system; or (e) is critical to the direct fulfillment of military or intelligence missions and does not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). [Title 40 U.S.C. Section 1552, Information Technology Management Reform Act of 1996.] (See: type 2 product.)
$ 国家セキュリティシステム（O）/U.S。政府/機能、運用、または使用（A）がインテリジェンス活動を含む政府運営情報システム。（b）国家安全保障に関連する暗号学的活動を含む。（c）軍事力の指揮と管理を含む。（d）武器または武器システムの不可欠な部分である機器を含む。または（e）は軍事または知性任務の直接履行にとって重要であり、日常的な行政およびビジネスアプリケーション（給与計算、財務、物流、および人事管理アプリケーションを含む）に使用されるシステムを含まない。[タイトル40米国米国1996年の情報技術管理改革法第1552条（2つの製品を参照）
$ natural disaster (I) /threat action/ See: secondary definitions under "corruption" and "incapacitation".
$ Natural Disaster（I）/脅威の対応/参照：「破損」および「無能」の下の二次定義。
$ NCSC (O) See: National Computer Security Center.
$ NCSC（O）国立コンピュータセキュリティセンターを参照してください。
$ need to know, need-to-know (I) The necessity for access to, knowledge of, or possession of specific information required to carry out official duties.
$ 公式の義務を実行するために必要な特定の情報のアクセス、知識、または所有権へのアクセス、知識、または所有の必要性を知る必要があります。
Usage: The compound "need-to-know" is commonly used as either an adjective or a noun.
使用法：「知識が必要」とは、形容詞または名詞として一般的に使用されています。
Tutorial: The need-to-know criterion is used in security procedures that require a custodian of sensitive information, prior to disclosing the information to someone else, to establish that the intended recipient has proper authorization to access the information.
チュートリアル：必要な受信者が情報にアクセスするための適切な許可を有することを確立するために、情報を他の人に開示することを目的としている、受信者が他の人に情報を開示する前に、受信者の管理者を必要とするセキュリティ手順で使用されます。
$ network (I) An information system comprised of a collection of interconnected nodes. (See: computer network.)
$ ネットワーク（i）相互接続されたノードの集合からなる情報システム。（コンピュータネットワークを参照してください。）
$ Network Hardware Layer (I) See: Internet Protocol Suite.
$ ネットワークハードウェアレイヤ（i）インターネットプロトコルスイートを参照してください。
$ Network Interface Layer (I) See: Internet Protocol Suite.
$ ネットワークインタフェースレイヤ（i）インターネットプロトコルスイートを参照してください。
$ Network Layer Security Protocol (NLSP). (N) An OSI protocol (IS0 11577) for end-to-end encryption services at the top of OSIRM Layer 3. NLSP is derived from SP3 but is more complex. (Compare: IPsec.)
$ ネットワークレイヤセキュリティプロトコル（NLSP）。（n）OSIRMレイヤ3の上部のエンドツーエンド暗号化サービスのOSIプロトコル（IS0 11577）は、NLSPから導出されますが、複雑です。（比較：IPSEC。）
$ Network Substrate Layer (I) Synonym for "Network Hardware Layer".
$ ネットワーク基板レイヤ（Iネットワークハードウェアレイヤー "の同義語。
$ network weaving (I) A penetration technique in which an intruder avoids detection and traceback by using multiple, linked, communication networks to access and attack a system. [C4009]
$ ネットワーク製織（i）侵入者が複数のリンクされた通信ネットワークを使用してシステムを攻撃して攻撃することによって、侵入者が検出およびトレースバックを回避する侵入技術。[C4009]
$ NIAP (N) See: National Information Assurance Partnership.
$ NIAP（N）参照：国家情報保証パートナーシップ。
$ nibble (D) Half of a byte (i.e., usually, 4 bits).
$ ニブル（D）バイトの半分（すなわち、通常4ビット）。
Deprecated Term: To avoid international misunderstanding, IDOCs SHOULD NOT use this term; instead, state the size of the block explicitly (e.g., "4-bit block"). (See: Deprecated Usage under "Green Book".)
廃止予定の期間：国際誤解を避けるために、IDocはこの用語を使用しないでください。代わりに、ブロックのサイズを明示的に述べます（例えば、 "4ビットブロック"）。（「グリーンブック」の「廃止予定の使用」。）
$ NIPRNET (O) The U.S. DoD's common-use Non-Classified Internet Protocol Router Network; the part of the Internet that is wholly controlled by the U.S. DoD and is used for official DoD business.
$ NIPRNET（O）米国のDODの共用されていないインターネットプロトコルルータネットワーク。インターネットの一部は、米国のDODによって完全に管理されており、公式のDoD事業に使用されます。
$ NIST (N) See: National Institute of Standards and Technology.
$ NIST（N）は、国立標準化学技術研究所を参照してください。
$ NLSP (N) See: Network Layer Security Protocol
$ NLSP（N）参照：ネットワークレイヤセキュリティプロトコル
$ no-lone zone (I) A room or other space or area to which no person may have unaccompanied access and that, when occupied, is required to be occupied by two or more appropriately authorized persons. [C4009] (See: dual control.)
$ 孤独なゾーン（i）人がいないようなアクセスが不可能である可能性がある部屋またはその他のスペースまたはその分野、占有されている場合は、2つ以上の適切な承認された人によって占有される必要があります。[C4009]（DUAL制御を参照）
$ no-PIN ORA (NORA) (O) /MISSI/ An organizational RA that operates in a mode in which the ORA performs no card management functions and, therefore, does not require knowledge of either the SSO PIN or user PIN for an end user's FORTEZZA PC card.
$ ORA（ORA）/ MISSI / ORAがカード管理機能を実行しないモードで動作する組織RAは、エンドユーザーのSSOピンまたはユーザーピンの知識を必要としません。Fortezza PCカード。
$ node (I) A collection of related subsystems located on one or more computer platforms at a single site. (See: site.)
$ ノード（i）1つのサイトで1つ以上のコンピュータプラットフォーム上にある関連サブシステムのコレクション。（サイトを参照してください。）
$ nonce (I) A random or non-repeating value that is included in data exchanged by a protocol, usually for the purpose of guaranteeing liveness and thus detecting and protecting against replay attacks. (See: fresh.)
$ nonce（i）プロトコルによって交換されるデータに含まれるランダムまたは非繰り返し値は、通常、活性を保証し、再生攻撃から検出および保護するために。（「新鮮」を参照してください。）
$ non-critical See: critical.
$ 重要ではない参照：重要です。
$ non-repudiation service 1. (I) A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data). (See: repudiation, time stamp.)
$ 非否認サービス1.（i）協会への関与の関与拒否を保護するセキュリティサービス（特にデータを転送する通信協会）。（否定、タイムスタンプを参照してください。）
Tutorial: Two separate types of denial are possible -- an entity can deny that it sent a data object, or it can deny that it received a data object -- and, therefore, two separate types of non-repudiation service are possible. (See: non-repudiation with proof of origin, non-repudiation with proof of receipt.)
チュートリアル：2つの別々のタイプの否定が可能です。エンティティはデータオブジェクトを送信したことを否定することも、データオブジェクトを受信したことを拒否できます。したがって、2つの別々のタイプの非和解サービスが可能です。（起源の証明による非否認、領収書の証明による否認防止。）
2. (D) "Assurance [that] the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data." [C4009]
2. （d）「保証」データの送付者は配達証明を提供し、受信者は送信者の身元の証明を備えているので、データを処理したことはありません。」[C4009]
Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it bundles two security services -- non-repudiation with proof of origin, and non-repudiation with proof of receipt -- that can be provided independently of each other.
非推奨の定義：IDOCは定義2を使用しないでください。
Usage: IDOCs SHOULD distinguish between the technical aspects and the legal aspects of a non-repudiation service: - "Technical non-repudiation": Refers to the assurance a relying party has that if a public key is used to validate a digital signature, then that signature had to have been made by the corresponding private signature key. [SP32] - "Legal non-repudiation": Refers to how well possession or control of the private signature key can be established. [SP32]
使用法：IDOCは技術的側面と否認防止サービスの法的側面を区別する必要があります。 - 「技術的な否認」：信頼当事者が信頼当事者がデジタル署名を検証するために使用されていることを持っているという保証を参照している。その署名は対応する個人署名鍵によって行われなければならなかった。[SP32] - 「法的な否認禁止」：民間署名鍵の所持または管理をどの程度確立できるかを指します。[SP32]
Tutorial: Non-repudiation service does not prevent an entity from repudiating a communication. Instead, the service provides evidence that can be stored and later presented to a third party to resolve disputes that arise if and when a communication is repudiated by one of the entities involved.
チュートリアル：否認防止サービスは、エンティティが通信を拒否するのを妨げません。代わりに、このサービスは、コミュニケーションが関与する企業の1つによって繰り返しされている場合、および通信が繰り返しされている場合、および通信が発生した場合、およびその後の紛争を解決するための第三者に保存されて提示されることができる証拠を提供する。
Ford describes the six phases of a complete non-repudiation service and uses "critical action" to refer to the act of communication that is the subject of the service [For94, For97]:
Fordは完全な非否認サービスの6つのフェーズを説明し、サービスの主題であるコミュニケーションの行為を指す[For94、97]：
-------- -------- -------- -------- -------- . --------
Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6:
Request Generate Transfer Verify Retain . Resolve
Service Evidence Evidence Evidence Evidence . Dispute
-------- -------- -------- -------- -------- . --------
Service Critical Evidence Evidence Archive . Evidence
Request => Action => Stored => Is => Evidence . Is
Is Made Occurs For Later Tested In Case . Verified
and Use | ^ Critical . ^
Evidence v | Action Is . |
Is +-------------------+ Repudiated . |
Generated |Verifiable Evidence|------> ... . ----+
+-------------------+
Phase / Explanation
-------------------
1. Request service: Before the critical action, the service
requester asks, either implicitly or explicitly, to have
evidence of the action be generated.
2. Generate evidence: When the critical action occurs, evidence is
generated by a process involving the potential repudiator and
possibly also a trusted third party.
3. Transfer evidence: The evidence is transferred to the requester
or stored by a third party, for later use (if needed).
4. Verify evidence: The entity that holds the evidence tests it to
be sure that it will suffice if a dispute arises.
5. Retain evidence: The evidence is retained for possible future
retrieval and use.
6. Resolve dispute: In this phase, which occurs only if the
critical action is repudiated, the evidence is retrieved from
storage, presented, and verified to resolve the dispute.
$ non-repudiation with proof of origin (I) A security service that provides the recipient of data with evidence that proves the origin of the data, and thus protects the recipient against an attempt by the originator to falsely deny sending the data. (See: non-repudiation service.)
$ 原点の証明による否認（i）データの原点を証明する証拠を持つデータの受信者を提供するセキュリティサービスであるため、発信者がデータの送信を誤って拒否するために受信者を保護します。（否認防止サービスを参照してください。）
Tutorial: This service is a strong version of data origin authentication service. This service can not only verify the identity of a system entity that is the original source of received data; it can also provide proof of that identity to a third party.
チュートリアル：このサービスは、データオリジナル認証サービスの強力なバージョンです。このサービスは、元の受信データのソースであるシステムエンティティのIDを検証することはできません。それは第三者にその身元の証明を提供することができます。
$ non-repudiation with proof of receipt (I) A security service that provides the originator of data with evidence that proves the data was received as addressed, and thus protects the originator against an attempt by the recipient to falsely deny receiving the data. (See: non-repudiation service.)
$ 領収書の証明による非否認（i）データの出所を証明証明する証明書をアドレス指定された証拠を提供するセキュリティサービスを提供し、したがって受信者がデータの受信を誤って拒否する試みに対して発信者を保護します。（否認防止サービスを参照してください。）
$ non-volatile media (I) Storage media that, once written into, provide stable storage of information without an external power supply. (Compare: permanent storage, volatile media.)
$ 不揮発性媒体（i）記憶媒体は、一度書き込まれ、外部電源なしで安定した情報を保存する。（比較：恒久的な貯蔵、揮発性媒体。）
$ NORA (O) See: no-PIN ORA.
$ NORA（O）は、ノーピンORAを参照してください。
$ notarization (I) Registration of data under the authority or in the care of a trusted third party, thus making it possible to provide subsequent assurance of the accuracy of characteristics claimed for the data, such as content, origin, time of existence, and delivery. [I7498-2] (See: digital notary.)
$ 公証（i）権限または信頼できる第三者の世話の下でのデータの登録、したがって、コンテンツ、起源、存在時間、配達などのデータに関連する特性の精度の後続の保証を提供することを可能にします。。[I7498-2]（「デジタル名称」を参照）
$ NRIC (N) See: Network Reliability and Interoperability Council.
$ NRIC（N）：ネットワークの信頼性と相互運用性理事会。
$ NSA (N) See: National Security Agency
$ NSA（N）参照：国家セキュリティエージェンシー
$ null (N) /encryption/ "Dummy letter, letter symbol, or code group inserted into an encrypted message to delay or prevent its decryption or to complete encrypted groups for transmission or transmission security purposes." [C4009]
$ NULL（N）/暗号化/「ダミー文字、文字記号、またはコードグループは、暗号化されたメッセージに挿入されたコードグループ、またはその復号化を遅らせるか、送信または送信のセキュリティ目的で暗号化されたグループを完成させる。」[C4009]
$ NULL encryption algorithm (I) An algorithm [R2410] that is specified as doing nothing to transform plaintext data; i.e., a no-op. It originated because ESP always specifies the use of an encryption algorithm for confidentiality. The NULL encryption algorithm is a convenient way to represent the option of not applying encryption in ESP (or in any other context where a no-op is needed). (Compare: null.)
$ NULL暗号化アルゴリズム（i）平文データを変換するために何もしないように指定されているアルゴリズム[R2410]。すなわち、NOOP。ESPは常に機密性のための暗号化アルゴリズムの使用を指定しているために発生しました。NULL暗号化アルゴリズムは、ESP（またはNO-OPが必要な他のコンテキストで）暗号化を適用しないオプションを表す便利な方法です。（比較：NULL。）
$ OAKLEY (I) A key establishment protocol (proposed for IPsec but superseded by IKE) based on the Diffie-Hellman-Merkle algorithm and designed to be a compatible component of ISAKMP. [R2412]
$ Oakley（i）Diffie-Hellman-Merkleアルゴリズムに基づいて、ISAKMPの互換性のあるコンポーネントになるように設計されている重要な設立プロトコル（IPsecのために提案されているがIKEに置き換えられた）。[R2412]
Tutorial: OAKLEY establishes a shared key with an assigned identifier and associated authenticated identities for parties;
チュートリアル：Oakleyは、割り当てられた識別子と政党の認証された認証されたIDを持つ共有キーを確立します。
i.e., OAKLEY provides authentication service to ensure the entities of each other's identity, even if the Diffie-Hellman-Merkle exchange is threatened by active wiretapping. Also, it provides public-key forward secrecy for the shared key and supports key updates, incorporation of keys distributed by out-of-band mechanisms, and user-defined abstract group structures for use with Diffie-Hellman-Merkle.
すなわち、オークリーは、Diffie-Hellman-Merkle交換がアクティブな盗聴によって脅かされていても、互いのアイデンティティのエンティティを確保するための認証サービスを提供します。また、共有鍵の公開鍵の秘密を提供し、鍵の更新、帯域外のメカニズムによって配布されたキーの組み込み、およびDiffie-Hellman-Merkleで使用するためのユーザー定義の抽象グループ構造をサポートしています。
$ object (I) /formal model/ Trusted-system modeling usage: A system component that contains or receives information. (See: Bell-LaPadula model, object reuse, trusted system.)
$ オブジェクト（I）/正式モデル/信頼済システムモデリング使用法：情報を含むシステムコンポーネント。（「ベルラップラドゥラモデル、オブジェクトの再利用、信頼できるシステム」を参照）
$ object identifier (OID) 1. (N) An official, globally unique name for a thing, written as a sequence of integers (which are formed and assigned as defined in the ASN.1 standard) and used to reference the thing in abstract specifications and during negotiation of security services in a protocol.
$ オブジェクト識別子（OID）1。（n）整数のシーケンスとして書かれた（これは、ASN.1規格で定義されていると割り当てられているもの）、抽象仕様のものを参照するために使用されるものの正式なグローバルなユニークな名前。プロトコルにおけるセキュリティサービスの交渉中。
2. (O) "A value (distinguishable from all other such values) [that] is associated with an object." [X680]
2. （O） "の値（他のすべてのそのような値と区別できます）[それがオブジェクトに関連付けられています。"[x680]
Tutorial: Objects named by OIDs are leaves of the object identifier tree (which is similar to but different from the X.500 Directory Information Tree). Each arc (i.e., each branch of the tree) is labeled with a non-negative integer. An OID is the sequence of integers on the path leading from the root of the tree to a named object.
チュートリアル：OIDによって指定されたオブジェクトは、オブジェクト識別子ツリー（X.500ディレクトリ情報ツリーと似ています）の葉です。各アーク（すなわち、ツリーの各分岐）は、負の負の整数でラベル付けされています。OIDは、ツリーのルートから指定されたオブジェクトへのパス上の整数のシーケンスです。
The OID tree has three arcs immediately below the root: {0} for use by ITU-T, {1} for use by ISO, and {2} for use by both jointly. Below ITU-T are four arcs, where {0 0} is for ITU-T recommendations. Below {0 0} are 26 arcs, one for each series of recommendations starting with the letters A to Z, and below these are arcs for each recommendation. Thus, the OID for ITU-T Recommendation X.509 is {0 0 24 509}. Below ISO are four arcs, where {1 0 }is for ISO standards, and below these are arcs for each ISO standard. Thus, the OID for ISO/IEC 9594-8 (the ISO number for X.509) is {1 0 9594 8}.
OIDツリーには、rootの3つのアークがあります。ITU-Tの下には4つの円弧があります。ここで、{0}はITU-Tの推奨事項用です。{0 0}以下は26円弧で、文字AからZまで始まる各一連の推奨数は、推奨事項ごとにアークです。したがって、ITU-T勧告X.509のOIDは{0 0 24 509}です。ISOの下には4つの円弧があります。ここで、{1 0}はISO規格用であり、これらはISO規格のアークです。したがって、ISO / IEC 9594-8のOID（X.509のISO番号）は{1 0 9594 8}です。
ANSI registers organization names below the branch {joint-iso-ccitt(2) country(16) US(840) organization(1) gov(101) csor(3)}. The NIST CSOR records PKI objects below the branch {joint-iso-itu-t(2) country(16) us(840) organization (1) gov(101) csor(3)}. The U.S. DoD registers INFOSEC objects below the branch {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1)}.
ANSIは支店の下の組織名を登録します。{共同ISO-CCITT（2）国（16）US（840）組織（1）gov（101）CSOR（3）}。NIST CSORは、支店の下にPKIオブジェクトを記録します。{共同ISO-ITU-T（2）国（16）US（840）組織（1）GOV（101）CSOR（3）}。米国のDODは、BRANCHの下にあるInfoSecオブジェクトをレジスタ登録します。{共同ISO-ITU-T（2）国（16）US（840）組織（1）GOV（101）DOD（2）INFOSEC（1）}。
The IETF's Public-Key Infrastructure (pkix) Working Group
registers PKI objects below the branch {iso(1) identified-
organization(3) dod(6) internet(1) security(5) mechanisms(5)
pkix(7)}. [R3280]
$ object reuse (N) /COMPUSEC/ Reassignment and reuse of an area of a storage medium (e.g., random-access memory, floppy disk, magnetic tape) that once contained sensitive data objects. Before being reassigned for use by a new subject, the area needs to be erased or, in some cases, purged. [NCS04] (See: object.)
$ オブジェクト再利用（n）/ compusec / compusec / compusec / compusec / compusec / compusec / compusec / reusement（例えば、ランダムアクセスメモリ、フロッピーディスク、磁気テープ）が、かつて機密データオブジェクトを含んでいた。新しい件名で使用するために再割り当てされる前に、この地域を消去する必要があるか、または場合によっては消去される必要があります。[NCS04]（オブジェクトを参照）
$ obstruction (I) A type of threat action that interrupts delivery of system services by hindering system operations. (See: disruption.)
$ 障害物（i）システム操作を妨げることによってシステムサービスの配信を中断する一種の脅威アクション。（混乱を参照してください。）
Tutorial: This type of threat action includes the following subtypes: - "Interference": Disruption of system operations by blocking communication of user data or control information. (See: jamming.) - "Overload": Hindrance of system operation by placing excess burden on the performance capabilities of a system component. (See: flooding.)
チュートリアル：このタイプの脅威アクションには、次のサブタイプが含まれています。 - 「干渉」：ユーザーデータの通信をブロックすることによるシステム操作の中断。（注意を参照してください。） - 「過負荷」：システムコンポーネントのパフォーマンス能力に過剰な負担をかけることでシステム操作の妨げます。（洪水を参照してください。）
$ OCSP (I) See: Online Certificate Status Protocol.
$ OCSP（i）：オンライン証明書ステータスプロトコルを参照してください。
$ octet (I) A data unit of eight bits. (Compare: byte.)
$ オクテット（i）8ビットのデータユニット。（比較：バイト）
Usage: This term is used in networking (especially in OSI standards) in preference to "byte", because some systems use "byte" for data storage units of a size other than eight bits.
使用法：この用語は、一部のシステムが8ビット以外のサイズのデータ記憶単位に「バイト」を使用するため、「バイト」を好み、ネットワーク（特にOSI標準）で使用されます。
$ OFB (N) See: output feedback.
$ OFB（n）出力フィードバックを参照してください。
$ off-line attack (I) See: secondary definition under "attack".
$ オフライン攻撃（i）「攻撃」の下の二次定義を参照してください。
$ ohnosecond (D) That minuscule fraction of time in which you realize that your private key has been compromised.
$ ohnosecond（d）あなたがあなたの秘密鍵が危険にさらされていることに気づく時間の割合の分数。
Deprecated Usage: IDOCs SHOULD NOT use this term; it is a joke for English speakers. (See: Deprecated Usage under "Green Book".)
廃止予定の使用法：IDOCはこの用語を使用しないでください。英語のスピーカーの冗談です。（「グリーンブック」の「廃止予定の使用」。）
$ OID (N) See: object identifier.
$ OID（N）：オブジェクト識別子を参照してください。
$ Online Certificate Status Protocol (OCSP) (I) An Internet protocol [R2560] used by a client to obtain from a server the validity status and other information about a digital certificate. (Mentioned in [X509] but not specified there.)
$ オンライン証明書ステータスプロトコル（OCSP）（i）インターネットプロトコル[R2560]は、クライアントがサーバーから入手するために妥当性ステータスおよびその他の情報を取得するために使用されます。（[X509]に記載されていますが、そこには指定されていません。）
Tutorial: In some applications, such as those involving high-value commercial transactions, it may be necessary either (a) to obtain certificate revocation status that is timelier than is possible with CRLs or (b) to obtain other kinds of status information. OCSP may be used to determine the current revocation status of a digital certificate, in lieu of or as a supplement to checking against a periodic CRL. An OCSP client issues a status request to an OCSP server and suspends acceptance of the certificate in question until the server provides a response.
チュートリアル：高価値の取引を含むもののようなアプリケーションによっては、CRLSまたは（B）で可能な証明書失効状態を取得するために（A）、他の種類のステータス情報を取得する必要がある場合があります。OCSPは、デジタル証明書の現在の失効状態を決定するために、定期的なCRLをチェックするための補足として、またはその代金として決定することができます。OCSPクライアントはOCSPサーバーへのステータス要求を発行し、サーバーが応答を提供するまで、問題のある証明書の受け入れを中断します。
$ one-time pad 1. (N) A manual encryption system in the form of a paper pad for one-time use.
$ ワンタイムパッド1.（n）ワンタイム使用のための紙パッドの形の手動暗号化システム。
2. (I) An encryption algorithm in which the key is a random sequence of symbols and each symbol is used for encryption only one time -- i.e., used to encrypt only one plaintext symbol and thus produce only one ciphertext symbol -- and a copy of the key is used similarly for decryption.
2. （i）キーがランダムなシンボルシーケンスであり、各シンボルが1回だけ暗号化されている暗号化アルゴリズムを使用して、1つの平文シンボルのみを暗号化するために使用され、したがって1つの暗号文記号のみを生成するために使用される。キーは復号化のために同様に使用されます。
Tutorial: To ensure one-time use, the copy of the key used for encryption is destroyed after use, as is the copy used for decryption. This is the only encryption algorithm that is truly unbreakable, even given unlimited resources for cryptanalysis [Schn], but key management costs and synchronization problems make it impractical except in special situations.
チュートリアル：1回の使用を確実にするために、暗号化に使用されるキーのコピーは、復号化に使用されるコピーのように、使用後に破棄されます。これは、CryptanAlysisのための無制限のリソースでさえ、本当に壊れやすい唯一の暗号化アルゴリズムですが、重要な管理コストと同期の問題は、特別な状況を除いて非実用化されています。
$ one-time password, One-Time Password (OTP) 1. (I) /not capitalized/ A "one-time password" is a simple authentication technique in which each password is used only once as authentication information that verifies an identity. This technique counters the threat of a replay attack that uses passwords captured by wiretapping.
$ ワンタイムパスワード、ワンタイムパスワード（OTP）1。（i）/資本化されていない/「ワンタイムパスワード」は、各パスワードがアイデンティティを検証する認証情報として一度だけ使用される単純な認証手法です。この手法は、盗聴によってキャプチャされたパスワードを使用する再生攻撃の脅威をカウントします。
2. (I) /capitalized/ "One-Time Password" is an Internet protocol [R2289] that is based on S/KEY and uses a cryptographic hash function to generate one-time passwords for use as authentication information in system login and in other processes that need protection against replay attacks.
2. （i）/資本化/「ワンタイムパスワード」は、S / KEYに基づくインターネットプロトコル[R2289]で、システムログインおよび他のプロセスで認証情報として使用するための1回限りのパスワードを生成するための暗号化ハッシュ関数を使用します。それは再生攻撃に対する保護を必要とします。
$ one-way encryption (I) Irreversible transformation of plain text to cipher text, such that the plain text cannot be recovered from the cipher text by other than exhaustive procedures even if the cryptographic key is known. (See: brute force, encryption.)
$ 暗号化テキストを暗号化されたテキストから暗号化されたテキストを知らせても、暗号化テキストへの単語テキストへの表示テキストの不可逆的な変換。（参照：ブルートフォース、暗号化。）
$ one-way function (I) "A (mathematical) function, f, [that] is easy to compute, but which for a general value y in the range, it is computationally difficult to find a value x in the domain such that f(x) = y. There may be a few values of y for which finding x is not computationally difficult." [X509]
$ 一方向関数（i） "a（数学）関数f、算成が容易であるが、範囲内の一般値yに対して、fになるようにドメイン内の値xを見つけることは計算困難である。（x）= y。xの発見が計算困難ではないが、数のyの値が少ないかもしれません。」[X509]
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for "cryptographic hash".
廃止予定の使用法：IDocは、この用語を「暗号化ハッシュ」の同義語として使用しないでください。
$ onion routing (I) A system that can be used to provide both (a) data confidentiality and (b) traffic-flow confidentiality for network packets, and also provide (c) anonymity for the source of the packets.
$ タマネーションルーティング（i）ネットワークパケットのデータ機密性と（B）トラフィックフロー機密性の両方を提供するために使用できるシステムであり、パケットのソースの匿名性も提供します。
Tutorial: The source, instead of sending a packet directly to the intended destination, sends it to an "onion routing proxy" that builds an anonymous connection through several other "onion routers" to the destination. The proxy defines a route through the "onion routing network" by encapsulating the original payload in a layered data packet called an "onion", in which each layer defines the next hop in the route and each layer is also encrypted. Along the route, each onion router that receives the onion peels off one layer; decrypts that layer and reads from it the address of the next onion router on the route; pads the remaining onion to some constant size; and sends the padded onion to that next router.
チュートリアル：ソースは、パケットを意図した宛先に直接送信する代わりに、宛先に他のいくつかの「オニオンルータ」を介して匿名接続を構築する「オニオンルーティングプロキシ」に送信します。プロキシは、「オニオン」と呼ばれる階層化されたデータパケットで元のペイロードをカプセル化することによって、「オニオンルーティングネットワーク」を介して経路を定義し、各層は経路内のネクストホップを定義し、各層も暗号化される。その経路に沿って、タマネギを受信する各タマネーションルータは1つの層から剥離する。そのレイヤーを復号化し、そのルート上の次のタマネーションルータのアドレスを読み込みます。残りのタマネギを一定のサイズにパッドします。そしてその次のルータにパッド化されたタマネーションを送信します。
$ open security environment (O) /U.S. DoD/ A system environment that meets at least one of the following two conditions: (a) Application developers (including maintainers) do not have sufficient clearance or authorization to provide an acceptable presumption that they have not introduced malicious logic. (b) Configuration control does not provide sufficient assurance that applications and the equipment are protected against the introduction of malicious logic prior to and during the operation of system applications. [NCS04] (See: "first law" under "Courtney's laws". Compare: closed security environment.)
$ オープンセキュリティ環境（O）/U.S。DOD /次の2つの条件のうちの少なくとも1つを満たすシステム環境：（a）アプリケーション開発者（メンテナを含む）は、悪意のあるロジックを導入していないと認められない推定を提供するのに十分なクリアランスまたは承認を持っていない。（b）構成制御は、システムアプリケーションの動作前およびシステムアプリケーションの動作の前に、アプリケーションと機器が悪質なロジックの導入に対して保護されるのに十分な保証を提供していない。[NCS04]（「Courtney's Laws」の下の「最初の法律」。比較：クローズドセキュリティ環境。）
$ open storage (N) /U.S. Government/ "Storage of classified information within an accredited facility, but not in General Services Administration approved secure containers, while the facility is unoccupied by authorized personnel." [C4009]
$ 開いた保管（n）/u.s。政府/「認定施設内の分類された情報の保管は、施設は安全な容器を承認したが、施設は承認された担当者によって未占通的な容器ではありません。」[C4009]
$ Open Systems Interconnection (OSI) Reference Model (OSIRM) (N) A joint ISO/ITU-T standard [I7498-1] for a seven-layer, architectural communication framework for interconnection of computers in networks. (See: OSIRM Security Architecture. Compare: Internet Protocol Suite.)
$ Open Systems InterConnection（OSI）リファレンスモデル（OSIRM）（N）ネットワーク内のコンピュータの相互接続のための7層、アーキテクチャコミュニケーションフレームワークのための共同ISO / ITU-T標準[I7498-1]。（OSIRDセキュリティアーキテクチャを参照してください。比較：インターネットプロトコルスイート。）
Tutorial: OSIRM-based standards include communication protocols that are mostly incompatible with the IPS, but also include security models, such as X.509, that are used in the Internet.
チュートリアル：OSIRMベースの標準には、IPSとほとんど互換性がないが、インターネットで使用されているX.509などのセキュリティモデルも含まれます。
The OSIRM layers, from highest to lowest, are (7) Application, (6) Presentation, (5) Session, (4) Transport, (3) Network, (2) Data Link, and (1) Physical.
OSIRMレイヤーは、最高から最低まで、（7）アプリケーション、（6）プレゼンテーション、（5）セッション、（4）トランスポート、（3）ネットワーク、（2）データリンク、（1）物理的です。
Usage: This Glossary refers to OSIRM layers by number to avoid confusing them with IPS layers, which are referred to by name.
使用法：この用語集は、名前によって参照されるIPS層でそれらを混乱させることを避けるために、OSIRMレイヤーを参照します。
Some unknown person described how the OSIRM layers correspond to the seven deadly sins:
何人かの未知の人は、OSIRR層が7つの致命的な罪にどのように対応するかを説明しました。
7. Wrath: Application is always angry with the mess it sees below itself. (Hey! Who is it to be pointing fingers?) 6. Sloth: Presentation is too lazy to do anything productive by itself. 5. Lust: Session is always craving and demanding what truly belongs to Application's functionality. 4. Avarice: Transport wants all of the end-to-end functionality. (Of course, it deserves it, but life isn't fair.) 3. Gluttony: (Connection-Oriented) Network is overweight and overbearing after trying too often to eat Transport's lunch. 2. Envy: Poor Data Link is always starved for attention. (With Asynchronous Transfer Mode, maybe now it is feeling less neglected.) 1. Pride: Physical has managed to avoid much of the controversy, and nearly all of the embarrassment, suffered by the others.
7. 怒り：アプリケーションは常にそれがそれがそれ自体を見ている混乱に腹を立てています。（ねえ！それは指を指しているのですか？）6. Sloth：プレゼンテーションはそれ自身で生産的なことをするのは面倒です。5.欲望：セッションは常に絶え間なく、本当にアプリケーションの機能に属するものを求めています。4. Avarice：トランスポートは、すべてのエンドツーエンド機能を望んでいます。（もちろん、それはそれに値するが、人生は公正ではない。）3。gluttony :(接続指向）ネットワークは太りすぎで急降下しており、輸送の昼食を食べることを試みることが多すぎる。羨望：データリンクが常に注意のために飢えています。（非同期転送モードでは、今や無視されているように感じています。）1。誇り：物理的なものは、論争の大部分を避けることができ、ほぼすべての恥ずかしさが他の人に苦しんでいました。
John G. Fletcher described how the OSIRM layers correspond to Snow White's dwarf friends:
John G. Fletcherは、OSIRR層がSnow WhiteのDwarfの友達にどのように対応するかを説明しました。
7. Doc: Application acts as if it is in charge, but sometimes muddles its syntax.
7. Doc：アプリケーションが担当しているかのように機能しますが、時にはその構文を混乱させることがあります。
6. Sleepy: Presentation is indolent, being guilty of the sin of Sloth. 5. Dopey: Session is confused because its charter is not very clear. 4. Grumpy: Transport is irritated because Network has encroached on Transport's turf. 3. Happy: Network smiles for the same reason that Transport is irritated. 2. Sneezy: Data Link makes loud noises in the hope of attracting attention. 1. Bashful: Physical quietly does its work, unnoticed by the others.
6. 眠そう：プレゼンテーションは非難されており、スモの罪の罪の罪である。5. Dopey：そのチャーターがあまり明確ではないため、セッションは混乱しています。4.不機嫌そうな：ネットワークがトランスポートの芝生に侵入したため、輸送は刺激されています。3.幸せ：トランスポートがイライラされているのと同じ理由でネットワーク微笑みます。2.くしゃんき：データリンクは注目を集めることを期待して大きなノイズを作ります。1. Bashful：他の人によって気付かれていない仕事を静かにしています。
$ operational integrity (I) Synonym for "system integrity"; this synonym emphasizes the actual performance of system functions rather than just the ability to perform them.
$ 「システムの整合性」のための整合性（i）同義語。この同義語は、それらを実行する能力ではなく、システム関数の実際のパフォーマンスを強調しています。
$ operational security 1. (I) System capabilities, or performance of system functions, that are needed either (a) to securely manage a system or (b) to manage security features of a system. (Compare: operations security (OPSEC).)
$ 運用セキュリティ1.（i）システムのシステム機能、またはシステム機能の性能、またはシステムのセキュリティ機能を管理するための（a）のいずれか（a）のいずれか（a）が必要です。（比較：オペレーションセキュリティ（OPSEC））
Usage: IDOCs that use this term SHOULD state a definition because (a) the definition provided here is general and vague and (b) the term could easily be confused with "operations security", which is a different concept.
使用法：この用語を使用するIDocは、（a）ここで提供されている定義は一般的であいまいで（b）という用語は、「操作のセキュリティ」と簡単に混同することができます。
Tutorial: For example, in the context of an Internet service provider, the term could refer to capabilities to manage network devices in the event of attacks, simplify troubleshooting, keep track of events that affect system integrity, help analyze sources of attacks, and provide administrators with control over network addresses and protocols to help mitigate the most common attacks and exploits. [R3871]
チュートリアル：インターネットサービスプロバイダのコンテキストでは、攻撃が発生した場合はネットワークデバイスを管理する機能を参照し、トラブルシューティングを簡素化し、システムの整合性に影響を与えるイベントを追跡し、攻撃の発生源を分析して提供するのに役立ちます。ネットワークアドレスを制御する管理者は、最も一般的な攻撃と悪用を軽減するのに役立つプロトコルを備えています。[R3871]
2. (D) Synonym for "administrative security".
2. （d）「管理セキュリティ」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "administrative security". Any type of security may affect system operations; therefore, the term may be misleading. Instead, use "administrative security", "communication security", "computer security", "emanations security", "personnel security", "physical security", or whatever specific type is meant. (See: security architecture. Compare: operational integrity, OPSEC.)
廃止予定の定義：IDocは、この用語を「管理セキュリティ」の同義語として使用しないでください。任意の種類のセキュリティはシステム操作に影響を与える可能性があります。したがって、用語は誤解を招く可能性があります。代わりに、「管理セキュリティ」、「通信セキュリティ」、「コンピュータセキュリティ」、「エメテーションセキュリティ」、「人事セキュリティ」、「物理セキュリティ」、または特定の種類が何でも構いません。（セキュリティアーキテクチャを参照してください。比較：操作整合性、OPSEC）
$ operations security (OPSEC) (I) A process to identify, control, and protect evidence of the planning and execution of sensitive activities and operations, and thereby prevent potential adversaries from gaining knowledge of capabilities and intentions. (See: communications cover. Compare: operational security.)
$ オペレーションセキュリティ（OPSEC）（i）機密活動と業務の計画と実行の証拠を識別、制御、および保護するためのプロセスであり、それによって潜在的な敵対者が機能と意図の知識を得るのを防ぎます。（：通信カバー。比較：運用セキュリティ。）
$ operator (I) A person who has been authorized to direct selected functions of a system. (Compare: manager, user.)
$ 演算子（i）システムの選択された機能を指示することを許可されている人。（比較：マネージャー、ユーザー。）
Usage: IDOCs that use this term SHOULD state a definition for it because a system operator may or may not be treated as a "user".
使用法：この用語を使用するIDocは、システムオペレータが「ユーザー」として扱われる場合と扱われない可能性があるため、定義を定義します。
$ OPSEC 1. (I) Abbreviation for "operations security".
$ OPSEC 1.（i）「操作セキュリティ」の略語。
2. (D) Abbreviation for "operational security".
2. （d）「運用セキュリティ」の略語。
Deprecated Usage: IDOCs SHOULD NOT use this abbreviation for "operational security" (as defined in this Glossary), because its use for "operations security" has been well established for many years, particular in the military community.
廃止予定の使用法：IDOCは、「オペレーショナルセキュリティ」の「オペレーショナルセキュリティ」のために（この用語集で定義されているように）この略語を使用しないでください。
$ ORA See: organizational registration authority.
$ ORA参照：組織登録局。
$ Orange Book (D) /slang/ Synonym for "Trusted Computer System Evaluation Criteria" [CSC1, DoD1].
$ オレンジブック（D）/スラング/シノニム「信頼できるコンピュータシステム評価基準」[CSC1、DOD1]。
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for "Trusted Computer System Evaluation Criteria" [CSC1, DoD1]. Instead, use the full, proper name of the document or, in subsequent references, the abbreviation "TCSEC". (See: Deprecated Usage under "Green Book".)
廃止予定の使用法：IDocsは、この用語を「信頼できるコンピュータシステム評価基準」[CSC1、DOD1]の同義語として使用しないでください。代わりに、ドキュメントのフル、適切な名前、または後続の参照、略語 "TCSEC"を使用します。（「グリーンブック」の「廃止予定の使用」。）
$ organizational certificate 1. (I) An X.509 public-key certificate in which the "subject" field contains the name of an institution or set (e.g., a business, government, school, labor union, club, ethnic group, nationality, system, or group of individuals playing the same role), rather than the name of an individual person or device. (Compare: persona certificate, role certificate.)
$ 組織証明書1.（i）「件名」フィールドには、機関の名前やセットの名前が含まれているX.509公開鍵証明書（例えば、ビジネス、政府、学校、労働組合、クラブ、民族グループ、国籍、個人またはデバイスの名前ではなく、同じ役割を果たすシステム、または個人のグループ。（比較：Persona証明書、役割証明書。）
Tutorial: Such a certificate might be issued for one of the following purposes:
チュートリアル：そのような証明書は、次のいずれかの目的のために発行されるかもしれません：
- To enable an individual to prove membership in the organization. - To enable an individual to represent the organization, i.e., to act in its name and with its powers or permissions.
- 個人が組織内のメンバーシップを証明できるようにする。 - 個人が組織を表現すること、すなわちその名前で行動し、その権限または権限を与えることを可能にする。
2. (O) /MISSI/ A type of MISSI X.509 public-key certificate that is issued to support organizational message handling for the U.S. DoD's Defense Message System.
2. （O）/ MISSI /米国DODの防衛メッセージシステムの組織メッセージ処理をサポートするために発行された公開鍵証明書の種類。
$ organizational registration authority (ORA) 1. (I) /PKI/ An RA for an organization.
$ 組織登録局（ORA）1.（I）/ PKI /組織のRA。
2. (O) /MISSI/ An end entity that (a) assists a PCA, CA, or SCA to register other end entities, by gathering, verifying, and entering data and forwarding it to the signing authority and (b) may also assist with card management functions. An ORA is a local administrative authority, and the term refers both to the role and to the person who plays that role. An ORA does not sign certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user-PIN ORA.)
2. （O）/ MISSI /（A）データを収集、検証、および入力して署名権限に転送することで、PCA、CA、またはSCAが他のエンドエンティティを登録し、（B）に支援することができます。カード管理機能ORAは地元の行政権限であり、その用語はその役割とその役割を果たす人の両方を指します。ORAは証明書、CRLS、またはCKLSに署名しません。（参照：NoピンORA、SSOピンORA、ユーザーピンORA。）
$ origin authentication (D) Synonym for "data origin authentication". (See: authentication, data origin authentication.)
$ 原点認証（D）「データ発信認証」の同義語。（認証、データ原点認証を参照）
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of the internationally standardized term "data origin authentication" and also could be confused with "peer entity authentication."
廃止予定語：IDocsはこの用語を使用しないでください。国際的に標準化された用語「データ発信認証」の不注意な使用を示唆しており、「ピアエンティティ認証」と混同することもできます。
$ origin authenticity (D) Synonym for "data origin authentication". (See: authenticity, data origin authentication.)
$ Origin Authenticity（d）「データ発信認証」の同義語。（認証性、データ原点認証を参照）
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of the internationally standardized term "data origin authentication" and mixes concepts in a potentially misleading way.
廃止予定語：IDocsはこの用語を使用しないでください。それは国際的に標準化された用語「データ起源認証」の不注意な使用を示唆し、潜在的に誤解を招くような方法で概念を混在させることを示唆しています。
$ OSI, OSIRM (N) See: Open Systems Interconnection Reference Model.
$ OSI、OSIRR（N）参照：オープンシステム間インターコネースリファレンスモデル。
$ OSIRM Security Architecture (N) The part of the OSIRM [I7498-2] that specifies the security services and security mechanisms that can be applied to protect communications between two systems. (See: security architecture.) Tutorial: This part of the OSIRM includes an allocation of security services to protocol layers. The following table shows which security services (see definitions in this Glossary) are permitted by the OSIRM in each of its layers. (Also, an application process that operates above the Application Layer may itself provide security services.) Similarly, the table suggests which services are suitable for each IPS layer. However, explaining and justifying these allocations is beyond the scope of this Glossary.
$ OSIRRセキュリティアーキテクチャ（n）2つのシステム間の通信を保護するために適用できるセキュリティサービスとセキュリティメカニズムを指定するOSIRR [I7498-2]の部分。（セキュリティアーキテクチャを参照してください。）チュートリアル：この部分は、プロトコルレイヤへのセキュリティサービスの割り当てを含みます。次の表は、どのセキュリティサービス（この用語集の定義を参照）が各レイヤーのOSIRMによって許可されているかを示しています。（また、アプリケーション層の上に動作するアプリケーションプロセスはセキュリティサービスを提供してもよい。）同様に、テーブルはどのサービスが各IPS層に適しているかを示唆している。ただし、これらの割り当てを説明し正当化することはこの用語集の範囲を超えています。
Legend for Table Entries: O = Yes, [I7498-2] permits the service in this OSIRM layer. I = Yes, the service can be incorporated in this IPS layer. * = This layer subsumed by Application Layer in IPS.
テーブルエントリの凡例：o =はい、[I7498-2]このOSIRRSレイヤのサービスを許可します。i =はい、このIPS層にサービスを組み込むことができます。* =このレイヤーはIPSのアプリケーション層によってサブされます。
IPS Protocol Layers +-----------------------------------------+
|Network| Net |In-| Trans | Application |
| H/W |Inter|ter| -port | |
| |-face|net| | |
OSIRM Protocol Layers +-----------------------------------------+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Confidentiality +-----------------------------------------+
- Datagram | O I | O I | O I | O I | | O * | O I |
- Selective Field | | | I | | | O * | O I |
- Traffic Flow | O | | O | | | | O |
-- Full | I | | | | | | |
-- Partial | | I | I | | | | I |
Integrity +-----------------------------------------+
- Datagram | I | I | O I | O I | | | O I |
- Selective Field | | | I | | | | O I |
- Stream | | | O I | O I | | | O I |
Authentication +-----------------------------------------+
- Peer Entity | | I | O I | O I | | | O I |
- Data Origin | | I | O I | O I | | | O I |
Access Control +-----------------------------------------+
- type as appropriate | | I | O I | O I | | | O I |
Non-Repudiation +-----------------------------------------+
- of Origin | | | | | | | O I |
- of Receipt | | | | | | | O I |
+-----------------------------------------+
$ OTAR (N) See: over-the-air rekeying.
$ OTAR（N）を参照してください。
$ OTP (I) See: One-Time Password.
$ OTP（i）ワンタイムパスワードを参照してください。
$ out-of-band (I) /adjective, adverb/ Information transfer using a channel or method that is outside (i.e., separate from or different from) the main channel or normal method.
$ 帯域外（i）/形容詞、副詞/情報転送、または主なチャネルまたは通常の方法の外側（つかず、または異なる）のチャネルまたは方法を使用した転送。
Tutorial: Out-of-band mechanisms are often used to distribute shared secrets (e.g., a symmetric key) or other sensitive information items (e.g., a root key) that are needed to initialize or otherwise enable the operation of cryptography or other security mechanisms. Example: Using postal mail to distribute printed or magnetic media containing symmetric cryptographic keys for use in Internet encryption devices. (See: key distribution.)
チュートリアル：アウトオブバンドメカニズムは、暗号化された秘密（例えば、対称鍵など）または他の機密情報（例えば、ルートキー）を分散させて、暗号化または他のセキュリティメカニズムの操作を初期化するか、そうでなければ可能にする。。例：インターネット暗号化装置で使用するための対称暗号鍵を含む印刷物または磁気メディアを配布するための郵便番号。（鍵配布を参照してください。）
$ output feedback (OFB) (N) A block cipher mode that modifies ECB mode to operate on plaintext segments of variable length less than or equal to the block length. [FP081] (See: block cipher, [SP38A].)
$ 出力フィードバック（OFB）（n）ブロック長以下の可変長の平文セグメントで動作するようにECBモードを変更するブロック暗号モード。[FP081]（[Chiper]を参照してください.Ciphers、[SP38A]）
Tutorial: This mode operates by directly using the algorithm's previously generated output block as the algorithm's next input block (i.e., by "feeding back" the output block) and combining (exclusive OR-ing) the output block with the next plaintext segment (of block length or less) to form the next ciphertext segment.
チュートリアル：このモードは、アルゴリズムの以前に生成された出力ブロックをアルゴリズムの次の入力ブロックとして（すなわち、「出力ブロックの送り返し」および次の平文セグメントとの出力ブロックを組み合わせて（排他的論理和）することで直接動作します。次の暗号文セグメントを形成するためにブロック長以下）
$ outside attack (I) See: secondary definition under "attack". Compare: outsider.)
$ 外部攻撃（i）「攻撃」の下の二次定義を参照してください。比較：部外者。）
$ outsider (I) A user (usually a person) that accesses a system from a position that is outside the system's security perimeter. (Compare: authorized user, insider, unauthorized user.)
$ outsider（i）システムのセキュリティ周辺の外側にある位置からシステムにアクセスするユーザー（通常は人）。（比較：承認されたユーザー、インサイダー、不正なユーザー。）
Tutorial: The actions performed by an outsider in accessing the system may be either authorized or unauthorized; i.e., an outsider may act either as an authorized user or as an unauthorized user.
チュートリアル：システムへのアクセス中の部外者によって実行されたアクションは、許可されているか不正なものです。すなわち、部外者は、許可されたユーザまたは不正なユーザとしても行動することができる。
$ over-the-air rekeying (OTAR) (N) Changing a key in a remote cryptographic device by sending a new key directly to the device via a channel that the device is protecting. [C4009]
$ air-the-air-resking（n）デバイスが保護しているチャネルを介して、デバイスに直接新しいキーを送信することによって、リモート暗号デバイスのキーを変更します。[C4009]
$ overload (I) /threat action/ See: secondary definition under "obstruction".
$ オーバーロード（I）/脅威アクション/参照：「障害物」の下の二次定義。
$ P1363 (N) See: IEEE P1363.
$ P1363（n）参照：IEEE P1363を参照してください。
$ PAA (O) See: policy approving authority.
$ PAA（o）は、ポリシー承認権限を参照してください。
$ package (N) /Common Criteria/ A reusable set of either functional or assurance components, combined in a single unit to satisfy a set of identified security objectives. (Compare: protection profile.)
$ パッケージ（N）/共通基準/機能的または保証部品のいずれかの再使用可能なセット、単一のユニット内で組み合わされて、識別されたセキュリティ目標のセットを満たす。（比較：保護プロファイル）
Example: The seven EALs defined in Part 3 of the Common Criteria are predefined assurance packages.
例：一般的な基準の部分3で定義されている7つのEALは、事前定義された保証パッケージです。
Tutorial: A package is a combination of security requirement components and is intended to be reusable in the construction of either more complex packages or protection profiles and security targets. A package expresses a set of either functional or assurance requirements that meet some particular need, expressed as a set of security objectives.
チュートリアル：パッケージはセキュリティ要件コンポーネントの組み合わせであり、より複雑なパッケージまたは保護プロファイルとセキュリティターゲットの構成で再利用可能であることを意図しています。パッケージは、一連のセキュリティ目標として表される、いくつかの特定の必要性を満たす機能または保証要件のセットを表します。
$ packet (I) A block of data that is carried from a source to a destination through a communication channel or, more generally, across a network. (Compare: datagram, PDU.)
$ パケット（i）通信チャネルまたはより一般的にはネットワークを介して、ソースから宛先への送信元から宛先へのデータブロック。（比較：データグラム、PDU）
$ packet filter (I) See: secondary definition under "filtering router".
$ パケットフィルタ（i）「フィルタリングルータ」の下のセカンダリ定義。
$ packet monkey (D) /slang/ Someone who floods a system with packets, creating a denial-of-service condition for the system's users. (See: cracker.)
$ パケットモンキー（D）/ Slang /パケットを搭載したシステムにあふれている人、システムのユーザーのサービス拒否条件を作成します。（クラッカーを参照してください。）
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ pagejacking (D) /slang/ A contraction of "Web page hijacking". A masquerade attack in which the attacker copies (steals) a home page or other material from the target server, rehosts the page on a server the attacker controls, and causes the rehosted page to be indexed by the major Web search services, thereby diverting browsers from the target server to the attacker's server.
$ PageJacking（D）/スラング/「WebページHijacking」の縮小。攻撃者がターゲットサーバからホームページまたは他の資料をコピー（盗む）をコピーすると、攻撃者がコントロールするサーバー上のページを再ホストし、再ホストされたページをメジャーWeb検索サービスによって索引付けさせ、それによってブラウザをそらすことができます。ターゲットサーバーから攻撃者のサーバーへ。
Deprecated Term: IDOCs SHOULD NOT use this contraction. The term is not listed in most dictionaries and could confuse international readers. (See: Deprecated Usage under "Green Book".)
廃止予定語：IDocsはこの縮小を使用しないでください。この用語はほとんどの辞書に記載されておらず、国際読者を混同することができます。（「グリーンブック」の「廃止予定の使用」。）
$ PAN (O) See: primary account number.
$ PAN（O）次：プライマリアカウント番号を参照してください。
$ PAP (I) See: Password Authentication Protocol.
$ PAP（i）パスワード認証プロトコルを参照してください。
$ parity bit (I) A checksum that is computed on a block of bits by computing the binary sum of the individual bits in the block and then discarding all but the low-order bit of the sum. (See: checksum.)
$ パリティビット（i）ブロック内の個々のビットのバイナリ合計を計算してから、合計の下位ビットを破棄することによってビットのブロックで計算されるチェックサム。（チェックサムを参照してください。）
$ partitioned security mode (N) A mode of system operation wherein all users having access to the system have the necessary security clearances for all data handled by the system, but some users might not have either formal access approval or need-to-know for all the data. (See: /system operation/ under "mode", formal access approval, need to know, protection level, security clearance.)
$ パーティションセキュリティモード（n）システムにアクセスできるすべてのユーザーがシステムによって処理されるすべてのデータに対して必要なセキュリティクリアランスを持つシステムの動作モードですが、一部のユーザーは正式なアクセス承認またはすべての知識を知らない可能性があります。データ。（/システム操作/「モード」の「モード」、正式なアクセス承認、知っている、保護レベル、セキュリティクリアランス。）
Usage: Usually abbreviated as "partitioned mode". This term was defined in U.S. Government policy on system accreditation.
使用法：通常、「パーティションモード」と略記します。この用語は、システム認定に関する米国政府政策で定義されていました。
$ PASS (N) See: personnel authentication system string.
$ pass（n）：人員認証システム文字列を参照してください。
$ passive attack (I) See: secondary definition under "attack".
$ パッシブ攻撃（i）「攻撃」の下の二次定義を参照してください。
$ passive user (I) See: secondary definition under "system user".
$ Passive User（i）「システムユーザー」の下のセカンダリ定義を参照してください。
$ passive wiretapping (I) A wiretapping attack that attempts only to observe a communication flow and gain knowledge of the data it contains, but does not alter or otherwise affect that flow. (See: wiretapping. Compare: passive attack, active wiretapping.)
$ パッシブワイヤキャッピング（I）通信フローを観察し、それが含むデータの知識を得ることを試みる盗聴攻撃は、そのフローを変更しないか、そうでなければ影響しません。（盗聴：パッシブ攻撃、アクティブな盗聴系。）
$ password 1a. (I) A secret data value, usually a character string, that is presented to a system by a user to authenticate the user's identity. (See: authentication information, challenge-response, PIN, simple authentication.)
$ パスワード1a。（i）ユーザの身元を認証するためのユーザによるシステムに提示された秘密データ値、通常は文字列。（認証情報、チャレンジ応答、PIN、単純認証）
1b. (O) "A character string used to authenticate an identity." [CSC2]
1b。（O）「アイデンティティの認証に使用される文字列」[CSC2]
1c. (O) "A string of characters (letters, numbers, and other symbols) used to authenticate an identity or to verify access authorization." [FP140]
1c。（O） "IDを認証するため、またはアクセス許可を確認するために使用される文字の文字列（文字、数字、その他の記号）。[FP140]
1d. (O) "A secret that a claimant memorizes and uses to authenticate his or her identity. Passwords are typically character strings." [SP63]
1D。（O）「請求者が彼または彼女の身元を認証するために記憶して使用する秘密。パスワードは通常文字列です。」[SP63]
Tutorial: A password is usually paired with a user identifier that is explicit in the authentication process, although in some cases the identifier may be implicit. A password is usually verified by matching it to a stored value held by the access control system for that identifier.
チュートリアル：通常、認証プロセスで明示的なユーザー識別子とペアになっていますが、場合によっては識別子が暗黙的になる場合があります。パスワードは通常、その識別子のためにアクセス制御システムによって保持されている格納値にそれを一致させることによって検証されます。
Using a password as authentication information is based on assuming that the password is known only by the system entity for which the identity is being authenticated. Therefore, in a network environment where wiretapping is possible, simple authentication that relies on transmission of static (i.e., repetitively used) passwords in cleartext form is inadequate. (See: one-time password, strong authentication.)
認証情報としてパスワードを使用することは、パスワードが認証されているシステムエンティティによってのみパスワードがわかっていると仮定しています。したがって、盗聴が可能なネットワーク環境では、クリアテキスト形式で静的（すなわち繰り返し使用されている）パスワードの送信に依存する簡単な認証が不十分である。（1回限りのパスワード、強力な認証を参照してください。）
$ Password Authentication Protocol (PAP) (I) A simple authentication mechanism in PPP. In PAP, a user identifier and password are transmitted in cleartext form. [R1334] (See: CHAP.)
$ パスワード認証プロトコル（PAP）（i）PPPの単純な認証メカニズム。PAPでは、ユーザー識別子とパスワードがClearTextフォームで送信されます。[R1334]（参照：CHAP。）
$ password sniffing (D) /slang/ Passive wiretapping to gain knowledge of passwords. (See: Deprecated Usage under "sniffing".)
$ パスワードの無知のためのパスワードスニッフィング（D）/スラング/パッシブ盗聴。（「スニッフィング」の下での廃止予定の使用法を参照してください。）
$ path discovery (I) For a digital certificate, the process of finding a set of public-key certificates that comprise a certification path from a trusted key to that specific certificate.
$ Path Discovery（i）デジタル証明書の場合、信頼できる鍵からその特定の証明書への認証パスを構成する一連の公開鍵証明書を見つけるプロセス。
$ path validation (I) The process of validating (a) all of the digital certificates in a certification path and (b) the required relationships between those certificates, thus validating the contents of the last certificate on the path. (See: certificate validation.)
$ PATH検証（i）認証パス内のすべてのデジタル証明書を検証するプロセスと（b）それらの証明書の間に必要な関係を検証して、パス上の最後の証明書の内容を検証します。（証明書検証を参照してください。）
Tutorial: To promote interoperable PKI applications in the Internet, RFC 3280 specifies a detailed algorithm for validation of a certification path.
チュートリアル：インターネット内の相互運用可能なPKIアプリケーションを促進するために、RFC 3280は認証パスを検証するための詳細なアルゴリズムを指定します。
$ payment card (N) /SET/ Collectively refers "to credit cards, debit cards, charge cards, and bank cards issued by a financial institution and which reflects a relationship between the cardholder and the financial institution." [SET2]
$ 決済カード、デビットカード、充電カード、および金融機関によって発行された銀行カード、およびカード会員と金融機関の間の関係を反映している銀行カードへの支払いカード（N）/集合的に参照する。[SET2]
$ payment gateway (O) /SET/ A system operated by an acquirer, or a third party designated by an acquirer, to provide electronic commerce services to the merchants in support of the acquirer, and which interfaces to the acquirer to support the authorization, capture, and processing of merchant payment messages, including payment instructions from cardholders. [SET1, SET2]
$ Acquirer、またはAcquirerによって指定された第三者によって運営されているシステム/セット/セット/ A回収者が購入者に電子商取引サービスを提供し、認可をサポートするために獲得者にインタフェースするそして、カード保有者からの支払い指示を含む、マーチャント支払いメッセージの処理。[SET1、SET2]
$ payment gateway certification authority (SET PCA) (O) /SET/ A CA that issues digital certificates to payment gateways and is operated on behalf of a payment card brand, an acquirer, or another party according to brand rules. A SET PCA issues a CRL for compromised payment gateway certificates. [SET2] (See: PCA.)
$ 支払いゲートウェイ認証局（PCA）/セット/ A CAは、支払いゲートウェイにデジタル証明書を発行し、ブランドルールによると、支払いカードブランド、取得者、または他の当事者に代わって運営されています。セットPCAは、侵入先の支払いゲートウェイ証明書のCRLを発行します。[SET2]（PCAを参照）
$ PC card (N) A type of credit card-sized, plug-in peripheral device that was originally developed to provide memory expansion for portable computers, but is also used for other kinds of functional expansion. (See: FORTEZZA, PCMCIA.)
$ PCカード（N）もともとポータブルコンピュータのメモリ拡張を提供するために開発されたが、他の種類の機能拡張にも使用されていたクレジットカードサイズのプラグイン周辺機器の一種のクレジットカードサイズのプラグイン周辺機器。（：Fortezza、PCMCIA。）
Tutorial: The international PC Card Standard defines a non-proprietary form factor in three sizes -- Types I, II, and III -- each of which have a 68-pin interface between the card and the socket into which it plugs. All three types have the same length and width, roughly the size of a credit card, but differ in their thickness from 3.3 to 10.5 mm. Examples include storage modules, modems, device interface adapters, and cryptographic modules.
チュートリアル：国際PCカード規格は、3つのサイズで非独自のフォームファクタを定義します.II、II、およびIII - それぞれ、カードとプラグをプラグするソケットとの間に68ピンインターフェイスがあります。3つのタイプすべてが同じ長さと幅、クレジットカードの大きさの大きさを持ちますが、3.3から10.5 mmの厚さが異なります。例としては、ストレージモジュール、モデム、デバイスインターフェイスアダプタ、および暗号化モジュールがあります。
$ PCA (D) Abbreviation of various kinds of "certification authority". (See: Internet policy certification authority, (MISSI) policy creation authority, (SET) payment gateway certification authority.)
$ PCA（D）さまざまな種類の「認証局」の略語。（インターネットポリシー認証局、（MISSI）ポリシー作成局、（設定）支払いゲートウェイ認証局。
Deprecated Usage: An IDOC that uses this abbreviation SHOULD define it at the point of first use.
廃止予定の使用法：この省略形を使用するIDocは、最初の使用の時点で定義する必要があります。
$ PCI (N) See: "protocol control information" under "protocol data unit".
$ PCI（N）「プロトコルデータ単位」の「プロトコル制御情報」を参照してください。
$ PCMCIA (N) Personal Computer Memory Card International Association, a group of manufacturers, developers, and vendors, founded in 1989 to standardize plug-in peripheral memory cards for personal computers and now extended to deal with any technology that works in the PC Card form factor. (See: PC card.)
$ PCMCIA（N）PCMCIA（N）パーソナルコンピュータメモリカード国際協会、1989年に設立されたメーカー、開発者、およびベンダーのグループパーソナルコンピュータ用のプラグイン周辺メモリカードを標準化し、PCカード形式で機能する技術に対処するために拡張されました。因子。（参照：PCカード。）
$ PDS (N) See: protective distribution system.
$ PDS（N）は、保護配信システムを参照してください。
$ PDU (N) See: protocol data unit.
$ PDU（n）プロトコルデータユニットを参照してください。
$ peer entity authentication (I) "The corroboration that a peer entity in an association is the one claimed." [I7498-2] (See: authentication.)
$ ピアエンティティ認証（I）「協会内のピアエンティティが主張したことのためのコラボレーション」[I7498-2]（認証を参照）
$ peer entity authentication service (I) A security service that verifies an identity claimed by or for a system entity in an association. (See: authentication, authentication service.)
$ ピアエンティティ認証サービス（i）関連付け中のシステムエンティティによって、またはシステムエンティティを主張する識別情報を検証するセキュリティサービス。（検知、認証サービスを参照してください。）
Tutorial: This service is used at the establishment of, or at times during, an association to confirm the identity of one entity to another, thus protecting against a masquerade by the first entity. However, unlike data origin authentication service, this service requires an association to exist between the two entities, and the corroboration provided by the service is valid only at the current time that the service is provided. (See: "relationship between data integrity service and authentication services" under "data integrity service").
チュートリアル：このサービスは、1つのエンティティのアイデンティティを別のエンティティのアイデンティティを確認するための関連性の確立、または最初のエンティティによるマスカレードに対して保護することで使用されます。ただし、データオリジナル認証サービスとは異なり、このサービスは2つのエンティティ間の関連付けが必要であり、サービスによって提供されるコラボレーションは、サービスが提供されている現在時刻でのみ有効です。（「データ整合性サービス」の「データ整合性サービスと認証サービスの関係」）。
$ PEM (I) See: Privacy Enhanced Mail.
$ PEM（i）は、プライバシー強化されたメールを参照してください。
$ penetrate 1a. (I) Circumvent a system's security protections. (See: attack, break, violation.)
$ 1Aを貫通します。（i）システムのセキュリティ保護を回避する。（攻撃、休憩、違反）
1b. (I) Successfully and repeatedly gain unauthorized access to a protected system resource. [Huff]
1b。（i）保護されたシステムリソースへの不正アクセスを正常かつ繰り返し得る。[ハフ]
$ penetration (I) /threat action/ See: secondary definition under "intrusion".
$ 浸透（I）/脅威の処置/参照：「侵入」の下の二次定義。
$ penetration test (I) A system test, often part of system certification, in which evaluators attempt to circumvent the security features of a system. [NCS04, SP42] (See: tiger team.)
$ 浸透テスト（i）評価者がシステムのセキュリティ機能を回避しようとするシステム認証の一部であるシステムテスト。[NCS04、SP42]（See：Tiger Team。）
Tutorial: Penetration testing evaluates the relative vulnerability of a system to attacks and identifies methods of gaining access to a system by using tools and techniques that are available to adversaries. Testing may be performed under various constraints and conditions, including a specified level of knowledge of the system design and implementation. For a TCSEC evaluation, testers are assumed to have all system design and implementation documentation, including source code, manuals, and circuit diagrams, and to work under no greater constraints than those applied to ordinary users.
チュートリアル：侵入テストは、攻撃を攻撃するためのシステムの相対的な脆弱性を評価し、敵対者に利用可能なツールとテクニックを使用してシステムへのアクセスを取得する方法を識別します。テストは、システム設計と実装に関する指定されたレベルの知識を含む、さまざまな制約や条件下で実行できます。TCSECの評価のために、テスターは、ソースコード、マニュアル、および回路図を含むすべてのシステム設計および実装文書を持つこと、および通常のユーザーに適用されるものよりも大きな制約を受けないと見なされます。
$ perfect forward secrecy (I) For a key agreement protocol, the property that compromises long-term keying material does not compromise session keys that were previously derived from the long-term material. (Compare: public-key forward secrecy.)
$ 完全な前方秘密（i）重要な合意プロトコルのための、長期キーイング材料を侵害する財産は、以前は長期資料から導き出されたセッション鍵を危険にさらさない。（比較：公開鍵の前方秘密。）
Usage: Some existing RFCs use this term but either do not define it or do not define it precisely. While preparing this Glossary, we found this to be a muddled area. Experts did not agree. For all practical purposes, the literature defines "perfect forward secrecy" by stating the Diffie-Hellman-Merkle algorithm. The term "public-key forward secrecy" (suggested by Hilarie Orman) and the definition stated for it in this Glossary were crafted to be compatible with current Internet documents, yet be narrow and leave room for improved terminology.
使用法：既存のRFCの中にはこの用語を使用していますが、それを定義したり、正確に定義したりしないでください。この用語集を準備しながら、これは混乱した地域であることがわかりました。専門家は同意しませんでした。すべての実用的な目的のために、文献はDiffie-Hellman-Merkleアルゴリズムを述べることによって「完全な前進秘密」を定義しています。この用語集で「公開鍵順Secrecy」と定義は、現在のインターネット文書と互換性があるように作られていましたが、狭くて名誉ある用語のための部屋を残します。
Challenge to the Internet security community: We need a taxonomy of terms and definitions to cover the basic properties discussed here for the full range of cryptographic algorithms and protocols used in Internet Standards:
インターネットセキュリティコミュニティへの挑戦：インターネット規格で使用される暗号化アルゴリズムおよびプロトコルの全範囲について、ここで議論された基本的なプロパティをカバーするための用語と定義の分類法が必要です。
Involvement of session keys vs. long-term keys: Experts disagree about the basic ideas involved: - One concept of "forward secrecy" is that, given observations of the operation of a key establishment protocol up to time t, and given some of the session keys derived from those protocol runs, you cannot derive unknown past session keys or future session keys. - A related property is that, given observations of the protocol and knowledge of the derived session keys, you cannot derive one or more of the long-term private keys.
セッション鍵と長期鍵の関与：専門家たちが関与している基本的な考えについての同意します。これらのプロトコル実行から派生したセッションキーは、未知の過去のセッションキーまたは将来のセッションキーを導き出すことはできません。 - 関連する財産は、派生セッション鍵のプロトコルの観察と知識を考慮すると、1つ以上の長期秘密鍵を導き出すことはできません。
- The "I" definition presented above involves a third concept of "forward secrecy" that refers to the effect of the compromise of long-term keys. - All three concepts involve the idea that a compromise of "this" encryption key is not supposed to compromise the "next" one. There also is the idea that compromise of a single key will compromise only the data protected by the single key. In Internet literature, the focus has been on protection against decryption of back traffic in the event of a compromise of secret key material held by one or both parties to a communication.
- 上記の「I」の定義は、長期キーの妥協の影響を指す「前方秘密」の第3の概念を含む。 - 3つの概念はすべて、「この」暗号化キーの妥協点が「次へ」のものを危険にさらすことになっていないという考えを含みます。単一のキーを犠牲にするという考えは、単一キーによって保護されたデータのみを危険にさらすという考えもあります。インターネット文学では、焦点を合わせる秘密鍵素材の妥協点が、コミュニケーションに保持されている秘密鍵素材を犠牲にした場合に、焦点は逆トラフィックの復号化を受けています。
Forward vs. backward: Experts are unhappy with the word "forward", because compromise of "this" encryption key also is not supposed to compromise the "previous" one, which is "backward" rather than forward. In S/KEY, if the key used at time t is compromised, then all keys used prior to that are compromised. If the "long-term" key (i.e., the base of the hashing scheme) is compromised, then all keys past and future are compromised; thus, you could say that S/KEY has neither forward nor backward secrecy.
「この」暗号化キーの妥協点も、前方ではなく「前方」のものを侵害することを想定していないため、専門家は「前方」という言葉で不幸です。S / KEYでは、時刻tに使用されたキーが危険にさらされている場合は、その前に使用されたすべてのキーが侵害されます。「長期的な」キー（すなわち、ハッシュ方式の基部）が危険にさらされている場合、過去および将来のすべてのキーが損なわれている。したがって、S / Keyは将来の秘密や後方秘密もないと言うことができます。
Asymmetric cryptography vs. symmetric: Experts disagree about forward secrecy in the context of symmetric cryptographic systems. In the absence of asymmetric cryptography, compromise of any long-term key seems to compromise any session key derived from the long-term key. For example, Kerberos isn't forward secret, because compromising a client's password (thus compromising the key shared by the client and the authentication server) compromises future session keys shared by the client and the ticket-granting server.
非対称暗号対称対称：専門家は、対称暗号システムの文脈において前方秘密について同意しない。非対称暗号化がない場合、長期キーを犠牲にすると、長期キーから派生したセッションキーが損なわれているようです。たとえば、クライアントのパスワードを犠牲にするため（したがって、クライアントと認証サーバーによって共有されているキーを犠牲にするため）は、クライアントとチケット付与サーバーによって共有された将来のセッションキーを犠牲にしているため、Kerberosは前方に秘密ではありません。
Ordinary forward secrecy vs. "perfect" forward secret: Experts disagree about the difference between these two. Some say there is no difference, and some say that the initial naming was unfortunate and suggest dropping the word "perfect". Some suggest using "forward secrecy" for the case where one long-term private key is compromised, and adding "perfect" for when both private keys (or, when the protocol is multi-party, all private keys) are compromised.
普通の順方向秘密と「完璧」前方秘密：専門家はこれら2つの違いについて同意しません。違いがないと言う人もいますが、最初の命名は残念だったと言われ、「完璧な」という言葉を落とすことをお勧めします。1つの長期秘密鍵が危険にさらされ、秘密鍵の両方（または、プロトコルがマルチパーティの場合はすべての秘密鍵）が危険にさらされている場合に「Forward Secrecy」を使用することをお勧めします。
Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul Van Oorschot, Jonathan Trostle, Michael Wiener, and, especially, Hilarie Orman contributed ideas to this discussion.
謝辞：Bill Burr、Burt Kaliski、Steve Kent、Paul Van Oorschot、Jonathan Trostle、Michael Wiener、そして特に、ヘラリーアーオルマンはこの議論へのアイデアを貢献しました。
$ perimeter See: security perimeter.
$ 境界を見る：セキュリティ境界。
$ periods processing (I) A mode of system operation in which information of different sensitivities is processed at distinctly different times by the same system, with the system being properly purged or sanitized between periods. (See: color change.)
$ 期間処理（i）システムは、システムが正しくパージまたは消毒された状態で、異なる感度の情報が同じシステムによって異なる時間に処理されるシステム動作のモード。（参照：色変更。）
Tutorial: The security mode of operation and maximum classification of data handled by the system is established for an interval of time and then is changed for the following interval of time. A period extends from the secure initialization of the system to the completion of any purging of sensitive data handled by the system during the period.
チュートリアル：システムによって処理されるデータのセキュリティ動作および最大分類は、時間間隔に対して確立され、次の時間間隔で変更されます。期間は、システムの安全な初期化からシステムによって処理された機密データの任意のパージが完了するまでの間に延びる。
$ permanent storage (I) Non-volatile media that, once written into, can never be completely erased.
$ 永久保管（i）書かれた不揮発性媒体は、完全に消去されることはありません。
$ permission 1a. (I) Synonym for "authorization". (Compare: privilege.)
$ 許可1a。（i）「承認」の同義語。（比較：特権）
1b. (N) An authorization or set of authorizations to perform security-relevant functions in the context of role-based access control. [ANSI]
1b。（n）役割ベースのアクセス制御のコンテキストでセキュリティ関連の機能を実行するための許可または承認のセット。[ANSI]
Tutorial: A permission is a positively stated authorization for access that (a) can be associated with one or more roles and (b) enables a user in a role to access a specified set of system resources by causing a specific set of system actions to be performed on the resources.
チュートリアル：権限は、（a）を1つ以上のロールに関連付けることができるアクセスのための正確な許可であり、（b）特定のシステムアクションのセットを実行することによって、指定されたシステムリソースのセットにアクセスするためのユーザーが役割のユーザーをアクセスできるようになる。リソースに対して実行されます。
$ persona certificate (I) An X.509 certificate issued to a system entity that wishes to use a persona to conceal its true identity when using PEM or other Internet services that depend on PKI support. (See: anonymity.) [R1422]
$ Persona Certificate（i）PKIサポートに依存するPEMまたは他のインターネットサービスを使用するときに、Personaを使用して本当のアイデンティティを隠すことを希望するシステムエンティティに発行されたX.509証明書。（匿名性を参照してください。）[R1422]
Tutorial: PEM designers intended that (a) a CA issuing persona certificates would explicitly not be vouching for the identity of the system entity to whom the certificate is issued, (b) such certificates would be issued only by CAs subordinate to a policy CA having a policy stating that purpose (i.e., that would warn relying parties that the "subject" field DN represented only a persona and not a true, vetted user identity), and (c) the CA would not need to maintain records binding the true identity of the subject to the certificate.
チュートリアル：PEMデザイナーは、（a）証明書が発行されたシステムエンティティの身元のために、CA発行ペルソナ証明書が明示的に告知されていないことを意図しています。その目的を示すポリシー（すなわち、「件名」フィールドDNがPersonAのみを表していて、（C）のみを表し、（c）、CAは本当のアイデンティティをバインディングする必要がないであろう対象の証明書の。
However, the PEM designers also intended that a CA issuing persona certificates would establish procedures (d) to enable "the holder of a PERSONA certificate to request that his certificate be revoked" and (e) to ensure that it did not issue the same subject DN to multiple users. The latter condition implies that a persona certificate is not an organizational certificate unless the organization has just one member or representative.
ただし、PEMデザイナーはまた、CA発行ペルソナ証明書であることを意図しています。複数のユーザーにDN。後者の状態は、組織に1つのメンバーまたは代表者がある場合を除き、Persona証明書が組織証明書ではないことを意味します。
$ personal identification number (PIN) 1a. (I) A character string used as a password to gain access to a system resource. (See: authentication information.)
$ 個人識別番号（PIN）1A。（i）システムリソースにアクセスするためのパスワードとして使用される文字列。（認証情報を参照してください。）
Example: A cryptographic token typically requires its user to enter a PIN in order to access information stored in the token and invoke the token's cryptographic functions.
例：暗号化トークンは通常、トークンに格納されている情報にアクセスしてトークンの暗号機能を呼び出すためにPINを入力する必要があります。
1b. (O) An alphanumeric code or password used to authenticate an identity.
1b。（O）IDを認証するために使用される英数字コードまたはパスワード。
Tutorial: Despite the words "identification" and "number", a PIN seldom serves as a user identifier, and a PIN's characters are not necessarily all numeric. Retail banking applications use 4-digit numeric user PINs, but the FORTEZZA PC card uses 12-character alphanumeric SSO PINs. (See: SSO PIN, user PIN.)
チュートリアル：「識別」と「番号」という言葉にもかかわらず、PINはユーザー識別子として機能し、PINの文字は必ずしもすべての数値ではありません。小売バンキングアプリケーションは4桁の数字のユーザーピンを使用しますが、Fortezza PCカードは12文字の英数字SSOピンを使用します。（参照：SSO端子、ユーザー端子）
A better name for this concept would have been "personnel authentication system string" (PASS), in which case, an alphanumeric character string for this purpose would have been called, obviously, a "PASSword".
この概念のためのより良い名前は「人事認証システムの文字列」（パス）であったが、この場合、この目的のための英数字文字列は呼ばれ、明らかに「パスワード」である。
$ personal information (I) Information about a particular person, especially information of an intimate or critical nature, that could cause harm or pain to that person if disclosed to unauthorized parties. Examples: medical record, arrest record, credit report, academic transcript, training report, job application, credit card number, Social Security number. (See: privacy.)
$ 個人情報（i）特定の人物、特に親密なものや重大な性質の情報、特に不正な締約国に開示されている場合には、その人に害または痛みを引き起こす可能性があります。例：医療記録、逮捕記録、クレジットレポート、学術的なトランプ、トレーニングレポート、求職、クレジットカード番号、社会保障番号。（：プライバシーを参照してください。）
$ personality 1. (I) Synonym for "principal".
$ 人格1.（i）「プリンシパル」の同義語。
2. (O) /MISSI/ A set of MISSI X.509 public-key certificates that have the same subject DN, together with their associated private keys and usage specifications, that is stored on a FORTEZZA PC card to support a role played by the card's user.
2. （O）/ MISSI /同じサブジェクトDNを持つMissi X.509のセット、それに関連する秘密鍵と使用仕様とともに、カードが再生する役割をサポートするためにFortezza PCカードに保存されています。ユーザー。
Tutorial: When a card's user selects a personality to use in a FORTEZZA-aware application, the data determines behavior traits (the personality) of the application. A card's user may have multiple personalities on the card. Each has a "personality label", a user-friendly character string that applications can display to the user for selecting or changing the personality to be used. For example, a military user's card might contain three personalities: GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW YEAR'S EVE PARTY CHAIRMAN. Each personality includes one or more certificates of different types (such as DSA versus RSA), for different purposes (such as digital signature versus encryption), or with different authorizations.
チュートリアル：カードのユーザーがFortezza対応アプリケーションで使用する人格を選択すると、データはアプリケーションの動作特性（個性）を決定します。カードのユーザーは、カードに複数の個性を持つことができます。使用される個性を選択または変更するために、アプリケーションがユーザーに表示できるユーザーフレンドリキャラクタ文字列は、それぞれ「パーソナリブルラベル」を持ちます。たとえば、軍事ユーザーのカードには、一般的なHalftrack、Commander Fort Swampy、およびYeke Eve Party Chairmanが3つの個性が含まれています。各性格は、さまざまな目的（デジタル署名と暗号化など）の場合、またはさまざまな権限を持つ1つ以上の種類の証明書（DSA対RSAなど）を含みます。
$ personnel authentication system string (PASS) (N) See: Tutorial under "personal identification number".
$ 人事認証システム文字列（PASS）（N）参照：「個人識別番号」の下のチュートリアル。
$ personnel security (I) Procedures to ensure that persons who access a system have proper clearance, authorization, and need-to-know as required by the system's security policy. (See: security architecture.)
$ 人事セキュリティ（i）システムにアクセスする人がシステムのセキュリティポリシーによって必要な通りに適切なクリアランス、承認、および知識がないことを確認する手順。（セキュリティアーキテクチャを参照してください。）
$ PGP(trademark) (O) See: Pretty Good Privacy(trademark).
$ PGP（登録商標）（O）参照：かなり良いプライバシー（商標）。
$ phase 1 negotiation $ phase 2 negotiation (I) /ISAKMP/ See: secondary definition under "Internet Security Association and Key Management Protocol".
$ フェーズ1ネゴシエーション$フェーズ2ネゴシエーション（I）/ ISAKMP / SEE：「インターネットセキュリティアソシエーションとキー管理プロトコル」の下のセカンダリ定義。
$ phishing (D) /slang/ A technique for attempting to acquire sensitive data, such as bank account numbers, through a fraudulent solicitation in email or on a Web site, in which the perpetrator masquerades as a legitimate business or reputable person. (See: social engineering.)
$ フィッシング（D）/ Slang /銀行口座番号などの機密データを取得しようとする技術は、電子メールまたはWebサイト上の詐欺的な勧誘を通じて、特許子が正当なビジネスまたは評判の高い人としてマスカレードされている。（社会工学を参照してください。）
Derivation: Possibly from "phony fishing"; the solicitation usually involves some kind of lure or bait to hook unwary recipients. (Compare: phreaking.)
派生：おそらく「偽釣り」から;勧誘は通常、不十分なレシピエントをフックするためのある種のルアーや餌を含みます。（比較：発言。）
Deprecated Term: IDOCs SHOULD NOT use this term; it is not listed in most dictionaries and could confuse international readers. (See: Deprecated Usage under "Green Book".)
廃止予定語：IDocsはこの用語を使用しないでください。それはほとんどの辞書にリストされておらず、国際的な読者を混同することができます。（「グリーンブック」の「廃止予定の使用」。）
$ Photuris (I) A UDP-based, key establishment protocol for session keys, designed for use with the IPsec protocols AH and ESP. Superseded by IKE.
$ PHOTURIS（i）IPsecプロトコルAHとESPで使用するために設計されたセッションキーのUDPベースのキー設立プロトコル。IKEに置き換えられた。
$ phreaking (D) A contraction of "telephone breaking". An attack on or penetration of a telephone system or, by extension, any other communication or information system. [Raym]
$ Pheraking（d）「電話壊れ」の縮小。電話システムの攻撃や侵入、あるいは拡張によって、他の通信または情報システムによって。[raym]
Deprecated Term: IDOCs SHOULD NOT use this contraction; it is not listed in most dictionaries and could confuse international readers. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：IDocsはこの収縮を使用しないでください。それはほとんどの辞書にリストされておらず、国際的な読者を混同することができます。（「グリーンブック」の「廃止予定の使用」。）
$ physical destruction (I) /threat action/ See: secondary definition under "incapacitation".
$ 物理的破壊（I）/脅威の処置/参照：「無能」の下の定義。
$ physical security (I) Tangible means of preventing unauthorized physical access to a system. Examples: Fences, walls, and other barriers; locks, safes, and vaults; dogs and armed guards; sensors and alarm bells. [FP031, R1455] (See: security architecture.)
$ 物理的セキュリティ（i）システムへの不正な物理的アクセスを防止するための有形手段。例：フェンス、壁、その他の障壁。ロック、室内金庫、ボールト。犬と武装警備員。センサーと警報ベル。[FP031、R1455]（セキュリティアーキテクチャを参照）
$ piggyback attack (I) A form of active wiretapping in which the attacker gains access to a system via intervals of inactivity in another user's legitimate communication connection. Sometimes called a "between-the-lines" attack. (See: hijack attack, man-in-the-middle attack.)
$ Piggyback Attack（i）攻撃者が別のユーザーの正当な通信接続における不活動の間隔を介してシステムへのアクセスを獲得するアクティブな盗聴の形式。時々「線の間」攻撃と呼ばれます。（参照：ハイジャック攻撃、中間攻撃。）
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term could confuse international readers.
廃止予定の使用法：この用語を使用するIDocは、その用語が国際読者を混乱させる可能性があるため、定義を述べるべきです。
$ PIN (I) See: personal identification number.
$ PIN（I）は、個人識別番号を参照してください。
$ ping of death (D) A denial-of-service attack that sends an improperly large ICMP echo request packet (a "ping") with the intent of causing the destination system to fail. (See: ping sweep, teardrop.)
$ Deathのping（d）宛先システムを失敗させるという意図を持つ不適切に大きなICMPエコー要求パケット（「ping」）を送信するサービス拒否攻撃。（：Ping Sweeep、Teardrop。）
Deprecated Term: IDOCs SHOULD NOT use this term; instead, use "ping packet overflow attack" or some other term that is specific with regard to the attack mechanism.
廃止予定語：IDocsはこの用語を使用しないでください。代わりに、「PINGパケットオーバーフロー攻撃」または攻撃メカニズムに関して特定の他の用語を使用してください。
Tutorial: This attack seeks to exploit an implementation vulnerability. The IP specification requires hosts to be prepared to accept datagrams of up to 576 octets, but also permits IP datagrams to be up to 65,535 octets long. If an IP implementation does not properly handle very long IP packets, the ping packet may overflow the input buffer and cause a fatal system error.
チュートリアル：この攻撃は実装の脆弱性を悪用しようとしています。IP仕様では、最大576オクテットのデータグラムを受け入れるようにホストを準備する必要がありますが、IPデータグラムは最大65,535オクテットの長さになることもできます。IP実装が非常に長いIPパケットを正しく処理しない場合、pingパケットは入力バッファをオーバーフローし、致命的なシステムエラーを引き起こす可能性があります。
$ ping sweep (I) An attack that sends ICMP echo requests ("pings") to a range of IP addresses, with the goal of finding hosts that can be probed for vulnerabilities. (See: ping of death. Compare: port scan.)
$ ping sweep（i）脆弱性について調べることができるホストを見つけることを目的として、ICMPエコー要求（ "PING"）をさまざまなIPアドレスに送信する攻撃。（死亡のping。比較：ポートスキャン）
$ PKCS (N) See: Public-Key Cryptography Standards.
$ PKCS（N）公開鍵暗号化基準を参照してください。
$ PKCS #5 (N) A standard [PKC05] (see: RFC 2898) from the PKCS series; defines a method for encrypting an octet string with a secret key derived from a password.
$ PKCS＃5（n）PKCSシリーズからの標準[PKC05]（RFC 2898参照）。パスワードから派生した秘密鍵でオクテット文字列を暗号化する方法を定義します。
Tutorial: Although the method can be used for arbitrary octet strings, its intended primary application in public-key cryptography is for encrypting private keys when transferring them from one computer system to another, as described in PKCS #8.
チュートリアル：この方法は任意のオクテット文字列に使用することができますが、公開鍵暗号化における意図された主なアプリケーションは、PKCS＃8で説明されているように、1つのコンピュータシステムから別のコンピュータシステムへの転送時に秘密鍵を暗号化するためのものです。
$ PKCS #7 (N) A standard [PKC07] (see: RFC 2315) from the PKCS series; defines a syntax for data that may have cryptography applied to it, such as for digital signatures and digital envelopes. (See: CMS.)
$ PKCS＃7（n）PKCSシリーズからの標準[PKC07]（RFC 2315参照）。デジタルシグネチャやデジタルエンベロープなど、暗号化が適用される可能性があるデータの構文を定義します。（CMSを参照）
$ PKCS #10 (N) A standard [PKC10] (see: RFC 2986) from the PKCS series; defines a syntax for certification requests. (See: certification request.)
$ PKCS＃10（n）PKCSシリーズからの標準[PKC10]（RFC 2986参照）。認証要求の構文を定義します。（認証依頼を参照してください。）
Tutorial: A PKCS #10 request contains a DN and a public key, and may contain other attributes, and is signed by the entity making the request. The request is sent to a CA, who converts it to an X.509 public-key certificate (or some other form), and returns it, possibly in PKCS #7 format.
チュートリアル：PKCS＃10要求には、DNと公開鍵が含まれており、他の属性を含み、要求を行うエンティティによって署名されています。要求はCAに送信されます。誰がそれをX.509公開鍵証明書（またはその他の形式）に変換し、おそらくPKCS＃7形式で返します。
$ PKCS #11 (N) A standard [PKC11] from the PKCS series; defines CAPI called "Cryptoki" for devices that hold cryptographic information and perform cryptographic functions.
$ PKCS＃11（n）PKCSシリーズからの標準[PKC11]。暗号化情報を保持し、暗号機能を実行するデバイスの「Cryptoki」というCAPIを定義します。
$ PKI (I) See: public-key infrastructure.
$ PKI（i）公開鍵インフラストラクチャーを参照してください。
$ PKINIT (I) Abbreviation for "Public Key Cryptography for Initial Authentication in Kerberos" (RFC 4556). (See: Tutorial under "Kerberos".)
$ PkinIt（i）Kerberosにおける初期認証のための公開鍵暗号化の略語（RFC 4556）。（「Kerberos」の「チュートリアル」を参照してください。）
$ PKIX 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the name of the IETF working group that is specifying an architecture [R3280] and set of protocols [R4210] to provide X.509-based PKI services for the Internet.
$ PKIX 1A。（i）「公開鍵インフラストラクチャ（X.509）」の縮小、Architecture [R3280]を指定しているIETFワーキンググループの名前[R4280]の名前[R4210]のX.509ベースのPKIサービスを提供インターネット。
1b. (I) A collective name for that Internet PKI architecture and associated set of protocols.
1b。（i）そのインターネットPKIアーキテクチャおよび関連するプロトコルのセットの集合名。
Tutorial: The goal of PKIX is to facilitate the use of X.509 public-key certificates in multiple Internet applications and to promote interoperability between different implementations that use those certificates. The resulting PKI is intended to provide a framework that supports a range of trust and hierarchy environments and a range of usage environments. PKIX specifies (a) profiles of the v3 X.509 public-key certificate standards and the v2 X.509 CRL standards for the Internet, (b) operational protocols used by relying parties to obtain information such as certificates or certificate status, (c) management protocols used by system entities to exchange information needed for proper management of the PKI, and (d) information about certificate policies and CPSs, covering the areas of PKI security not directly addressed in the rest of PKIX.
チュートリアル：PKIXの目標は、複数のインターネットアプリケーションでのX.509の公開鍵証明書の使用を容易にし、それらの証明書を使用するさまざまな実装間の相互運用性を促進することです。結果のPKIは、さまざまな信頼環境と階層環境と使用環境の範囲をサポートするフレームワークを提供することを目的としています。PKIXは、Internet（B）証明書や証明書のステータスなどの情報を入手するための依頼者が使用するv3 X.509の公開鍵証明書規格とV2 X.509 CRL規格のプロファイルを指定します（B）。システムエンティティによってシステムエンティティが使用するPKIの適切な管理に必要な情報を交換するための管理プロトコル、および（D）証明書ポリシーおよびCPSSに関する情報を交換し、PKIセキュリティの分野を、PKIXの他のPKIXで直接扱われていません。
$ plain text 1. (I) /noun/ Data that is input to an encryption process. (See: plaintext. Compare: cipher text, clear text.)
$ プレーンテキスト1.（i）/名詞/暗号化プロセスに入力されたデータ。（：平文を参照してください。比較：暗号テキスト、クリアテキスト）。
2. (D) /noun/ Synonym for "clear text".
2. （D）/名詞/「クリアテキスト」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "clear text". Sometimes plain text that is input to an encryption operation is clear text, but other times plain text is cipher text that was output from a previous encryption operation. (See: superencryption.)
非推奨の定義：IDocはこの用語を「クリアテキスト」の同義語として使用しないでください。暗号化操作に入力されるプレーンテキストが明確にテキストであることがある場合がありますが、他の時間プレーンテキストは、以前の暗号化操作から出力された暗号テキストです。（SuperEncryptionを参照してください。）
$ plaintext 1. (O) /noun/ Synonym for "plain text".
$ 平文1.（O）/名詞/「プレーンテキスト」の同義語。
2. (I) /adjective/ Referring to plain text. Usage: Commonly used instead of "plain-text". (Compare: ciphertext, cleartext.)
2. （i）/形容詞/プレーンテキストの参照。使用法：「プレーンテキスト」の代わりに一般的に使用されています。（比較：暗号文、クリアテキスト）
3. (D) /noun/ Synonym for "cleartext".
3. （d）/名詞/「クリアテキスト」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "cleartext". Cleartext data is, by definition, not encrypted; but plaintext data that is input to an encryption operation may be cleartext data or may be ciphertext data that was output from a previous encryption operation. (See: superencryption.)
非推奨の定義：IDocは、この用語を「ClearText」の同義語として使用しないでください。クリアテキストデータは、定義によって暗号化されていません。しかし、暗号化操作に入力される平文データは、クリアテキストデータでもよいし、以前の暗号化操作から出力された暗号文データでもよい。（SuperEncryptionを参照してください。）
$ PLI (I) See: Private Line Interface.
$ PLI（I）参照：プライベートラインインターフェース。
$ PMA (N) See: policy management authority.
$ PMA（N）は、ポリシー管理局を参照してください。
$ Point-to-Point Protocol (PPP) (I) An Internet Standard protocol (RFC 1661) for encapsulation and full-duplex transportation of protocol data packets in OSIRM Layer 3 over an OSIRM Layer 2 link between two peers, and for multiplexing different Layer 3 protocols over the same link. Includes optional negotiation to select and use a peer entity authentication protocol to authenticate the peers to each other before they exchange Layer 3 data. (See: CHAP, EAP, PAP.)
$ ポイントツーポイントプロトコル（I）2つのピア間のOSIRMレイヤ2の間のOSIRMレイヤ2の間のOSIRMレイヤ3のインターネット標準プロトコル（RFC 1661）、および異なるレイヤーを多重化するためのインターネット標準プロトコル（RFC 1661）同じリンクで3つのプロトコル。ピアエンティティ認証プロトコルを選択して使用して、レイヤ3データを交換する前に互いにピアを認証するためのオプションのネゴシエーションが含まれています。（参照：CHAP、EAP、PAP。）
$ Point-to-Point Tunneling Protocol (PPTP) (I) An Internet client-server protocol (RFC 2637) (originally developed by Ascend and Microsoft) that enables a dial-up user to create a virtual extension of the dial-up link across a network by tunneling PPP over IP. (See: L2TP.)
$ ポイントツーポイントトンネリングプロトコル（I）ダイヤルアップユーザがダイヤルアップリンクの仮想拡張を作成できるようにするインターネットクライアント - サーバプロトコル（RFC 2637）（RFC 2637）IP上のPPPをトンネリングすることによるネットワーク。（：L2TPを参照してください。）
Tutorial: PPP can encapsulate any IPS Network Interface Layer protocol or OSIRM Layer 3 protocol. Therefore, PPTP does not specify security services; it depends on protocols above and below it to provide any needed security. PPTP makes it possible to divorce the location of the initial dial-up server (i.e., the PPTP Access Concentrator, the client, which runs on a special-purpose host) from the location at which the dial-up protocol (PPP) connection is terminated and access to the network is provided (i.e., at the PPTP Network Server, which runs on a general-purpose host).
チュートリアル：PPPは、IPSネットワークインターフェイス層プロトコルまたはOSIRMレイヤ3プロトコルをカプセル化できます。したがって、PPTPはセキュリティサービスを指定しません。それは必要なセキュリティを提供するためにそれを上下のプロトコルに依存します。PPTPは、ダイヤルアッププロトコル（PPP）接続がある場所から、初期ダイヤルアップサーバー（つまり、PPTPアクセスコンセントレータ、特殊目的ホスト上で実行されるクライアント）の離婚を可能にします。終了してネットワークへのアクセスが提供されます（つまり、汎用ホスト上で実行されるPPTPネットワークサーバーで）。
$ policy 1a. (I) A plan or course of action that is stated for a system or organization and is intended to affect and direct the decisions and deeds of that entity's components or members. (See: security policy.)
$ ポリシー1A。（i）システムまたは組織に述べられており、その事業体のコンポーネントまたはメンバーの決定および行為に影響を及ぼし、指示することを目的としています。（セキュリティポリシーを参照してください。）
1b. (O) A definite goal, course, or method of action to guide and determine present and future decisions, that is implemented or executed within a particular context, such as within a business unit. [R3198]
1b。（o）事業部内などの特定の文脈内で実施または実行される、現在および将来の決定を指示および決定するための明確な目標、コース、または行動方法。[R3198]
Deprecated Abbreviation: IDOCs SHOULD NOT use "policy" as an abbreviation of either "security policy" or "certificate policy".
廃止予定の省略形：IDOCは、「セキュリティポリシー」または「証明書ポリシー」のいずれかの略語として「ポリシー」を使用しないでください。
Instead, to avoid misunderstanding, use a fully qualified term, at least at the point of first usage.
代わりに、誤解を避けるために、少なくとも最初の使用の時点で完全修飾語を使用してください。
Tutorial: The introduction of new technology to replace traditional systems can result in new systems being deployed without adequate policy definition and before the implications of the new technology are fully understand. In some cases, it can be difficult to establish policies for new technology before the technology has been operationally tested and evaluated. Thus, policy changes tend to lag behind technological changes, such that either old policies impede the technical innovation, or the new technology is deployed without adequate policies to govern its use.
チュートリアル：従来のシステムに代わる新しいテクノロジの導入は、適切なポリシー定義がなく、新しいテクノロジの影響が十分に理解される前に、新しいシステムが展開される可能性があります。場合によっては、技術が活動的にテストされ評価されている前に、新技術のための政策を確立することが困難になる可能性があります。したがって、政策の変化は技術的な変化の背後に遅れる傾向があり、そのように古い政策のいずれかが技術的革新を妨げる、または新しい技術がその使用を支配するために適切な政策なしで展開される。
When new technology changes the ways that things are done, new "procedures" must be defined to establish operational guidelines for using the technology and achieving satisfactory results, and new "practices" must be established for managing new systems and monitoring results. Practices and procedures are more directly coupled to actual systems and business operations than are polices, which tend to be more abstract. - "Practices" define how a system is to be managed and what controls are in place to monitor the system and detect abnormal behavior or quality problems. Practices are established to ensure that a system is managed in compliance with stated policies. System audits are primarily concerned with whether or not practices are being followed. Auditors evaluate the controls to make sure they conform to accepted industry standards, and then confirm that controls are in place and that control measurements are being gathered. Audit trails are examples of control measurements that are recorded as part of system operations. - "Procedures" define how a system is operated, and relate closely to issues of what technology is used, who the operators are, and how the system is deployed physically. Procedures define both normal and abnormal operating circumstances. - For every control defined by a practice statement, there should be corresponding procedures to implement the control and provide ongoing measurement of the control parameters. Conversely, procedures require management practices to insure consistent and correct operational behavior.
新しい技術が行われる方法を変更すると、新しい「手順」は、技術を使用して満足のいく結果を実現するための運用ガイドラインを確立するために定義されなければならず、新しいシステムを管理し、結果を監視するために新しい「慣行」を確立しなければなりません。慣例や手順は、政治化がより抽象的になる傾向があるポリシーよりも実際のシステムや事業運営に直接結合されています。 - システムを監視し、異常な行動や品質の問題を検出するためのシステムの管理方法を定義し、どのような制御が施されているかを定義します。システムが述べられたポリシーに準拠して管理されるように、慣行が確立されています。システム監査は、主に実践が続いているかどうかに関係しています。監査人は、受け入れられている業界標準に準拠していることを確認するためにコントロールを評価し、そのコントロールが所定の位置にあることを確認し、その制御測定が集められていることを確認します。監査証跡は、システム操作の一部として記録されている制御測定の例です。 - システムがどのように操作されるかを定義し、オペレータが使用されている技術者、およびシステムの展開方法の問題と密接に関連しています。手順は、通常の動作状況と異常な動作状況の両方を定義します。 - 練習文によって定義されたすべての制御については、制御を実装し、制御パラメータを継続的に測定するための対応する手順があるべきです。逆に、手順では、一貫した正しい運用行動を保証するための管理方法が必要です。
$ policy approval authority (D) /PKI/ Synonym for "policy management authority". [PAG]
$ 「ポリシー管理局」の方針承認局（D）/ PKI /同義語。[PAG]
Deprecated Term: IDOCs SHOULD NOT use this term as synonym for "policy management authority". The term suggests a limited, passive role that is not typical of PMAs.
廃止予定語：IDocは、この用語を「ポリシー管理局」の同義語として使用しないでください。この用語は、PMAに典型的ではない限られた、受動的な役割を示唆しています。
$ policy approving authority (PAA) (O) /MISSI/ The top-level signing authority of a MISSI certification hierarchy. The term refers both to that authoritative office or role and to the person who plays that role. (See: policy management authority, root registry.)
$ Policy Approving Authority（PAA）/ MISSI / MISSI認証階層のトップレベルの署名権限。この用語は、その権威ある事務所や役割の両方を指し、その役割を果たす人に。（「ポリシー管理局、ルートレジストリ」を参照してください。
Tutorial: A MISSI PAA (a) registers MISSI PCAs and signs their X.509 public-key certificates, (b) issues CRLs but does not issue a CKL, and (c) may issue cross-certificates to other PAAs.
チュートリアル：Missi PAA（A）はMissi PCAを登録し、それらのX.509公開鍵証明書、（b）を発行するがCKLを発行しない。（c）は他のPAAに相互証明書を発行することができます。
$ policy authority (D) /PKI/ Synonym for "policy management authority". [PAG]
$ 「ポリシー管理局」の方針局（D）/ PKI /同義語。[PAG]
Deprecated Term: IDOCs SHOULD NOT use this term as synonym for "policy management authority". The term is unnecessarily vague and thus may be confused with other PKI entities, such as CAs and RAs, that enforce of apply various aspects of PKI policy.
廃止予定語：IDocは、この用語を「ポリシー管理局」の同義語として使用しないでください。この用語は不必要に曖昧であり、したがってCASやRASなどの他のPKIエンティティと混同され、PKIポリシーのさまざまな側面の適用を強制することができます。
$ policy certification authority (Internet PCA) (I) An X.509-compliant CA at the second level of the Internet certification hierarchy, under the IPRA. Each PCA operates under its published security policy (see: certificate policy, CPS) and within constraints established by the IPRA for all PCAs. [R1422]. (See: policy creation authority.)
$ ポリシー認証局（Internet PCA）（I）IPRAの下の2番目のレベルのインターネット認定階層のX.509準拠のCA。各PCAは、公開されているセキュリティポリシー（証明書ポリシー、CPS）およびすべてのPCASのIPRAによって確立された制約内で動作します。[R1422]。（「ポリシー作成局」を参照してください。
$ policy creation authority (MISSI PCA) (O) /MISSI/ The second level of a MISSI certification hierarchy; the administrative root of a security policy domain of MISSI users and other, subsidiary authorities. The term refers both to that authoritative office or role and to the person who fills that office. (See: policy certification authority.)
$ 政策創造機関（MISSI PCA）（O）/ MISSI /第2レベルのMISSI認証階層。Missiユーザーのセキュリティポリシードメインの管理ルートおよびその他の子会社。この用語は、その権威ある事務所または役割の両方を指し、その事務所を埋める人に。（Policy Certification Authorityを参照してください。）
Tutorial: A MISSI PCA's certificate is issued by a PAA. The PCA registers the CAs in its domain, defines their configurations, and issues their X.509 public-key certificates. (The PCA may also issue certificates for SCAs, ORAs, and other end entities, but a PCA does not usually do this.) The PCA periodically issues CRLs and CKLs for its domain.
チュートリアル：Missi PCAの証明書はPAAによって発行されます。PCAはCASをそのドメインに登録し、それらの構成を定義し、それらのX.509公開鍵証明書を発行します。（PCAは、SCAS、ORAS、およびその他のエンドエンティティの証明書を発行することもできますが、PCAは通常これを実行するわけではありません。）PCAは定期的にそのドメインのCRLとCKLSを発行します。
$ policy management authority (PMA) (I) /PKI/ A person, role, or organization within a PKI that is responsible for (a) creating or approving the content of the certificate policies and CPSs that are used in the PKI; (b) ensuring the administration of those policies; and (c) approving any cross-certification or interoperability agreements with CAs external to the PKI and any related policy mappings. The PMA may also be the accreditor for the PKI as a whole or for some of its components or applications. [DoD9, PAG] (See: policy approving authority.)
PKIの内容を作成または承認するPKI内の$ Policy Management Authority（PMA）/ PKI / A個人、役割、または組織。（b）それらの政策の管理を確実にする。（c）PKIおよび関連するポリシーマッピングの外部のCASとの間で、交差認証または相互運用性契約を承認する。PMAは、PKI全体として、またはその一部のコンポーネントまたは用途のためのAccreditorでもよい。[DOD9、PAG]（Policy Apploviing Authorityを参照）
Example: In the U.S. Department of Defense, an organization called the Policy Management Authority is responsible for DoD PKI [DoD9].
例：米国国防総省では、政策管理局と呼ばれる組織がDOD PKI [DOD9]を担当しています。
$ policy mapping (I) "Recognizing that, when a CA in one domain certifies a CA in another domain, a particular certificate policy in the second domain may be considered by the authority of the first domain to be equivalent (but not necessarily identical in all respects) to a particular certificate policy in the first domain." [X509]
$ ポリシーマッピング（i）「1つのドメイン内のCAが別のドメイン内のCAを認証すると、第2のドメイン内の特定の証明書ポリシーが同等のものになるように第1のドメインの権限によって考慮され得る（ただし、全く同一ではない）ということを認識する。最初のドメインの特定の証明書ポリシーに尊重します。」[X509]
$ policy rule (I) A building block of a security policy; it (a) defines a set of system conditions and (b) specifies a set of system actions that are to be performed if those conditions occur. [R3198]
$ ポリシールール（i）セキュリティポリシーのビルディングブロック。IT（a）システム条件のセットを定義し、（b）それらの条件が発生した場合に実行されるシステムアクションのセットを指定します。[R3198]
$ POP3 (I) See: Post Office Protocol, version 3.
$ POP3（i）郵便局プロトコル、バージョン3を参照してください。
$ POP3 APOP (I) A POP3 command (better described as a transaction type, or subprotocol) by which a POP3 client optionally uses a keyed hash (based on MD5) to authenticate itself to a POP3 server and, depending on the server implementation, to protect against replay attacks. (See: CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.)
$ POP3 APOP（i）POP3クライアントがオプションでPOP3サーバーを使用してPOP3サーバーに認証し、サーバーの実装に応じて、POP3クライアントを使用するPOP3コマンド（トランザクションタイプ、またはサブプロトコルとして説明されています）。再生攻撃から保護する。（参照：CRAM、POP3 AUTH、IMAP4認証。）
Tutorial: The server includes a unique time stamp in its greeting to the client. The subsequent APOP command sent by the client to the server contains the client's name and the hash result of applying MD5 to a string formed from both the time stamp and a shared secret value that is known only to the client and the server. APOP was designed to provide an alternative to using POP3's USER and PASS (i.e., password) command pair, in which the client sends a cleartext password to the server.
チュートリアル：サーバーには、クライアントへのあいさつに一意のタイムスタンプが含まれています。クライアントからサーバに送信された後続のAPOPコマンドには、クライアントの名前と、タイムスタンプとクライアントとサーバだけが知られている共有秘密値の両方から形成された文字列にMD5を適用したハッシュ結果が含まれています。APOPは、POP3のユーザとパス（すなわちパスワード）コマンドペアを使用するように設計され、クライアントはクリアテキストパスワードをサーバに送信します。
$ POP3 AUTH (I) A POP3 command [R1734] (better described as a transaction type, or subprotocol) by which a POP3 client optionally proposes a mechanism to a POP3 server to authenticate the client to the server and provide other security services. (See: POP3 APOP, IMAP4 AUTHENTICATE.)
$ POP3 Command [R1734]（Transaction Typeとして説明されている（トランザクションタイプ、またはサブプロトコルとして説明されています）.POP3クライアントは、ClientをPOP3サーバーに認証し、他のセキュリティサービスを提供するためのPOP3サーバーへのメカニズムを提案します。（参照：POP3 APOP、IMAP4認証を参照してください。）
Tutorial: If the server accepts the proposal, the command is followed by performing a challenge-response authentication protocol and, optionally, negotiating a protection mechanism for subsequent POP3 interactions. The security mechanisms used by POP3 AUTH are those used by IMAP4.
チュートリアル：サーバーがプロポーザルを受け入れると、コマンドの後にチャレンジ応答認証プロトコルを実行し、オプションで、後続のPOP3インタラクションの保護メカニズムをネゴシエートします。POP3 AUTHによって使用されるセキュリティメカニズムは、IMAP4によって使用されるものです。
$ port scan (I) A technique that sends client requests to a range of service port addresses on a host. (See: probe. Compare: ping sweep.)
$ ポートスキャン（i）クライアント要求をホスト上のさまざまなサービスポートアドレスに送信する手法。（プローブを参照してください。比較：Ping Sweeep。）
Tutorial: A port scan can be used for pre-attack surveillance, with the goal of finding an active port and subsequently exploiting a known vulnerability of that port's service. A port scan can also be used as a flooding attack.
チュートリアル：アクティブなポートを見つけ、その後そのポートのサービスの既知の脆弱性を悪用することを目的として、ポートスキャンを攻撃前監視に使用できます。ポートスキャンはフラッディング攻撃としても使用できます。
$ positive authorization (I) The principle that a security architecture should be designed so that access to system resources is permitted only when explicitly granted; i.e., in the absence of an explicit authorization that grants access, the default action shall be to refuse access. (See: authorization, access.)
$ 正の承認（i）システムリソースへのアクセスが明示的に付与された場合にのみ許可されるようにセキュリティアーキテクチャを設計する必要があるという原則。すなわち、アクセスを許可する明示的な承認がない場合、デフォルトの行動はアクセスを拒否するものとします。（承認、アクセス）を参照してください。
$ POSIX (N) Portable Operating System Interface for Computer Environments, a standard [FP151, I9945] (originally IEEE Standard P1003.1) that defines an operating system interface and environment to support application portability at the source code level. It is intended to be used by both application developers and system implementers.
$ POSIX（N）ソースコードレベルでのアプリケーションの移植性をサポートするオペレーティングシステムのインタフェースと環境を定義する標準[FP151、I9945]（もともとIEEE標準P1003.1）のためのPOSIX環境のためのポータブルオペレーティングシステムインタフェース。アプリケーション開発者とシステム実装者の両方で使用されることを意図しています。
Tutorial: P1003.1 supports security functionality like that on most UNIX systems, including discretionary access control and privileges. IEEE Draft Standard P1003.6 specifies additional functionality not provided in the base standard, including (a) discretionary access control, (b) audit trail mechanisms, (c) privilege mechanisms, (d) mandatory access control, and (e) information label mechanisms.
チュートリアル：P1003.1は、任意のアクセス制御と特権を含む、ほとんどのUNIXシステム上のセキュリティ機能をサポートしています。IEEEドラフト標準P1003.6は、（a）裁量アクセス制御、（b）監査証跡メカニズム、（c）特権メカニズム、（d）必須アクセス制御、（e）情報ラベルなど、基本規格で提供されていない追加機能を指定します。メカニズム
$ Post Office Protocol, version 3 (POP3) (I) An Internet Standard protocol (RFC 1939) by which a client workstation can dynamically access a mailbox on a server host to retrieve mail messages that the server has received and is holding for the client. (See: IMAP4.)
$ 郵便局プロトコル（POST3）（i）クライアントワークステーションがサーバーホスト上のメールボックスに動的にアクセスできるインターネット標準プロトコル（RFC 1939）は、サーバーが受信してクライアントを保持しているメールメッセージを取得できます。（：IMAP4を参照してください。）
Tutorial: POP3 has mechanisms for optionally authenticating a client to a server and providing other security services. (See: POP3 APOP, POP3 AUTH.)
チュートリアル：POP3には、オプションでクライアントをサーバーに認証し、他のセキュリティサービスを提供するためのメカニズムがあります。（：POP3 APOP、POP3認証を参照）
$ PPP (I) See: Point-to-Point Protocol.
$ PPP（i）ポイントツーポイントプロトコルを参照してください。
$ PPTP (I) See: Point-to-Point Tunneling Protocol.
$ PPTP（i）ポイントツーポイントトンネリングプロトコルを参照してください。
$ preauthorization (N) /PKI/ A CAW feature that enables certification requests to be automatically validated against data provided in advance to the CA by an authorizing entity.
$ Prauthorization（N）/ PKI / A CAW機能は、認証要因によって事前に提供されたデータに対して自動的に検証されることを可能にするCAW機能を認証エンティティによって自動的に検証できるようにする。
$ precedence 1. (I) /information system/ A ranking assigned to events or data objects that determines the relative order in which they are processed.
$ 優先順位1.（i）/情報システム/情報システム/それらが処理される相対順序を決定するイベントまたはデータオブジェクトに割り当てられたランキング。
2. (N) /communication system/ A designation assigned to a communication (i.e., packet, message, data stream, connection, etc.) by the originator to state the importance or urgency of that communication versus other communications, and thus indicate to the transmission system the relative order of handling, and indicate to the receiver the order in which the communication is to be noted. [F1037] (See: availability, critical, preemption.)
2. （n）/通信システム/発信者による通信（すなわち、パケット、メッセージ、データストリーム、接続など）に割り当てられている指定された通信対他の通信に対するその通信の重要度または緊急性を述べること、したがって送信に示すような指定システムの相対的な順序は、受信機に通信が注目される順序を示す。[F1037]（「空室状況、重大、プリエンプション」を参照）
Example: The "Precedence" subfield of the "Type of Service" field of the IPv4 header supports the following designations (in descending order of importance): 111 Network Control, 110 Internetwork Control, 101 CRITIC/ECP (Critical Intelligence Communication/Emergency Command Precedence), 100 Flash Override, 011 Flash, 010 Immediate, 001 Priority, and 000 Routine. These designations were adopted from U.S. DoD systems that existed before ARPANET.
例：IPv4ヘッダーの「サービスの種類」フィールドの「優先」サブフィールドは、（重要度の降順で）次の指定をサポートしています.111ネットワーク制御、110インターネットワークコントロール、101批評家/ ECP（重要Intelligence Communication /緊急コマンド）優先順位）、100フラッシュオーバーライド、011フラッシュ、010即時、001優先順位、および000ルーチン。これらの指定は、アルパニットの前に存在していた米国のDODシステムから採用されました。
$ preemption (N) The seizure, usually automatic, of system resources that are being used to serve a lower-precedence communication, in order to serve immediately a higher-precedence communication. [F1037]
$ プリエンプション（n）すぐに優先順位の高い通信を提供するために、通常、優先順位の低い通信を果たすために使用されているシステムリソースの発作（通常は自動）。[F1037]
$ Pretty Good Privacy(trademark) (PGP(trademark)) (O) Trademarks of Network Associates, Inc., referring to a computer program (and related protocols) that uses cryptography to provide data security for electronic mail and other applications on the Internet. (Compare: DKIM, MOSS, MSP, PEM, S/MIME.)
$ かなり良いプライバシー（商標）（PGP（登録商標））（o）ネットワークアソシエイツ社の商標は、電子メールやその他のアプリケーションのためのデータセキュリティおよびその他のアプリケーションを提供するコンピュータプログラム（および関連プロトコル）を指す。（比較：DKIM、MOSS、MSP、PEM、S / MIME）
Tutorial: PGP encrypts messages with a symmetric algorithm (originally, IDEA in CFB mode), distributes the symmetric keys by encrypting them with an asymmetric algorithm (originally, RSA), and creates digital signatures on messages with a cryptographic hash and an asymmetric encryption algorithm (originally, MD5 and RSA). To establish ownership of public keys, PGP depends on the "web of trust".
チュートリアル：PGPは対称アルゴリズムでメッセージを暗号化します（もともとCFBモードのアイデア）、非対称アルゴリズム（もともとRSA）で暗号化して対称キーを配布し、暗号化ハッシュと非対称暗号化アルゴリズムを持つメッセージにデジタルシグネチャを作成します。（もともとMD5とRSA）。公開鍵の所有権を確立するために、PGPは「信頼のWeb」によって異なります。
$ prevention (I) See: secondary definition under "security".
$ 予防（i）「セキュリティ」の下の二次定義を参照してください。
$ primary account number (PAN) (O) /SET/ "The assigned number that identifies the card issuer and cardholder. This account number is composed of an issuer identification number, an individual account number identification, and an accompanying check digit as defined by ISO 7812-1985." [SET2, I7812] (See: bank identification number.)
$ プライマリ口座番号（PAN）（O）/ SET / "カード発行者とカード保有者を識別する割り当てられた番号。この口座番号は、ISOで定義されている発行者識別番号、個々の口座番号識別、および付随するチェック数字で構成されています。7812-1985。」[SET2、I7812]（銀行識別番号を参照）
Tutorial: The PAN is embossed, encoded, or both on a magnetic-strip-based credit card. The PAN identifies the issuer to which a transaction is to be routed and the account to which it is to be applied unless specific instructions indicate otherwise. The authority that assigns the BIN part of the PAN is the American Bankers Association.
チュートリアル：パンは磁気ストリップベースのクレジットカード上のエンボス加工、符号化、またはその両方です。PANは、他の指示を示していない限り、トランザクションがルーティングされるべき発行者と、それが適用されるアカウントを識別します。PANのビン部分を割り当てる権限は、アメリカンバンカー協会です。
$ principal (I) A specific identity claimed by a user when accessing a system.
$ 校長（i）システムにアクセスするときにユーザーが主張した特定の身元。
Usage: Usually understood to be an identity that is registered in and authenticated by the system; equivalent to the notion of login account identifier. Each principal is normally assigned to a single user, but a single user may be assigned (or attempt to use) more than one principal. Each principal can spawn one or more subjects, but each subject is associated with only one principal. (Compare: role, subject, user.)
使用法：通常、システムによって登録され認証されているアイデンティティであると理解されていました。ログインアカウントIDの概念と同等です。各プリンシパルは通常単一のユーザーに割り当てられますが、1つのユーザーが複数のプリンシパルを割り当てる（または使用しようとしています）。各主体は1つ以上の被験者を出現することができますが、各件名は1つのプリンシパルのみに関連付けられています。（比較：役割、件名、ユーザー。）
(I) /Kerberos/ A uniquely identified (i.e., uniquely named) client or server instance that participates in a network communication.
（i）/ kerberos /ネットワーク通信に参加する一意的に識別された（すなわち、一意的に名前が付けられた）クライアントまたはサーバインスタンス。
$ priority (I) /information system/ Precedence for processing an event or data object, determined by security importance or other factors. (See: precedence.)
$ Securityの重要度またはその他の要因によって決定されたイベントまたはデータオブジェクトを処理するための優先順位（I）/情報システム/優先順位。（参照：優先順位。）
$ privacy 1. (I) The right of an entity (normally a person), acting in its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share its personal information with others. (See: HIPAA, personal information, Privacy Act of 1974. Compare: anonymity, data confidentiality.) [FP041]
$ プライバシー1.（i）企業がその環境と対話する程度を決定するための企業の権利（通常は人）の権利は、企業がその個人情報を共有している意思がある程度を含む。他の人と。（：HIPAA、個人情報、1974年のプライバシー行為。比較：匿名性、データ機密性。）[FP041]
2. (O) "The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed." [I7498-2]
2. （O）「個人の権利は、それらに関連する情報を管理または影響を与えることができ、その情報がどの情報に開示される可能性があるか。[I7498-2]
3. (D) Synonym for "data confidentiality".
3. （d）「データ機密性」の同義語。
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "data confidentiality" or "data confidentiality service", which are different concepts. Privacy is a reason for security rather than a kind of security. For example, a system that stores personal data needs to protect the data to prevent harm, embarrassment, inconvenience, or unfairness to any person about whom data is maintained, and to protect the person's privacy. For that reason, the system may need to provide data confidentiality service.
非推奨の定義：IDocは、この用語を「データ機密保持」または「データ機密保持サービス」の同義語として使用しないでください。プライバシーは、一種のセキュリティではなくセキュリティの理由です。例えば、個人データを格納するシステムは、データを保護するためにデータを保護するために、データを維持し、その人のプライバシーを保護するために、害、恥ずかしさ、不便、または不公平さを防ぐために。そのため、システムはデータ機密保持サービスを提供する必要があるかもしれません。
Tutorial: The term "privacy" is used for various separate but related concepts, including bodily privacy, territorial privacy, personal information privacy, and communication privacy. IDOCs are expected to address only communication privacy, which in this Glossary is defined primarily by "data confidentiality" and secondarily by "data integrity".
チュートリアル：「プライバシー」という用語は、身体のプライバシー、領土のプライバシー、個人情報のプライバシー、およびコミュニケーションのプライバシーを含む、さまざまな別のが関連する概念に使用されています。IDOCはコミュニケーションのプライバシーのみに対処することが期待されており、この用語集では主に「データの機密性」と「データの整合性」によって定義されます。
IDOCs are not expected to address information privacy, but this Glossary provides definition 1 for that concept because personal information privacy is often confused with communication privacy. IDOCs are not expected to address bodily privacy or territorial privacy, and this Glossary does not define those concepts because they are not easily confused with communication privacy.
IDocは情報のプライバシーに対処することは期待されていませんが、この用語集はその概念の定義1を提供します。個人情報のプライバシーは、コミュニケーションのプライバシーと混同されることがよくあります。IDocは、身体のプライバシーまたは領土のプライバシーに対処することは期待されておらず、この用語集はそれらの概念をコミュニケーションのプライバシーと容易に混同していないため、それらの概念を定義しません。
$ Privacy Act of 1974 (O) A U.S. Federal law (Section 552a of Title 5, United States Code) that seeks to balance the U.S. Government's need to maintain data about individuals with the rights of individuals to be protected against unwarranted invasions of their privacy stemming from federal agencies' collection, maintenance, use, and disclosure of personal data. (See: privacy.)
$ 1974年のプライバシー法（O）米国政府のバランスをとる米国政府のバランスをとる米国政府の政府のバランスをとることを目的としている個人の権利を保護するためのデータを維持することを目的とした個人の権利を維持することを目的としている連邦機関のコレクション、メンテナンス、使用、および個人データの開示から。（：プライバシーを参照してください。）
Tutorial: In 1974, the U.S. Congress was concerned with the potential for abuses that could arise from the Government's increasing use of computers to store and retrieve personal data. Therefore, the Act has four basic policy objectives: - To restrict disclosure of personally identifiable records maintained by Federal agencies. - To grant individuals increased rights of access to Federal agency records maintained on themselves. - To grant individuals the right to seek amendment of agency records maintained on themselves upon a showing that the records are not accurate, relevant, timely, or complete. - To establish a code of "fair information practices" that requires agencies to comply with statutory norms for collection, maintenance, and dissemination of records.
チュートリアル：1974年に、米国議会は、政府が政府のコンピュータの増加した使用が個人データを記憶して検索する可能性がある虐待の可能性を心配していました。したがって、その行為には4つの基本的な政策目標があります。 - 連邦機関によって維持されている個人識別可能な記録の開示を制限する。 - 個人が連邦機関の記録へのアクセス権を自分で維持する権利を増やす。 - レコードが正確、関連性、タイムリー、または完全ではないことを示す局所レコードの修正を維持する権利を個人に付与すること。 - レコードの収集、メンテナンス、および普及のための法定規範に準拠する機関の「公正な情報慣行」のコードを確立すること。
$ Privacy Enhanced Mail (PEM) (I) An Internet protocol to provide data confidentiality, data integrity, and data origin authentication for electronic mail. [R1421, R1422]. (Compare: DKIM, MOSS, MSP, PGP, S/MIME.)
$ Privacy Enhanced Mail（PEM）（i）電子メールのデータ機密性、データの整合性、およびデータの原点認証を提供するためのインターネットプロトコル。[R1421、R1422]。（比較：DKIM、MOSS、MSP、PGP、S / MIME）
Tutorial: PEM encrypts messages with a symmetric algorithm (originally, DES in CBC mode), provides distribution for the symmetric keys by encrypting them with an asymmetric algorithm (originally, RSA), and signs messages with an asymmetric encryption algorithm over a cryptographic hash (originally, RSA over either MD2 or MD5). To establish ownership of public keys, PEM uses a certification hierarchy, with X.509 public-key certificates and X.509 CRLs that are signed with an asymmetric encryption algorithm over a cryptographic hash (originally, RSA over MD2).
チュートリアル：PEMは対称アルゴリズムでメッセージを暗号化します（もともと、CBCモードではDES）、非対称アルゴリズム（もともとRSA）で暗号化し、暗号化ハッシュを介して非対称暗号化アルゴリズムでメッセージをサインすることによって、対称キーの配布を提供します。元々、MD2またはMD5のどちらかのRSA）。公開鍵の所有権を確立するために、PEMは認証階層を使用しており、X.509の公開鍵証明書と暗号化ハッシュを介して非対称暗号化アルゴリズムで署名されているX.509 CRL（もともと、MD2上のRSA）。
PEM is designed to be compatible with a wide range of key management methods, but is limited to specifying security services only for text messages and, like MOSS, has not been widely implemented in the Internet.
PEMは、幅広い鍵管理方法と互換性があるように設計されていますが、テキストメッセージのみにセキュリティサービスを指定することに限定されています。
$ private component (I) Synonym for "private key".
$ プライベートコンポーネント（i）「秘密鍵」の同義語。
Deprecated Usage: In most cases, IDOCs SHOULD NOT use this term; instead, to avoid confusing readers, use "private key". However, the term MAY be used when discussing a key pair; e.g., "A key pair has a public component and a private component."
廃止予定の使用法：ほとんどの場合、IDocはこの用語を使用しないでください。代わりに、読者を混乱させることを避けるために、「秘密鍵」を使用してください。しかしながら、鍵ペアを議論するときに用語を使用することができる。例えば、「鍵ペアは公開コンポーネントとプライベートコンポーネントを持っています」。
$ private extension (I) See: secondary definition under "extension".
$ Private Extension（i）「拡張子」の下の2次定義を参照してください。
$ private key 1. (I) The secret component of a pair of cryptographic keys used for asymmetric cryptography. (See: key pair, public key, secret key.)
$ 秘密鍵1.（i）非対称暗号化に使用される一対の暗号鍵の秘密成分。（参照：キーペア、公開鍵、秘密鍵）
2. (O) In a public key cryptosystem, "that key of a user's key pair which is known only by that user." [X509]
2. （O）公開鍵暗号システムでは、そのユーザーだけが知られているユーザーの鍵ペアのその鍵。[X509]
$ Private Line Interface (PLI) (I) The first end-to-end packet encryption system for a computer network, developed by BBN starting in 1975 for the U.S. DoD, incorporating U.S. Government-furnished, military-grade COMSEC equipment (TSEC/KG-34). [B1822] (Compare: IPLI.)
$ プライベートラインインタフェース（I）1975年から開発されたBBNが開発したコンピュータネットワーク用の最初のエンドツーエンドパケット暗号化システム（TSEC / KG）-34）。[B1822]（比較：IPLI）
$ privilege 1a. (I) /access control/ A synonym for "authorization". (See authorization. Compare: permission.)
$ 特権1A。（i）/アクセス制御/「承認」の同義語。（承認を参照してください。比較：許可を比較してください。）
1b. (I) /computer platform/ An authorization to perform a security-relevant function in the context of a computer's operating system.
1b。（i）/コンピュータプラットフォーム/コンピュータのオペレーティングシステムのコンテキストでセキュリティ関連の関数を実行するための許可。
$ privilege management infrastructure (O) "The infrastructure able to support the management of privileges in support of a comprehensive authorization service and in relationship with a" PKI; i.e., processes concerned with attribute certificates. [X509]
$ 特権管理インフラストラクチャ（O） "インフラストラクチャは、包括的な承認サービスと「PKIとの関係」の特権の管理をサポートできるようにすることができる。すなわち、属性証明書に関するプロセス。[X509]
Deprecated Usage: IDOCs SHOULD NOT use this term with this definition. This definition is vague, and there is no consensus on a more specific one.
廃止予定の使用法：IDOCはこの定義でこの用語を使用しないでください。この定義は曖昧であり、より具体的なものにはコンセンサスはありません。
$ privileged process (I) A computer process that is authorized (and, therefore, trusted) to perform some security-relevant functions that ordinary processes are not. (See: privilege, trusted process.)
$ 特権プロセス（i）通常のプロセスが正しくないいくつかのセキュリティ関連の機能を実行するために許可されているコンピュータプロセス（したがって、信頼されている）。（：特権、信頼されたプロセス。）
$ privileged user (I) An user that has access to system control, monitoring, or administration functions. (See: privilege, /UNIX/ under "root", superuser, user.)
$ 特権ユーザー（i）システム制御、監視、または管理機能にアクセスできるユーザー。（：特権、/ UNIX /「root」、スーパーユーザー、ユーザー。）
Tutorial: Privileged users include the following types: - Users with near or complete control of a system, who are authorized to set up and administer user accounts, identifiers, and authentication information, or are authorized to assign or change other users' access to system resources. - Users that are authorized to change control parameters (e.g., network addresses, routing tables, processing priorities) on routers, multiplexers, and other important equipment. - Users that are authorized to monitor or perform troubleshooting for a system's security functions, typically using special tools and features that are not available to ordinary users.
チュートリアル：特権ユーザーには、次のようなタイプが含まれます。リソース - ルータ、マルチプレクサ、および他の重要な機器に関する制御パラメータ（例えば、ネットワークアドレス、ルーティングテーブル、処理優先順位）を変更することを許可されているユーザー。 - システムのセキュリティ機能のトラブルシューティングを監視または実行することを許可されているユーザーは、通常は通常のユーザーが利用できない特別なツールと機能を使用しています。
$ probe (I) /verb/ A technique that attempts to access a system to learn something about the system. (See: port scan.)
$ プローブ（i）/動詞/システムにアクセスしようとするテクニック。（Port Scanを参照してください。）
Tutorial: The purpose of a probe may be offensive, e.g., an attempt to gather information for circumventing the system's protections; or the purpose may be defensive, e.g., to verify that the system is working properly.
チュートリアル：プローブの目的は、システムの保護を回避するための情報を集めるための試みです。あるいは目的は、システムが正しく機能していることを確認するために、防御的であるかもしれません。
$ procedural security (D) Synonym for "administrative security".
$ 手続き型セキュリティ（D）「管理セキュリティ」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for "administrative security". The term may be misleading because any type of security may involve procedures, and procedures may be either external to the system or internal. Instead, use "administrative security", "communication security", "computer security", "emanations security", "personnel security", "physical security", or whatever specific type is meant. (See: security architecture.)
廃止予定の用語：IDocは、この用語を「管理セキュリティ」の同義語として使用しないでください。任意の種類のセキュリティが手順を含み得るので、用語は誤解を招く可能性があり、そして手順はシステムまたは内部の外部であり得る。代わりに、「管理セキュリティ」、「通信セキュリティ」、「コンピュータセキュリティ」、「エメテーションセキュリティ」、「人事セキュリティ」、「物理セキュリティ」、または特定の種類が何でも構いません。（セキュリティアーキテクチャを参照してください。）
$ profile See: certificate profile, protection profile.
$ プロファイル参照：証明書プロファイル、保護プロファイル。
$ proof-of-possession protocol (I) A protocol whereby a system entity proves to another that it possesses and controls a cryptographic key or other secret information. (See: zero-knowledge proof.)
$ 所有権証明プロトコル（i）システムエンティティが、それが暗号化キーまたは他の秘密情報を所有し制御する別のものに証明されているプロトコル。（参照：ゼロ知識の証明）
$ proprietary (I) Refers to information (or other property) that is owned by an individual or organization and for which the use is restricted by that entity.
$ 独自の（i）は、個人または組織によって所有されており、そのエンティティによって使用が制限されている情報（または他の財産）を指します。
$ protected checksum (I) A checksum that is computed for a data object by means that protect against active attacks that would attempt to change the checksum to make it match changes made to the data object. (See: digital signature, keyed hash, Tutorial under "checksum".)
$ Protected CheckSum（i）データオブジェクトを変更しようとしたアクティブな攻撃に対して保護することで、データオブジェクトに対してデータオブジェクトに合わせるようにしようとするアクティブな攻撃に対して保護するチェックサム。（参照：デジタル署名、キー付きハッシュ、「チェックサム」の「チュートリアル」。）
$ protective packaging (N) "Packaging techniques for COMSEC material that discourage penetration, reveal a penetration has occurred or was attempted, or inhibit viewing or copying of keying material prior to the time it is exposed for use." [C4009] (See: tamper-evident, tamper-resistant. Compare: QUADRANT.)
$ 保護包装（N）」包装技術浸透を妨げる、浸透が起こっているか、またはそれが使用のために露出されるまでのキー化材料の視認またはコピーを阻止する、または試みられたか、または試みられた。[C4009]（「改ざん：耐タンパー抵抗力」を参照してください。比較：象限を比較してください。
$ protection authority (I) See: secondary definition under "Internet Protocol Security Option".
$ 保護局（I）「インターネットプロトコルセキュリティオプション」の下のセカンダリ定義を参照してください。
$ protection level (N) /U.S. Government/ An indication of the trust that is needed in a system's technical ability to enforce security policy for confidentiality. (Compare: /system operation/ under "mode of operation".) Tutorial: An organization's security policy could define protection levels that are based on comparing (a) the sensitivity of information handled by a system to (b) the authorizations of users that receive information from the system without manual intervention and reliable human review. For each level, the policy could specify security features and assurances that must be included in any system that was intended to operate at that level.
$保護レベル（n）/u.s。政府/機密性のためのセキュリティポリシーを強制するためのシステムの技術的能力において必要とされる信頼の指示。（比較：/システム操作/「操作モード」）チュートリアル：組織のセキュリティポリシーは、（a）システムが処理する情報の感度を（b）ユーザーの認証に基づく保護レベルを定義することができます。手動の介入と信頼できる人間のレビューなしでシステムから情報を受信します。各レベルについて、ポリシーはそのレベルで動作することを意図したシステムに含める必要があるセキュリティ機能と保証を指定できます。
Example: Given some set of data objects that are classified at one or more hierarchical levels and in one or more non-hierarchical categories, the following table defines five protection levels for systems that would handle that data. Beginning with PL1 and evolving to PL5, each successive level would require stronger features and assurances to handle the dataset. (See: clearance, formal access approval, and need-to-know.)
例：1つ以上の階層レベルで分類され、1つ以上の階層的なカテゴリで分類されている一連のデータオブジェクトが与えられ、次の表はそのデータを処理するシステムの5つの保護レベルを定義します。PL1から始まりPL5に進化すると、連続した各レベルでは、データセットを処理するための強力な機能と保証が必要です。（：クリアランス、正式なアクセス承認、そして知り切りがない。）
Lowest Clearance Formal Access Need-To-Know
Among All Users Approval of Users of Users
+-------------------+-------------------+-------------------+
PL5 | Some user has no | [Does not matter.]| [Does not matter.]|
High | clearance at all. | | |
+-------------------+-------------------+-------------------+
PL4 | All are cleared | [Does not matter.]| [Does not matter.]|
| for some data. | | |
+-------------------+-------------------+-------------------+
PL3 | All are cleared | Some not approved | [Does not matter.]|
| for all data. | for all data. | |
+-------------------+-------------------+-------------------+
PL2 | All are cleared | All are approved | Some don't need to|
| for all data. | for all data. | to know all data. |
+-------------------+-------------------+-------------------+
PL1 | All are cleared | All are approved | All have a need |
Low | for all data. | for all data. | to know all data. |
+-------------------+-------------------+-------------------+
Each of these protection levels can be viewed as being equivalent to one or more modes of system operation defined in this Glossary: - PL5 is equivalent to multilevel security mode. - PL4 is equivalent to either multilevel or compartmented security mode, depending on the details of users' clearances. - PL3 is equivalent to partitioned security mode. - PL2 is equivalent to system-high security mode. - PL1 is equivalent to dedicated security mode.
これらの保護レベルのそれぞれは、この用語集に定義されているシステム動作の1つ以上のモードと同等のものと見なすことができます。 - PL5はマルチレベルセキュリティモードに相当します。 - PL4は、ユーザーのクリアランスの詳細に応じて、マルチレベルまたはコンパートメントセキュリティモードのいずれかと同じです。 - PL3は分割セキュリティモードと同等です。 - PL2はシステムハイセキュリティモードに相当します。 - PL1は専用のセキュリティモードに相当します。
$ protection profile (N) /Common Criteria/ An implementation-independent set of security requirements for a category of targets of evaluation that meet specific consumer needs. [CCIB] Example: [IDSAN]. (See: target of evaluation. Compare: certificate profile, package.)
$保護プロファイル（n）/共通基準/特定の消費者のニーズを満たす評価の対象のカテゴリのためのセキュリティ要件の実装に依存しないセット。[CCIB]例：[IDSAN]。（評価の対象。比較：証明書プロファイル、パッケージ。）
Tutorial: A protection profile (PP) is the kind of document used by consumers to specify functional requirements they want in a product, and a security target (ST) is the kind of document used by vendors to make functional claims about a product.
チュートリアル：保護プロファイル（PP）は、製品内で欲しい機能要件を指定するために消費者が使用する文書の種類であり、セキュリティ対象（ST）は製品について機能的な請求をするためにベンダーが使用する文書の種類です。
A PP is intended to be a reusable statement of product security needs, which are known to be useful and effective, for a set of information technology security products that could be built. A PP contains a set of security requirements, preferably taken from the catalogs in Parts 2 and 3 of the Common Criteria, and should include an EAL. A PP could be developed by user communities, product developers, or any other parties interested in defining a common set of requirements.
PPは、構築され得る一連の情報技術セキュリティ製品のために、有用で効果的であることが知られている製品セキュリティのニーズの再利用可能な声明であることを意図しています。PPは、好ましくは一般的な基準の部品2および3のカタログから取られた一組のセキュリティ要件を含み、EALを含むべきである。PPは、ユーザコミュニティ、製品開発者、または一般的な要件のセットの定義に関心がある他の締約国によって開発することができます。
$ protection ring (I) One of a hierarchy of privileged operation modes of a system that gives certain access rights to processes authorized to operate in that mode. (See: Multics.)
$ 保護リング（i）そのモードで動作することを許可されたプロセスへの特定のアクセス権を与えるシステムの特権モードの階層の1つ。（：マルチスを参照してください。）
$ protective distribution system (PDS) (N) A wireline or fiber-optic communication system used to transmit cleartext classified information through an area of lesser classification or control. [N7003]
$ 保護配電システム（PDS）（N）クリアテキスト分類情報を短縮または制御の領域を介して送信するために使用される有線または光ファイバ通信システム。[N7003]
$ protocol 1a. (I) A set of rules (i.e., formats and procedures) to implement and control some type of association (e.g., communication) between systems. Example: Internet Protocol.
$ プロトコル1a。（i）システム間のいくつかの種類の関連付け（例えば通信）を実装し制御するための一連の規則（すなわち、フォーマットおよび手順）。例：インターネットプロトコル。
1b. (I) A series of ordered computing and communication steps that are performed by two or more system entities to achieve a joint objective. [A9042]
1b。（i）関節目的を達成するために2つ以上のシステムエンティティによって実行される一連の順序付けられたコンピューティングおよび通信ステップ。[A9042]
$ protocol control information (PCI) (N) See: secondary definition under "protocol data unit".
$ プロトコル制御情報（PCI）（N）「プロトコルデータ単位」の下の2次定義。
$ protocol data unit (PDU) (N) A data packet that is defined for peer-to-peer transfers in a protocol layer.
$ プロトコルデータユニット（PDU）（N）プロトコルレイヤ内のピアツーピア転送に定義されているデータパケット。
Tutorial: A PDU consists of two disjoint subsets of data: the SDU and the PCI. (Although these terms -- PDU, SDU, and PCI -- originated in the OSIRM, they are also useful and permissible in an IPS context.)
チュートリアル：PDUはデータの2つの異なるサブセットで構成されています.SDUとPCI。（これらの用語 - PDU、SDU、およびPCI - OSIRMで発信されているが、それらはIPSコンテキストでも有用で許可されています。）
- The "service data unit" (SDU) in a packet is data that the protocol transfers between peer protocol entities on behalf of the users of that layer's services. For Layers 1 through 6, the layer's users are peer protocol entities at a higher layer; for Layer 7, the users are application entities outside the scope of the OSIRM. - The "protocol control information" (PCI) in a packet is data that peer protocol entities exchange between themselves to control their joint operation of the layer.
- パケット内の「サービスデータユニット」（SDU）は、そのレイヤのサービスのユーザに代わってピアプロトコルエンティティ間でプロトコルが転送するデータである。レイヤ1から6の場合、レイヤーのユーザーは、より高いレイヤーのピアトロウトエンティティです。レイヤ7の場合、ユーザーはOSIRMの範囲外のアプリケーションエンティティです。 - パケット内の「プロトコル制御情報」（PCI）は、ピアプロトコルエンティティがレイヤのジョイント動作を制御するためにそれら自身の間で交換するデータです。
$ protocol suite (I) A complementary collection of communication protocols used in a computer network. (See: IPS, OSI.)
$ プロトコルスイート（i）コンピュータネットワークで使用される通信プロトコルの補完的なコレクション。（参照：IPS、OSI。）
$ proxy 1. (I) A computer process that acts on behalf of a user or client.
$ プロキシ1.（i）ユーザーまたはクライアントに代わって機能するコンピュータプロセス。
2. (I) A computer process -- often used as, or as part of, a firewall -- that relays application transactions or a protocol between client and server computer systems, by appearing to the client to be the server and appearing to the server to be the client. (See: SOCKS.)
2. （i）コンピュータプロセス - アプリケーショントランザクションまたはクライアントとサーバコンピュータシステム間のプロトコルをサーバに表示し、サーバに現れることによって、ファイアウォールの一部として、またはその一部として使用される。クライアントになりましょう。（靴下を参照してください。）
Tutorial: In a firewall, a proxy server usually runs on a bastion host, which may support proxies for several applications and protocols (e.g., FTP, HTTP, and TELNET). Instead of a client in the protected enclave connecting directly to an external server, the internal client connects to the proxy server, which in turn connects to the external server. The proxy server waits for a request from inside the firewall, forwards the request to the server outside the firewall, gets the response, then sends the response back to the client. The proxy may be transparent to the clients, or they may need to connect first to the proxy server, and then use that association to also initiate a connection to the real server.
チュートリアル：ファイアウォールでは、プロキシサーバーが通常、バスティオンホスト上で実行され、これはいくつかのアプリケーションとプロトコル（例えば、FTP、HTTP、およびTelnet）のプロキシをサポートできます。外部サーバーに直接接続する保護されたエンクリューブのクライアントの代わりに、内部クライアントはプロキシサーバーに接続します。これは次に外部サーバーに接続します。プロキシサーバーはファイアウォールの内側からの要求を待ち、リクエストをファイアウォールの外側のサーバーに転送し、応答を取得してから、応答をクライアントに送信します。プロキシはクライアントに対して透過的であるか、または最初にプロキシサーバーに接続する必要があり、その関連付けを使用して実サーバへの接続を開始する必要があるかもしれません。
Proxies are generally preferred over SOCKS for their ability to perform caching, high-level logging, and access control. A proxy can provide security service beyond that which is normally part of the relayed protocol, such as access control based on peer entity authentication of clients, or peer entity authentication of servers when clients do not have that ability. A proxy at OSIRM Layer 7 can also provide finer-grained security service than can a filtering router at Layer 3. For example, an FTP proxy could permit transfers out of, but not into, a protected network.
プロキシは、キャッシュ、高レベルのロギング、およびアクセス制御を実行する能力のために、一般的に靴下よりも優先されます。プロキシは、クライアントのピアエンティティ認証に基づくアクセス制御、クライアントがその能力を持たない場合のサーバーのピアエンティティ認証など、中継プロトコルの一部であることを超えてセキュリティサービスを提供できます。OSIRMレイヤ7でのプロキシは、レイヤ3でフィルタリングルータをフィルタリングすることもできます。たとえば、FTPプロキシは、保護されたネットワークからの転送を許可することができます。
$ proxy certificate (I) An X.509 public-key certificate derived from an end-entity certificate, or from another proxy certificate, for the purpose of establishing proxies and delegating authorizations in the context of a PKI-based authentication system. [R3820]
$ プロキシ証明書（i）PKIベースの認証システムのコンテキストでプロキシと承認を委任するために、エンドエンティティ証明書、または別のプロキシ証明書から派生したX.509公開鍵証明書。[R3820]
Tutorial: A proxy certificate has the following properties: - It contains a critical extension that (a) identifies it as a proxy certificate and (b) may contain a certification path length constraint and policy constraints. - It contains the public component of a key pair that is distinct from that associated with any other certificate. - It is signed by the private component of a key pair that is associated with an end-entity certificate or another proxy certificate. - Its associated private key can be used to sign only other proxy certificates (not end-entity certificates). - Its "subject" DN is derived from its "issuer" DN and is unique. - Its "issuer" DN is the "subject" DN of an end-entity certificate or another proxy certificate.
チュートリアル：プロキシ証明書には次のプロパティがあります。 - （a）がプロキシ証明書として識別する重要な拡張子を含み、（b）は認証パス長制約とポリシーの制約を含むことができます。 - 他の証明書に関連付けられているものとは異なるキーペアのパブリックコンポーネントが含まれています。 - エンドエンティティ証明書または別のプロキシ証明書に関連付けられているキーペアのプライベートコンポーネントによって署名されます。 - それに関連する秘密鍵を使用して、他のプロキシ証明書（エンドエンティティ証明書ではありません）のみに署名できます。 - その「被験者」DNはその「発行者」DNから派生しており、ユニークです。 - その「発行者」DNは、エンドエンティティ証明書または別のプロキシ証明書の「件名」DNです。
$ pseudorandom (I) A sequence of values that appears to be random (i.e., unpredictable) but is actually generated by a deterministic algorithm. (See: compression, random, random number generator.)
$ 擬似乱数（i）ランダムであるように見える一連の値（すなわち予測不可能）が、実際には決定論的アルゴリズムによって生成される。（圧縮、ランダム、乱数発生器。）
$ pseudorandom number generator (I) See: secondary definition under "random number generator".
$ Pseudorandom Number Generator（i）「乱数発生器」の下の2次定義を参照してください。
$ public component (I) Synonym for "public key".
$ パブリックコンポーネント（i）「公開鍵」の同義語。
Deprecated Usage: In most cases, IDOCs SHOULD NOT use this term; to avoid confusing readers, use "private key" instead. However, the term MAY be used when discussing a key pair; e.g., "A key pair has a public component and a private component."
廃止予定の使用法：ほとんどの場合、IDocはこの用語を使用しないでください。読者の混乱を避けるために、代わりに「秘密鍵」を使用してください。しかしながら、鍵ペアを議論するときに用語を使用することができる。例えば、「鍵ペアは公開コンポーネントとプライベートコンポーネントを持っています」。
$ public key 1. (I) The publicly disclosable component of a pair of cryptographic keys used for asymmetric cryptography. (See: key pair. Compare: private key.)
$ 公開鍵1.（i）非対称暗号化に使用される一対の暗号鍵の公的に開示されている構成要素。（：キーペアを参照してください。比較：秘密鍵）
2. (O) In a public key cryptosystem, "that key of a user's key pair which is publicly known." [X509]
2. （O）公開鍵暗号システムでは、「公に知られているユーザーの鍵ペアの鍵」。[X509]
$ public-key certificate 1. (I) A digital certificate that binds a system entity's identifier to a public key value, and possibly to additional, secondary data items; i.e., a digitally signed data structure that attests to the ownership of a public key. (See: X.509 public-key certificate.)
$ 公開鍵証明書1.（i）システムエンティティの識別子を公開鍵の値にバインドし、おそらく追加のセカンダリデータ項目をバインドするデジタル証明書。すなわち、公開鍵の所有権に証明するデジタル署名付きデータ構造。（X.509公開鍵証明書を参照してください。）
2. (O) "The public key of a user, together with some other information, rendered unforgeable by encipherment with the private key of the certification authority which issued it." [X509]
2. （O）「ユーザーの公開鍵は、その他の情報とともに、それを発行した認証局の秘密鍵で暗号化によって忘れられないようにしました。」[X509]
Tutorial: The digital signature on a public-key certificate is unforgeable. Thus, the certificate can be published, such as by posting it in a directory, without the directory having to protect the certificate's data integrity.
チュートリアル：公開鍵証明書のデジタル署名は忘れられません。したがって、証明書のデータの整合性を保護しなければならないディレクトリなしで、それをディレクトリに投稿するなど、証明書を公開できます。
$ public-key cryptography (I) Synonym for "asymmetric cryptography".
$ 公開鍵暗号化（i）「非対称暗号」の同義語。
$ Public-Key Cryptography Standards (PKCS) (N) A series of specifications published by RSA Laboratories for data structures and algorithms used in basic applications of asymmetric cryptography. [PKCS] (See: PKCS #5 through PKCS #11.)
$ 公開鍵暗号化規格（PKCS）（N）非対称暗号化の基本的な用途で使用されるデータ構造およびアルゴリズムについては、RSA Laboratoriesによって公開された一連の仕様。[PKCS]（PKCS＃5からPKCS＃11を参照）
Tutorial: The PKCS were begun in 1991 in cooperation with industry and academia, originally including Apple, Digital, Lotus, Microsoft, Northern Telecom, Sun, and MIT. Today, the specifications are widely used, but they are not sanctioned by an official standards organization, such as ANSI, ITU-T, or IETF. RSA Laboratories retains sole decision-making authority over the PKCS.
チュートリアル：もともと、リンゴ、デジタル、ロータス、マイクロソフト、北部テレコム、太陽、そしてMITを含む、産業と学界と協力して1991年にPKCSが開始されました。今日、仕様は広く使用されていますが、ANSI、ITU-T、またはIETFなどの公式規格機関によって認可されていません。RSAラボラトリーズはPKCSに対して唯一の意思決定権限を保持しています。
$ public-key forward secrecy (PFS) (I) For a key-agreement protocol based on asymmetric cryptography, the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the private keys is compromised in the future. (See: Usage note and other discussion under "perfect forward secrecy".)
$ 非対称暗号化に基づく重要な契約プロトコル（i）非対称暗号化に基づく重要な契約プロトコルの場合、一連の長期的な鍵と秘密鍵のセッションから派生したセッション鍵が損なわれないことを保証する。将来的には秘密鍵が危険にさらされています。（「使用上の注意」および「完璧な前進秘密」の「その他の議論」。）
$ public-key Kerberos (I) See: Tutorial under "Kerberos", PKINIT.
$ 公開鍵Kerberos（i）「Kerberos」の「Kerberos」、Pkinitの下のチュートリアル。
$ public-key infrastructure (PKI) 1. (I) A system of CAs (and, optionally, RAs and other supporting servers and agents) that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography. (See: hierarchical PKI, mesh PKI, security management infrastructure, trust-file PKI.) 2. (I) /PKIX/ The set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography.
（i）一組の証明書管理、アーカイブ管理、鍵管理、およびトークン管理機能を実行するCAS（optionally、RAS、その他のサポートサーバーおよびエージェント）のシステム。非対称暗号化の応用におけるユーザのコミュニティ。（階層型PKI、メッシュPKI、セキュリティ管理インフラストラクチャ、信託ファイルPKI）2。（i）/ PKIX /ハードウェア、ソフトウェア、人、ポリシー、および作成、管理、保存、配布に必要な手順非対称暗号化に基づいてデジタル証明書を取り消す。
Tutorial: The core PKI functions are (a) to register users and issue their public-key certificates, (b) to revoke certificates when required, and (c) to archive data needed to validate certificates at a much later time. Key pairs for data confidentiality may be generated (and perhaps escrowed) by CAs or RAs, but requiring a PKI client to generate its own digital signature key pair helps maintain system integrity of the cryptographic system, because then only the client ever possesses the private key it uses. Also, an authority may be established to approve or coordinate CPSs, which are security policies under which components of a PKI operate.
チュートリアル：コアPKI関数は（a）ユーザーを登録し、必要に応じて証明書を取り消すために、そして（c）を実行するためにそれらの公開鍵証明書を発行し、（c）を実行するために必要なデータをアーカイブすること。データ機密性のためのキーペアは、CASまたはRASによって生成されます（そしておそらく浮命止め）、PKIクライアントが独自のデジタル署名キーペアを生成する必要があるため、クライアントのみが秘密鍵を持っていますので、暗号システムのシステムの整合性を維持するのに役立ちます。それは使用しています。また、PKIの構成要素が動作するセキュリティポリシーであるCPSSを承認または調整するための権限を確立することができる。
A number of other servers and agents may support the core PKI, and PKI clients may obtain services from them, such as certificate validation services. The full range of such services is not yet fully understood and is evolving, but supporting roles may include archive agent, certified delivery agent, confirmation agent, digital notary, directory, key escrow agent, key generation agent, naming agent who ensures that issuers and subjects have unique identifiers within the PKI, repository, ticket-granting agent, time-stamp agent, and validation agent.
他の多くのサーバーとエージェントはコアPKIをサポートしていてもよく、PKIクライアントは証明書検証サービスなど、それらからサービスを受けることがあります。そのようなサービスの全範囲はまだ完全に理解されておらず、進化していますが、役割をサポートする場合があります。対象には、PKI、リポジトリ、チケット付与エージェント、タイムスタンプエージェント、および検証エージェント内の一意の識別子があります。
$ purge 1. (I) Synonym for "erase".
$ PURGE 1.（i）「消去」の同義語。
2. (O) /U.S. Government/ Use degaussing or other methods to render magnetically stored data unusable and irrecoverable by any means, including laboratory methods. [C4009] (Compare: /U.S. Government/ erase.)
2. （O）/U.S。政府/磁気的に貯蔵されたデータを使用できず、実験室の方法を含む任意の手段によって回復不能になるように政府の使用またはその他の方法を使用する。[C4009]（比較：/u.s.政府/消去）
$ QUADRANT (O) /U.S. Government/ Short name for technology and methods that protect cryptographic equipment by making the equipment tamper-resistant. [C4009] (Compare: protective packaging, TEMPEST.)
$ 象限（O）/U.S。機器を改ざんすることで暗号化装置を保護する技術や方法の政府/短編小節。[C4009]（コンペア：保護包装、テンペスト）
Tutorial: Equipment cannot be made completely tamper-proof, but it can be made tamper-resistant or tamper-evident.
チュートリアル：設備を完全に改ざんできないが、耐タンパーまたはタンパーイブミックにすることができます。
$ qualified certificate (I) A public-key certificate that has the primary purpose of identifying a person with a high level of assurance, where the certificate meets some qualification requirements defined by an applicable legal framework, such as the European Directive on Electronic Signature. [R3739]
$ 認定証明書（i）証明書がヨーロッパの指令などの適切な法的枠組みによって定義されたいくつかの資格要件を満たす人を識別する主な目的を持つ公開鍵証明書。[R3739]
$ quick mode (I) See: /IKE/ under "mode".
$ クイックモード（i）：/ IKE / INDER "MODE"を参照してください。
$ RA (I) See: registration authority.
$ RA（i）登録局。
$ RA domains (I) A feature of a CAW that allows a CA to divide the responsibility for certificate requests among multiple RAs.
$ RAドメイン（i）CAが複数のRA間の証明書要求に対する責任を分割できるようにするCAWの機能。
Tutorial: This ability might be used to restrict access to private authorization data that is provided with a certificate request, and to distribute the responsibility to review and approve certificate requests in high-volume environments. RA domains might segregate certificate requests according to an attribute of the certificate's subject, such as an organizational unit.
チュートリアル：この能力は、証明書要求を提供されている個人認証データへのアクセスを制限し、大量の環境で証明書要求を確認して承認する責任を配布することができます。RAドメインは、組織単位などの証明書の件名の属性に従って、証明書要求を分離することがあります。
$ RADIUS (I) See: Remote Authentication Dial-In User Service.
$ RADIUS（i）：リモート認証ダイヤルインユーザサービス。
$ Rainbow Series (O) /COMPUSEC/ A set of more than 30 technical and policy documents with colored covers, issued by the NCSC, that discuss in detail the TCSEC and provide guidance for meeting and applying the criteria. (See: Green Book, Orange Book, Red Book, Yellow Book.)
$ Rainbow Series（O）/ CompUSEC / NCSCによって発行されたカラーカバーを備えた30以上の技術文書のセットは、TCSECを詳細に説明し、会議と適用のためのガイダンスを提供します。（緑の本、オレンジブック、レッドブック、黄色い本。）
$ random (I) In essence, "random" means "unpredictable". [SP22, Knut, R4086] (See: cryptographic key, pseudorandom.) - "Random sequence": A sequence in which each successive value is obtained merely by chance and does not depend on the preceding values of the sequence. In a random sequence of bits, each bit is unpredictable; i.e., (a) the probability of each bit being a "0" or "1" is 1/2, and (b) the value of each bit is independent of any other bit in the sequence. - "Random value": An individual value that is unpredictable; i.e., each value in the total population of possibilities has equal probability of being selected.
$ ランダム（i）本質的には、「ランダム」は「予測不可能」を意味します。[SP22、Knut、R4086]（暗号鍵、擬似乱数。） - 「ランダムシーケンス」：各連続値が偶然に稼働しており、シーケンスの前の値に依存しない順序。ランダムなビットのシーケンスでは、各ビットは予測不可能です。すなわち、（a）各ビットが「0」または「1」の確率は1/2であり、（b）各ビットの値はシーケンス内の他のビットとは無関係である。 - 「ランダム値」：予測不可能な個別値。すなわち、可能性の総集団における各値は、同等の確率が選択されている。
$ random number generator (I) A process that is invoked to generate a random sequence of values (usually a sequence of bits) or an individual random value.
$ 乱数発生器（i）呼び出されたプロセスは、ランダムな値（通常は一連のビット）または個々のランダム値を生成するプロセスです。
Tutorial: There are two basic types of generators. [SP22] - "(True) random number generator": It uses one or more non-deterministic bit sources (e.g., electrical circuit noise, timing of human processes such as key strokes or mouse movements, semiconductor quantum effects, and other physical phenomena) and a processing function that formats the bits, and it outputs a sequence of values that is unpredictable and uniformly distributed. - "Pseudorandom number generator": It uses a deterministic computational process (usually implemented by software) that has one or more inputs called "seeds", and it outputs a sequence of values that appears to be random according to specified statistical tests.
チュートリアル：ジェネレータには2つの基本的な種類があります。[SP22] - 「（真）乱数発生器」：1つ以上の非決定論的ビットソース（例えば、電気回路ノイズ、キーストローク、マウスの動き、半導体量子効果などの人間のプロセスのタイミング、その他の物理的現象など）を使用します。そして、ビットをフォーマットする処理機能とそれは予測不可能で均一に分散された一連の値を出力する。 - 「Pseudorandom Number Generator」：「SEEDS」と呼ばれる1つ以上の入力を持つ決定論的計算プロセス（通常はソフトウェアで実装されています）を使用し、指定された統計テストに従ってランダムになるように見える一連の値を出力します。
$ RBAC (N) See: role-based access control, rule-based access control.
$ RBAC（N）は、ロールベースのアクセス制御、ルールベースのアクセス制御を参照してください。
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the abbreviation is ambiguous.
廃止予定の使用法：この用語を使用するIDocは、略語があいまいであるため、定義を定義します。
$ RC2, RC4, RC6 (N) See: Rivest Cipher #2, #4, #6.
$ RC2、RC4、RC6（N）参照：Rivest暗号＃2、＃4、＃6。
$ read (I) /security model/ A system operation that causes a flow of information from an object to a subject. (See: access mode. Compare: write.)
$ 読み取り（i）/セキュリティモデル/オブジェクトから被写体への情報の流れを引き起こすシステム操作。（参照モードを参照してください。比較：書き込み。）
$ realm (I) /Kerberos/ A domain consisting of a set of Kerberized clients, Kerberized application servers, and one or more Kerberos authentication servers and ticket-granting servers that support the clients and applications, all operating under the same security policy. (See: domain.)
$ REALM（I）/ Kerberos /一連のKerberizedクライアント、Kerberized Application Server、およびクライアントとアプリケーションをサポートする1つ以上のKerberos認証サーバー、およびチケット付与サーバーからなるドメイン。（以下を参照してください。）
$ recovery 1. (I) /cryptography/ The process of learning or obtaining cryptographic data or plain text through cryptanalysis. (See: key recovery, data recovery.)
$ 回復1.（i）/暗号化/暗号データの学習または学習または暗号化されたテキストを求めるプロセス。（参照：キーの回復、データの回復。）
2a. (I) /system integrity/ The process of restoring a secure state in a system after there has been an accidental failure or a successful attack. (See: secondary definition under "security", system integrity.)
2A。（i）/システムの整合性/システム内の安全な状態を復元するプロセスは、偶発的な失敗または成功した攻撃があった。（「セキュリティ」の下のセカンダリ定義、システムの整合性。）
2b. (I) /system integrity/ The process of restoring an information system's assets and operation following damage or destruction. (See: contingency plan.)
2b。（i）/システムの整合性/情報システムの資産と損傷や破壊後の操作の復元プロセス。（緊急プランを参照してください。）
$ RED 1. (N) Designation for data that consists only of clear text, and for information system equipment items and facilities that handle clear text. Example: "RED key". (See: BCR, color change, RED/BLACK separation. Compare: BLACK.)
$ RED 1.（n）明確なテキストのみで構成されているデータの指定、および情報システム機器の項目や明確なテキストを処理する機能。例：「赤キー」。（BCR、色の変更、赤/黒の分離。比較：黒）
Derivation: From the practice of marking equipment with colors to prevent operational errors.
派生：運用誤差を防ぐために、機器を色でマーキングすることの実践から。
2. (O) /U.S. Government/ Designation applied to information systems, and to associated areas, circuits, components, and equipment, "in which unencrypted national security information is being processed." [C4009]
2. （O）/U.S。政府/指定は、情報システムに適用されており、関連する地域、回線、部品、および機器、「未暗報国のセキュリティ情報が処理されている。」[C4009]
$ RED/BLACK separation (N) An architectural concept for cryptographic systems that strictly separates the parts of a system that handle plain text (i.e., RED information) from the parts that handle cipher text (i.e., BLACK information). (See: BLACK, RED.)
$ 赤/黒分離（n）暗号テキスト（すなわち黒い情報）を処理する部品からプレーンテキスト（すなわち赤い情報）を処理するシステムの部分を厳密に分離する暗号システムのためのアーキテクチャ概念。（参照：黒、赤）
$ Red Book (D) /slang/ Synonym for "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria" [NCS05].
$ Red Book（D）/ Slang / Synon '"信頼できるコンピュータシステム評価基準の信頼されたネットワーク解釈" [NCS05]。
Deprecated Term: IDOCs SHOULD NOT use this term. Instead, use the full proper name of the document or, in subsequent references, a more conventional abbreviation, e.g., TNI-TCSEC. (See: TCSEC, Rainbow Series, Deprecated Usage under "Green Book".)
廃止予定語：IDocsはこの用語を使用しないでください。代わりに、文書の完全な適切な名前を使用するか、またはその後の参照において、より従来の略語、例えばTNI-TCSECを使用します。（TCSEC、Rainbow Series、「グリーンブック」の「使用済みの使用」を参照。
$ RED key (N) A cleartext key, which is usable in its present form (i.e., it does not need to be decrypted before being used). (See: RED. Compare: BLACK key.)
$ Red Key（n）現在の形式で使用可能なクリアテキストキー（すなわち、使用前に復号化する必要はありません）。（参照：赤。比較：黒キーを参照してください。）
$ reference monitor (I) "An access control concept that refers to an abstract machine that mediates all accesses to objects by subjects." [NCS04] (See: security kernel.)
$ 参照モニタ（i）「対象によるオブジェクトへのアクセスをすべて仲介する抽象マシンを参照するアクセス制御の概念」[NCS04]（セキュリティカーネルを参照）
Tutorial: This concept was described in the Anderson report. A reference monitor should be (a) complete (i.e., it mediates every access), (b) isolated (i.e., it cannot be modified by other system entities), and (c) verifiable (i.e., small enough to be subjected to analysis and tests to ensure that it is correct).
チュートリアル：この概念はAndersonレポートに記載されています。参照モニタは（a）完全であるべきである（すなわち、それはあらゆるアクセスを媒介する）、（b）分離された（すなわち、他のシステムエンティティによって変更することはできない）、および（c）検証可能な（すなわち、分析を受けるのに十分小さい）。そしてそれが正しいことを保証するためにテスト。
$ reflection attack (I) An attack in which a valid data transmission is replayed to the originator by an attacker who intercepts the original transmission. (Compare: indirect attack, replay attack.)
$ Reflection Attact（i）有効なデータ伝送が、元の送信を傍受する攻撃者によって発信者に再生される攻撃。（比較：間接攻撃、再生攻撃）
$ reflector attack (D) Synonym for "indirect attack".
$ 反射攻撃（D）「間接攻撃」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it could be confused with "reflection attack", which is a different concept.
廃止予定語：IDocsはこの用語を使用しないでください。それは「反射攻撃」と混同することができ、それは別の概念です。
$ registered user (I) A system entity that is authorized to receive a system's products and services or otherwise access system resources. (See: registration, user.)
$ 登録ユーザー（i）システムの製品とサービスを受信するか、その他の方法でシステムリソースにアクセスすることを許可されているシステムエンティティ。（登録、ユーザー。）
$ registration 1. (I) /information system/ A system process that (a) initializes an identity (of a system entity) in the system, (b) establishes an identifier for that identity, (c) may associate authentication information with that identifier, and (d) may issue an identifier credential (depending on the type of authentication mechanism being used). (See: authentication information, credential, identifier, identity, identity proofing.)
$ 登録1.（i）/情報システム/システムの（a）システム内の（A）システムのIDを初期化するシステム、（b）はそのIDの識別子を確立し、（c）認証情報をその識別子と関連付けることができる（D）は（使用されている認証メカニズムの種類に応じて）識別子の認証情報を発行することができます。（認証情報、信任状、識別子、ID、ID校正）を参照してください。
2. (I) /PKI/ An administrative act or process whereby an entity's name and other attributes are established for the first time at a CA, prior to the CA issuing a digital certificate that has the entity's name as the subject. (See: registration authority.)
2. （i）/ PKI /管理者の名前やその他のプロセスが、CAの初めてCAで初めて確立され、エンティティの名前が主題の名前を持つデジタル証明書を発行します。（登録局を参照してください。）
Tutorial: Registration may be accomplished either directly, by the CA, or indirectly, by a separate RA. An entity is presented to the CA or RA, and the authority either records the name(s) claimed for the entity or assigns the entity's name(s). The authority also determines and records other attributes of the entity that are to be bound in a certificate (such as a public key or authorizations) or maintained in the authority's database (such as street address and telephone number). The authority is responsible, possibly assisted by an RA, for verifying the entity's identity and vetting the other attributes, in accordance with the CA's CPS.
チュートリアル：登録は、CAによって直接、または間接的に、別々のRAによって実行されることがあります。エンティティはCAまたはRAに提示され、権限はエンティティに主張されている名前を記録するか、エンティティの名前を割り当てます。この権限はまた、証明書に拘束されるエンティティの他の属性（公開鍵や承認など）を決定し、当局のデータベース（通りアドレスや電話番号など）に維持されます。この権限は、CAのCPSに従って、企業の身元を検証し、他の属性を害するために、RAから支援される可能性がある責任があります。
Among the registration issues that a CPS may address are the following [R3647]: - How a claimed identity and other attributes are verified. - How organization affiliation or representation is verified. - What forms of names are permitted, such as X.500 DN, domain name, or IP address. - Whether names are required to be meaningful or unique, and within what domain. - How naming disputes are resolved, including the role of trademarks. - Whether certificates are issued to entities that are not persons.
CPSが対処できる登録の問題の中には、次の[R3647]が次のとおりです。 - 組織の所属や表現の検証方法 - X.500 DN、ドメイン名、またはIPアドレスなど、どのような名称の名前が許可されています。 - 名前が意味のあるものまたは一意であること、およびどのドメイン内である必要があるかどうか。 - 商標の役割を含め、ネーム紛争の解決方法。 - 証明書が個人ではないエンティティに発行されるかどうか。
- Whether a person is required to appear before the CA or RA, or can instead be represented by an agent. - Whether and how an entity proves possession of the private key matching a public key.
- 人がCAまたはRAの前に現れる必要があるかどうか、または代わりにエージェントによって表現されることができます。 - エンティティが公開鍵と一致する秘密鍵の所有を証明するかどうか。
$ registration authority (RA) 1. (I) An optional PKI entity (separate from the CAs) that does not sign either digital certificates or CRLs but has responsibility for recording or verifying some or all of the information (particularly the identities of subjects) needed by a CA to issue certificates and CRLs and to perform other certificate management functions. (See: ORA, registration.)
$ 登録局（RA）1。（i）デジタル証明書またはCRLのいずれかに署名しないが、情報の一部または全部を記録または検証するための責任を有するオプションのPKIエンティティ（特に主題の識別情報）がある。証明書とCRLを発行し、他の証明書管理機能を実行するためのCAによって。（参照：ORA、登録。）
2. (I) /PKIX/ An optional PKI component, separate from the CA(s). The functions that the RA performs will vary from case to case but may include identity authentication and name assignment, key generation and archiving of key pairs, token distribution, and revocation reporting. [R4210]
2. （i）/ PKIX /オプションのPKI成分、CAとは別のPKI成分。RAが実行する関数はケースによって異なりますが、ID認証と名前割り当て、キーペアの鍵生成、アーカイブ、トークン配布、および失効報告を含めることができます。[R4210]
Tutorial: Sometimes, a CA may perform all certificate management functions for all end users for which the CA signs certificates. Other times, such as in a large or geographically dispersed community, it may be necessary or desirable to offload secondary CA functions and delegate them to an assistant, while the CA retains the primary functions (signing certificates and CRLs). The tasks that are delegated to an RA by a CA may include personal authentication, name assignment, token distribution, revocation reporting, key generation, and archiving.
チュートリアル：CAは、CAが証明書に署名するすべてのエンドユーザーに対してすべての証明書管理機能を実行できます。大規模または地理的に分散したコミュニティのような他の時間は、二次CA機能をオフロードし、それらをアシスタントに委任することが必要または望ましいかもしれないが、CAは主要関数（署名証明書およびCRLS）を保持する。CAによってRAに委任されているタスクは、個人認証、名前割り当て、トークン配布、失効報告、鍵生成、およびアーカイブを含み得る。
An RA is an optional PKI entity, separate from the CA, that is assigned secondary functions. The duties assigned to RAs vary from case to case but may include the following: - Verifying a subject's identity, i.e., performing personal authentication functions. - Assigning a name to a subject. (See: distinguished name.) - Verifying that a subject is entitled to have the attributes requested for a certificate. - Verifying that a subject possesses the private key that matches the public key requested for a certificate. - Performing functions beyond mere registration, such as generating key pairs, distributing tokens, handling revocation reports, and archiving data. (Such functions may be assigned to a PKI component that is separate from both the CA and the RA.)
RAは、CAとは別のオプションのPKIエンティティであり、それは二次関数を割り当てられています。RASに割り当てられた職務は、場合によって異なりますが、次のものを含めることができます。 - 被験者の身元の確認、すなわち個人認証機能を実行する。 - 件名に名前を割り当てる。（参照：識別名を参照してください。） - 件名が証明書に対して要求された属性を持つ権利があることを確認します。 - 被験者が証明書に要求された公開鍵と一致する秘密鍵を所有していることを確認します。 - キーペアの生成、トークンの配布、失効報告書、およびアーカイブデータなど、単なる登録を超えて機能を実行する。（そのような機能は、CAとRAの両方とは別のPKIコンポーネントに割り当てられます。）
3. (O) /SET/ "An independent third-party organization that processes payment card applications for multiple payment card brands and forwards applications to the appropriate financial institutions." [SET2]
3. （o）/ set / "複数の支払いカードブランドのための支払いカードアプリケーションを処理し、適切な金融機関に申請書を転送する独立したサードパーティ組織。」[SET2]
$ regrade (I) Deliberately change the security level (especially the hierarchical classification level) of information in an authorized manner. (See: downgrade, upgrade.)
$ Regrade（i）は、正規の方法でセキュリティレベル（特に階層分類レベル）を意図的に変更します。（検索、アップグレード、アップグレード）
$ rekey (I) Change the value of a cryptographic key that is being used in an application of a cryptographic system. (See: certificate rekey.)
$ REKEY（i）暗号化システムのアプリケーションで使用されている暗号鍵の値を変更します。（証明書の再登録を参照してください。）
Tutorial: Rekey is required at the end of a cryptoperiod or key lifetime.
チュートリアル：クリプリオットまたはキーの有効期間の末尾にREKEYが必要です。
$ reliability (I) The ability of a system to perform a required function under stated conditions for a specified period of time. (Compare: availability, survivability.)
$ 信頼性（i）指定された条件下で指定された関数を指定された期間にわたって実行する能力。（比較：可用性、生存可能性。）
$ reliable human review (I) Any manual, automated, or hybrid process or procedure that ensures that a human examines a digital object, such as text or an image, to determine whether the object may be permitted, according to some security policy, to be transferred across a controlled interface. (See: guard.)
$ 信頼性の高い人間のレビュー（i）人間がテキストや画像などのデジタルオブジェクトを検査して、あるセキュリティポリシーによると、あるセキュリティポリシーによると、テキストや画像などのデジタルオブジェクトを検査する手動、自動、またはハイブリッドプロセスまたは手順制御されたインターフェースを介して転送されます。（：警備員を参照してください。）
$ relying party (I) Synonym for "certificate user".
$ 「証明書user」の同義語。
Usage: Used in a legal context to mean a recipient of a certificate who acts in reliance on that certificate. (See: ABA Guidelines.)
使用法：その証明書への依存に役立つ証明書の受信者を意味するために法的コンテキストで使用されます。（参照：ABAガイドライン。）
$ remanence (I) Residual information that can be recovered from a storage medium after clearing. (See: clear, magnetic remanence, purge.)
$ 残留（i）クリア後に記憶媒体から回復することができる残差情報。（参照：クリア、磁気残留、パージ。）
$ Remote Authentication Dial-In User Service (RADIUS) (I) An Internet protocol [R2865] for carrying dial-in users' authentication information and configuration information between a shared, centralized authentication server (the RADIUS server) and a network access server (the RADIUS client) that needs to authenticate the users of its network access ports. (See: TACACS.)
$ リモート認証ダイヤルインユーザサービス（I）ダイヤルインユーザの認証情報と共有集中認証サーバ（RADIUSサーバ）とネットワークアクセスサーバの間の設定情報と構成情報のインターネットプロトコル[R2865]。ネットワークアクセスポートのユーザーを認証する必要があるRADIUS Client）。（TACACSを参照してください。）
User presents authentication and possibly other information to the RADIUS client (e.g., health information regarding the user device).
ユーザは、認証およびおそらく他の情報をRADIUSクライアントに提示する（例えば、ユーザ装置に関する健康情報）。
Tutorial: A user presents authentication information and possibly other information to the RADIUS client, and the client passes that information to the RADIUS server. The server authenticates the client using a shared secret value and checks the presented information, and then returns to the client all authorization and configuration information needed by the client to serve the user.
チュートリアル：ユーザーは認証情報とおそらく他の情報をRADIUSクライアントに提示し、その情報をRADIUSサーバーに渡します。サーバーは、共有秘密値を使用してクライアントを認証し、提示された情報をチェックしてから、クライアントがユーザーにサービスを提供するために必要なすべての許可および構成情報をクライアントに戻します。
$ renew See: certificate renewal.
$ 更新：証明書の更新。
$ reordering (I) /packet/ See: secondary definition under "stream integrity service".
$ 並べ替え（I）/パケット/参照：「Stream Integrity Service」の下のセカンダリ定義。
$ replay attack (I) An attack in which a valid data transmission is maliciously or fraudulently repeated, either by the originator or by a third party who intercepts the data and retransmits it, possibly as part of a masquerade attack. (See: active wiretapping, fresh, liveness, nonce. Compare: indirect attack, reflection attack.)
$ リプレイアタック（i）有効なデータ伝送が、オリジネータまたはデータを傍受し、それを再送信し、おそらくマスカレード攻撃の一部として、故意または不正に繰り返される攻撃。（Active Wirpaping、Fresh、Livity、Nonce。比較：間接攻撃、反射攻撃）
$ repository 1. (I) A system for storing and distributing digital certificates and related information (including CRLs, CPSs, and certificate policies) to certificate users. (Compare: archive, directory.)
$ リポジトリ1.（i）デジタル証明書および関連情報（CRL、CPSS、および証明書ポリシーを含む）を証明書ユーザに格納および配布するためのシステム。（比較：アーカイブ、ディレクトリ。）
2. (O) "A trustworthy system for storing and retrieving certificates or other information relevant to certificates." [DSG]
2. （O） "証明書または証明書に関連するその他の情報を保存および検索するための信頼できるシステム。」[DSG]
Tutorial: A certificate is published to those who might need it by putting it in a repository. The repository usually is a publicly accessible, on-line server. In the FPKI, for example, the expected repository is a directory that uses LDAP, but also may be an X.500 Directory that uses DAP, or an HTTP server, or an FTP server that permits anonymous login.
チュートリアル：証明書がそれをリポジトリに入れることによってそれを必要とするかもしれない人に公開されています。リポジトリは通常、アクセス可能なオンラインサーバーです。たとえば、FPKIでは、予期されるリポジトリはLDAPを使用するディレクトリですが、DAP、またはHTTPサーバー、または匿名ログインを許可するFTPサーバーでもあります。
$ repudiation 1. (I) Denial by a system entity that was involved in an association (especially a communication association that transfers data) of having participated in the relationship. (See: accountability, non-repudiation service.)
$ 繰り返し1.（i）関係に参加した協会（特にデータを転送する通信協会）に関与したシステム実体による否定。（説明責任、否認防止サービスを参照）
2. (I) A type of threat action whereby an entity deceives another by falsely denying responsibility for an act. (See: deception.) Usage: This type of threat action includes the following subtypes: - False denial of origin: Action whereby an originator denies responsibility for sending data. - False denial of receipt: Action whereby a recipient denies receiving and possessing data.
2.（i）ACTの責任を誤って否定することによって、企業が別の脅威を締めくくる脅威行動の一種です。（詐欺）使用法：このタイプの脅威アクションには、次のサブタイプが含まれています。 - False Originの拒否：オリジネータがデータの送信に対する責任を拒否します。 - 受信拒否：受信者がデータを受信して所有することを拒否する行動。
3. (O) /OSIRM/ "Denial by one of the entities involved in a communication of having participated in all or part of the communication." [I7498-2]
3. （O）/ OSIRR /「コミュニケーションの全部または一部に参加したことの通信に関与するエンティティの1つによって拒否されます。」[I7498-2]
$ Request for Comment (RFC) 1. (I) One of the documents in the archival series that is the official channel for IDOCs and other publications of the Internet Engineering Steering Group, the Internet Architecture Board, and the Internet community in general. (RFC 2026, 2223) (See: Internet Standard.)
$ （i）インターネットエンジニアリングステアリンググループ、インターネットアーキテクチャ盤、およびインターネットコミュニティのIDocの公式チャネルであるアーカイブシリーズ内の文書の1つ。（RFC 2026,2223）（インターネット規格を参照）
2. (D) A popularly misused synonym for a document on the Internet Standards Track, i.e., an Internet Standard, Draft Standard, or Proposed Standard. (See: Internet Standard.)
2. （d）インターネット標準の文書の一般的に誤って誤って誤ってシノニム、すなわちインターネット標準、ドラフト標準、または提案された標準。（インターネット規格を参照してください。）
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2 because many other types of documents also are published as RFCs.
廃止予定の定義：他の多くの種類の文書もRFCとして公開されているため、IDocは定義2でこの用語を使用しないでください。
$ residual risk (I) The portion of an original risk or set of risks that remains after countermeasures have been applied. (Compare: acceptable risk, risk analysis.)
$ 残留リスク（i）対策が適用された後に残っている元のリスクまたは一連のリスクの一部。（比較：許容できるリスク、リスク分析）
$ restore See: card restore.
$ 復元：カードの復元を参照してください。
$ reverse engineering (I) /threat action/ See: secondary definition under "intrusion".
$ リバースエンジニアリング（I）/脅威アクション/参照：「侵入」の下の二次定義。
$ revocation See: certificate revocation.
$ 失効：証明書失効
$ revocation date (N) /X.509/ In a CRL entry, a date-time field that states when the certificate revocation occurred, i.e., when the CA declared the digital certificate to be invalid. (See: invalidity date.)
$ 失効日（n）/ x.509/ CRLエントリでは、証明書の失効が発生したときに、すなわちCAがデジタル証明書を無効にすると宣言した日時フィールド。（有効日を参照してください。）
Tutorial: The revocation date may not resolve some disputes because, in the worst case, all signatures made during the validity period of the certificate may have to be considered invalid. However, it may be desirable to treat a digital signature as valid even though the private key used to sign was compromised after the signing. If more is known about when the compromise actually occurred, a second date-time, an "invalidity date", can be included in an extension of the CRL entry.
チュートリアル：失効日は、最悪の場合、証明書の有効期間中に行われたすべての署名が無効と見なされる必要があるかもしれないので、いくつかの紛争を解決することはできません。ただし、署名に使用されている秘密鍵が署名後に侵害されていても、デジタル署名を有効にすることが望ましい場合があります。妥協が実際に発生したときについてもっと知られている場合、2回目の日時、「無効日」をCRLエントリの拡張に含めることができます。
$ revocation list See: certificate revocation list.
$ 失効リスト[証明書失効]リストを参照してください。
$ revoke (I) See: certificate revocation.
$ REVOKE（i）証明書の失効を参照してください。
$ RFC (I) See: Request for Comment.
$ RFC（I）参照：コメントの要求を参照してください。
$ Rijndael (N) A symmetric, block cipher that was designed by Joan Daemen and Vincent Rijmen as a candidate for the AES, and that won that competition. [Daem] (See: Advanced Encryption Standard.)
$ Rijndael（n）Joan DaemenとVincent RijmenがAESの候補として設計された対称ブロック暗号、そしてそれはその競争を勝ち取った。[DAEM]（「高度な暗号化規格」を参照してください。）
$ risk 1. (I) An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result. (See: residual risk.)
$ リスク1.（i）特定の脅威が特定の有害な結果で特定の脆弱性を悪用する可能性として表明される損失の期待。（参照：残りのリスクを参照してください。）
2. (O) /SET/ "The possibility of loss because of one or more threats to information (not to be confused with financial or business risk)." [SET2]
2. （O）/ SET /「情報への1つ以上の脅威のため（金融リスクまたはビジネスリスクと混同されない）のため、損失の可能性。」[SET2]
Tutorial: There are four basic ways to deal with a risk [SP30]: - "Risk avoidance": Eliminate the risk by either countering the threat or removing the vulnerability. (Compare: "avoidance" under "security".) - "Risk transference": Shift the risk to another system or entity; e.g., buy insurance to compensate for potential loss. - "Risk limitation": Limit the risk by implementing controls that minimize resulting loss. - "Risk assumption": Accept the potential for loss and continue operating the system.
チュートリアル：リスクに対処するための4つの基本的な方法があります[SP30]： - 「リスク回避」：脅威に対抗するか、または脆弱性を解消することによってリスクを排除します。（比較：「セキュリティ」の下の「回避」） - 「リスクトランスレンス」：リスクを別のシステムまたはエンティティにシフトさせる。例えば、潜在的な損失を補償するためのBuy Insurance。 - 「リスク制限」：結果として生じる損失を最小限に抑えるコントロールを実装することでリスクを制限します。 - 「リスクの仮定」：損失の可能性を受け入れ、システムの運用を続けます。
$ risk analysis (I) An assessment process that systematically (a) identifies valuable system resources and threats to those resources, (b) quantifies loss exposures (i.e., loss potential) based on estimated frequencies and costs of occurrence, and (c) (optionally) recommends how to allocate available resources to countermeasures so as to minimize total exposure. (See: risk management, business-case analysis. Compare: threat analysis.) Tutorial: Usually, it is financially and technically infeasible to avoid or transfer all risks (see: "first corollary" of "second law" under "Courtney's laws"), and some residual risks will remain, even after all available countermeasures have been deployed (see: "second corollary" of "second law" under "Courtney's laws"). Thus, a risk analysis typically lists risks in order of cost and criticality, thereby determining where countermeasures should be applied first. [FP031, R2196]
$リスク分析（i）体系的に（a）は、貴重なシステムリソースとそれらのリソースに対する脅威を特定し、（b）推定周波数と発生コストに基づく損失曝露（損失ポテンシャル）を定量化します。任意選択で、総露出を最小限に抑えるために、対策に利用可能なリソースをどのように割り当てるかを推奨します。（リスク管理、ビジネスケース分析。比較：脅威分析。）チュートリアル：通常、すべてのリスクを回避または譲渡することが財政的かつ技術的に実行不可能です（「Courtney's Laws」の「第2件の「第一議論」の「第一議論」利用可能なすべての対策が展開された後でさえも、残りのリスクの中には残りのリスクが残っています（「Courtney's Laws」の下の「2番目の議論」の「第二の冠詞」）。したがって、リスク分析は通常、コストと臨界度の順にリスクを列挙し、それによって最初に対策を適用する場所を決定します。[FP031、R2196]
In some contexts, it is infeasible or inadvisable to attempt a complete or quantitative risk analysis because needed data, time, and expertise are not available. Instead, basic answers to questions about threats and risks may be already built into institutional security policies. For example, U.S. DoD policies for data confidentiality "do not explicitly itemize the range of expected threats" but instead "reflect an operational approach ... by stating the particular management controls that must be used to achieve [confidentiality] ... Thus, they avoid listing threats, which would represent a severe risk in itself, and avoid the risk of poor security design implicit in taking a fresh approach to each new problem". [NRC91]
いくつかの状況では、必要なデータ、時間、および専門知識が利用できないため、完全または定量的リスク分析を試みることが不可能であるか不可能である。代わりに、脅威とリスクについての質問に対する基本的な回答は、既に機関のセキュリティポリシーに組み込まれている可能性があります。たとえば、データ機密性のための米国のDODポリシー「予想される脅威の範囲を明示的に明示的に箇条化させないでください」と、「機密性」を達成するために使用されなければならない特定の管理コントロールを述べることで、彼らは脅威のリストを避けています。[NRC91]
$ risk assumption (I) See: secondary definition under "risk".
$ リスクの仮定（i）「リスク」の下の二次定義を参照してください。
$ risk avoidance (I) See: secondary definition under "risk".
$ リスク回避（i）「リスク」の下の二次定義を参照してください。
$ risk limitation (I) See: secondary definition under "risk".
$ リスク制限（i）「リスク」の下の二次定義。
$ risk management 1. (I) The process of identifying, measuring, and controlling (i.e., mitigating) risks in information systems so as to reduce the risks to a level commensurate with the value of the assets protected. (See: risk analysis.)
$ リスク管理1.（i）保護された資産の価値に応じたレベルへのリスクを減らすために、情報システムにおけるリスクを特定する、測定、制御するプロセス（すなわち、情報システムの軽減）のプロセス。（リスク分析を参照してください。）
2. (I) The process of controlling uncertain events that may affect information system resources.
2. （i）情報システムリソースに影響を与える可能性がある不確実なイベントを制御するプロセス。
3. (O) "The total process of identifying, controlling, and mitigating information system-related risks. It includes risk assessment; cost-benefit analysis; and the selection, implementation, test, and security evaluation of safeguards. This overall system security review considers both effectiveness and efficiency, including impact on the mission and constraints due to policy, regulations, and laws." [SP30]
3. （O） "情報システム関連のリスクの識別、制御、および軽減の全プロセス。リスクアセスメントが含まれます。費用便益分析および保障措置の選択、実施、試験、およびセキュリティ評価。このシステム全体のセキュリティレビュー政策、規制、法律による任務と制約への影響を含む有効性と効率の両方。」[SP30]
$ risk transference (I) See: secondary definition under "risk".
$ リスクトランスファー（I）「リスク」の下の二次定義を参照してください。
$ Rivest Cipher #2 (RC2) (N) A proprietary, variable-key-length block cipher invented by Ron Rivest for RSA Data Security, Inc.
$ RIVEST CISHIPH＃2（RC2）（N）RON RIVESTがRSA Data Security、Inc。の独自の可変キー長ブロック暗号化
$ Rivest Cipher #4 (RC4) (N) A proprietary, variable-key-length stream cipher invented by Ron Rivest for RSA Data Security, Inc.
$ RIVAST CISHIPH＃4（RC4）（N）RON RIVESTがRSA Data Security、Inc。の独自の可変キー長ストリーム暗号化
$ Rivest Cipher #6 (RC6) (N) A symmetric, block cipher with 128-bit or longer key length, developed by Ron Rivest for RSA Data Security, Inc. as a candidate for the AES.
$ RIVAST Data Security、Inc。がAESの候補としてRON Rivest、Inc。がRON Rivest、Inc。によって開発された、128ビット以上のキー長を持つ対称ブロック暗号（N）。
$ Rivest-Shamir-Adleman (RSA) (N) An algorithm for asymmetric cryptography, invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78].
$ RIVEST-SHARIVIR-ADLEMAN（RSA）（N）1977年にRON RIVEST、ADI Shamir、およびLeonard Adleman [RSA78]によって発明された非対称暗号化のためのアルゴリズム。
Tutorial: RSA uses exponentiation modulo the product of two large prime numbers. The difficulty of breaking RSA is believed to be equivalent to the difficulty of factoring integers that are the product of two large prime numbers of approximately equal size.
チュートリアル：RSAは、2つの大きな素数の積を指数モジュロを使用しています。RSAを破るのの難しさは、2つの大きなサイズの2つの大きな素数の積である整数を因数調整することの困難さと同等であると考えられています。
To create an RSA key pair, randomly choose two large prime numbers, p and q, and compute the modulus, n = pq. Randomly choose a number e, the public exponent, that is less than n and relatively prime to (p-1)(q-1). Choose another number d, the private exponent, such that ed-1 evenly divides (p-1)(q-1). The public key is the set of numbers (n,e), and the private key is the set (n,d).
RSA鍵ペアを作成するには、ランダムに2つの大きな素数PとQを選択し、モジュラスN = PQを計算します。ランダムに数E、公共の指数、つまりNより小さい（P-1）（P-1）（Q-1）を選択します。ED-1が均等に分割される（P-1）（Q-1）になるように、別の番号D、民間指数を選択してください。公開鍵は数字（n、e）のセットです、そして秘密鍵はセット（n、d）です。
It is assumed to be difficult to compute the private key (n,d) from the public key (n,e). However, if n can be factored into p and q, then the private key d can be computed easily. Thus, RSA security depends on the assumption that it is computationally difficult to factor a number that is the product of two large prime numbers. (Of course, p and q are treated as part of the private key, or else are destroyed after computing n.)
公開鍵（N、E）から秘密鍵（N、D）を計算することは困難であると仮定されています（N、E）。しかしながら、NがPおよびQに触れることができる場合、秘密鍵Dは容易に計算することができる。したがって、RSAセキュリティは、2つの大きな素数の積である数値を率することが計算的に困難であるという仮定に依存します。（もちろん、PとQは秘密鍵の一部として扱われるか、またはコンピューティング後に破棄されます。）
For encryption of a message, m, to be sent to Bob, Alice uses Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob can compute c**d (mod n) to recover m.
メッセージを暗号化するために、M、BOBに送信されるMは、BOBの公開鍵（N、E）を使用してM ** E（MOD N）= Cを計算します。彼女はBobにCを送ります。BOBはC ** D（MOD N）= Mを計算します。ボブのみDを知っているので、BのみがMを復元するためにC ** D（MOD N）を計算できます。
To provide data origin authentication of a message, m, to be sent to Bob, Alice computes m**d (mod n) = s, where (d,n) is Alice's private key. She sends m and s to Bob. To recover the message that only Alice could have sent, Bob computes s**e (mod n) = m, where (e,n) is Alice's public key.
BOBに送信されるメッセージのデータ原点認証を提供するために、AliceはM ** D（MOD N）= Sを計算します。ここで、（D、N）はAliceの秘密鍵です。彼女はmとsをボブに送ります。アリスだけが送信された可能性があるというメッセージを回復するには、BOBはS ** E（MOD N）= M、ここで（E、N）はAliceの公開鍵です。
To ensure data integrity in addition to data origin authentication requires extra computation steps in which Alice and Bob use a cryptographic hash function h (see: digital signature). Alice computes the hash value h(m) = v, and then encrypts v with her private key to get s. She sends m and s. Bob receives m' and s', either of which might have been changed from the m and s that Alice sent. To test this, he decrypts s' with Alice's public key to get v'. He then computes h(m') = v". If v' equals v", Bob is assured that m' is the same m that Alice sent.
データの原点認証に加えてデータの整合性を確保するには、アリスとボブが暗号化ハッシュ関数Hを使用する追加の計算ステップを必要とします（デジタル署名を参照）。アリスはハッシュ値H（m）= vを計算してから、秘密鍵とvを暗号化してSを取得します。彼女はmとsを送ります。BobはM 'とS'を受信し、そのどちらもMとSから変更されたことがあります。これをテストするために、彼はv 'を得るためにアリスの公開鍵とs'を復号化します。彼は次にh（m '）= v "を計算します。v'がv"の場合、BobはM 'が同じMであると同じmであることが保証されます。
$ robustness (N) See: level of robustness.
$ 堅牢性（N）参照：堅牢性のレベル。
$ role 1. (I) A job function or employment position to which people or other system entities may be assigned in a system. (See: role-based access control. Compare: duty, billet, principal, user.)
$ 役割1.（i）システム内で人々または他のシステムエンティティが割り当てられる仕事関数または雇用位置。（役割ベースのアクセス制御を参照してください。比較：義務、ビレット、プリンシパル、ユーザー。）
2. (O) /Common Criteria/ A pre-defined set of rules establishing the allowed interactions between a user and the TOE.
2. （O）/共通基準/ユーザーとつま先の間の許可された相互作用を確立する規則の事前定義されたセット。
$ role-based access control (I) A form of identity-based access control wherein the system entities that are identified and controlled are functional positions in an organization or process. [Sand] (See: authorization, constraint, identity, principal, role.)
$ 役割ベースのアクセス制御（i）識別され制御されるシステムエンティティが組織またはプロセスにおける機能的位置である識別ベースのアクセス制御の形式。[砂]（承認、制約、身元、校長、役割を参照）
Tutorial: Administrators assign permissions to roles as needed to perform functions in the system. Administrators separately assign user identities to roles. When a user accesses the system in an identity (for which the user has been registered) and initiates a session using a role (to which the user has been assigned), then the permissions that have been assigned to the role are available to be exercised by the user.
チュートリアル：管理者は、システム内の機能を実行するために必要に応じてロールに権限を割り当てます。管理者は、ユーザーIDをロールに個別に割り当てます。ユーザーがシステムに（ユーザーが登録されている）でシステムにアクセスし、（ユーザーが割り当てられている役割を使用してセッションを開始すると、役割に割り当てられている権限は実行されます。ユーザーによって。
The following diagram shows that role-based access control involves five different relationships: (a) administrators assign identities to roles, (b) administrators assign permissions to roles, (c) administrators assign roles to roles, (d) users select identities in sessions, and (e) users select roles in sessions. Security policies may define constraints on these assignments and selections.
次の図は、ロールベースのアクセス制御に5つの異なる関係が含まれていることを示しています。（a）管理者は役割へのIDを割り当てる、（b）管理者に権限を割り当てる、（c）管理者はロールへの役割を割り当てます、（d）ユーザーはセッションのIDを選択します（e）ユーザーはセッションで役割を選択します。セキュリティポリシーは、これらの割り当てと選択に制約を定義できます。
(c) Permission Inheritance Assignments (i.e., Role Hierarchy)
[Constraints]
+=====+
| |
(a) Identity v v (b) Permission
+----------+ Assignments +-------+ Assignments +----------+
|Identities|<=============>| Roles |<=============>|Permissions|
+----------+ [Constraints] +-------+ [Constraints] +----------+
| | ^ ^
| | +-----------+ | | +---------------------+
| | | +-------+ | | | | Legend |
| +====>|Session|=====+ | | |
| | +-------+ | | | One-to-One |
| | ... | | | =================== |
| | +-------+ | | | |
+========>|Session|=========+ | One-to-Many |
(d) Identity | +-------+ | (e) Role | ==================> |
Selections | | Selections | |
[Constraints]| Access |[Constraints] | Many-to-Many |
| Sessions | | <=================> |
+-----------+ +---------------------+
$ role certificate (I) An organizational certificate that is issued to a system entity that is a member of the set of users that have identities that are assigned to the same role. (See: role-based access control.)
$ 役割証明書（i）同じ役割に割り当てられているIDを持つユーザーのセットのメンバーであるシステムエンティティに発行された組織証明書。（「役割ベースのアクセス制御」を参照してください。
$ root, root CA 1. (I) /PKI/ A CA that is directly trusted by an end entity. (See: trust anchor, trusted CA.)
$ ルート、ルートCA 1.（i）/ PKI / A CAエンドエンティティによって直接信頼されています。（：信頼のアンカー、信頼されたCAを参照）
2. (I) /hierarchical PKI/ The CA that is the highest level (most trusted) CA in a certification hierarchy; i.e., the authority upon whose public key all certificate users base their validation of certificates, CRLs, certification paths, and other constructs. (See: top CA.)
2. （i）/階層PKI / CAは、認証階層内の最高レベル（最も信頼できる）CAです。すなわち、公開鍵全ての証明書ユーザが証明書、CRL、認証パス、およびその他の構成要素の検証を基礎とする権限。（参照：トップCA.）
Tutorial: The root CA in a certification hierarchy issues public-key certificates to one or more additional CAs that form the second-highest level. Each of these CAs may issue certificates to more CAs at the third-highest level, and so on. To initialize operation of a hierarchical PKI, the root's initial public key is securely distributed to all certificate users in a way that does not depend on the PKI's certification relationships, i.e., by an out-of-band procedure. The root's public key may be distributed simply as a numerical value, but typically is distributed in a self-signed certificate in which the root is the subject. The root's certificate is signed by the root itself because there is no higher authority in a certification hierarchy. The root's certificate is then the first certificate in every certification path.
チュートリアル：認証階層内のルートCAは、2番目に高いレベルを形成する1つ以上の追加のCASに公開鍵証明書を発行します。これらのCAはそれぞれ、3番目の最高レベルでもっとCASに証明書を発行することができます。階層型PKIの動作を初期化するために、ルートの最初の公開鍵は、PKIの認証関係、すなわち帯域外手順によって依存しない方法で、すべての証明書ユーザに安全に分散される。ルートの公開鍵は単に数値として分配されてもよいが、通常、根が件名の自己署名証明書に配布されている。認証階層には、根本の証明書はルート自体によって署名されています。ルートの証明書は、すべての認証パスの最初の証明書です。
3. (I) /DNS/ The base of the tree structure that defines the name space for the Internet DNS. (See: domain name.)
3. （i）/ dns /インターネットDNSの名前空間を定義するツリー構造のベース。（ドメイン名を参照してください。）
4. (O) /MISSI/ A name previously used for a MISSI policy creation authority, which is not a root as defined above for general usage, but is a CA at the second level of the MISSI hierarchy, immediately subordinate to a MISSI policy approving authority.
4. （O）/ MISSI /以前に使用された名前Missi Policy Creation Authoryで使用されていた名前は、一般的な使用法については上で定義されている根本ではなく、Missi階層の2番目のレベルのCAです。。
5. (O) /UNIX/ A user account (a.k.a. "superuser") that has all privileges (including all security-related privileges) and thus can manage the system and its other user accounts.
5. （O）/ UNIX /すべての権限（すべてのセキュリティ関連特権を含む）を持ち、システムとその他のユーザーアカウントを管理できます。
$ root certificate 1. (I) /PKI/ A certificate for which the subject is a root. (See: trust anchor certificate, trusted certificate.)
$ ルート証明書1.（i）/ PKI /対象が根付いている証明書。（「信頼証明書、信頼できる証明書」を参照してください。
2. (I) /hierarchical PKI/ The self-signed public-key certificate at the top of a certification hierarchy.
2. （i）/階層PKI /認証階層の上部の自己署名の公開鍵証明書。
$ root key (I) /PKI/ A public key for which the matching private key is held by a root. (See: trust anchor key, trusted key.)
$ ルートキー（i）/ PKI /絶対キーがルートによって保持されている公開鍵。（以下を参照してください。
$ root registry (O) /MISSI/ A name previously used for a MISSI PAA.
$ ルートレジストリ（O）/ MISSI /以前にMissi PAAに使用されていた名前。
$ ROT13 (I) See: secondary definition under "Caesar cipher".
$ ROT13（i）「Caesar暗号」の下の二次定義。
$ router 1a. (I) /IP/ A networked computer that forwards IP packets that are not addressed to the computer itself. (Compare: host.)
$ ルータ1A。（i）/ IP /コンピュータ自体に対処されていないIPパケットを転送するネットワークコンピュータ。（比較：ホスト。）
1b. (I) /IPS/ A gateway that operates in the IPS Internet Layer to connect two or more subnetworks.
1b。（i）/ IPS / IPSインターネットレイヤで動作するゲートウェイは、2つ以上のサブネットワークを接続します。
1c. (N) /OSIRM/ A computer that is a gateway between two networks at OSIRM Layer 3 and that relays and directs data packets through that internetwork. (Compare: bridge, proxy.)
1c。（n）/ OSIRM / OSIRMレイヤ3の2つのネットワーク間のゲートウェイであるコンピュータとその中継器、およびそのインターネットワークを通してデータパケットを転送します。（比較：ブリッジ、プロキシ。）
$ RSA (N) See: Rivest-Shamir-Adleman.
$ RSA（N）参照：Rivest-Shamir-Adleman。
$ rule See: policy rule.
$ ルール参照：ポリシールール。
$ rule-based security policy (I) "A security policy based on global rules [i.e., policy rules] imposed for all users. These rules usually rely on comparison of the sensitivity of the resource being accessed and the possession of corresponding attributes of users, a group of users, or entities acting on behalf of users." [I7498-2] (Compare: identity-based security policy, policy rule, RBAC.)
$ ルールベースのセキュリティポリシー（i） "グローバルな規則に基づくセキュリティポリシー[すなわちポリシールール]はすべてのユーザーに課されました。これらの規則は通常、アクセスされているリソースの感度とユーザーの対応する属性の所有の比較に依存しています。ユーザーのグループ、またはユーザーに代わって行動するエンティティ。」[I7498-2]（比較：IDベースのセキュリティポリシー、ポリシールール、RBAC）
$ rules of behavior (I) A body of security policy that has been established and implemented concerning the responsibilities and expected behavior of entities that have access to a system. (Compare: [R1281].)
$ 行動規則（i）システムにアクセスできるエンティティの責任と予想される行動に関して確立され実現されたセキュリティポリシーの体。（比較：[R1281]）
Tutorial: For persons employed by a corporation or government, the rules might cover such matters as working at home, remote access, use of the Internet, use of copyrighted works, use of system resources for unofficial purpose, assignment and limitation of system privileges, and individual accountability.
チュートリアル：企業や政府によって雇用されている人のために、ルールは、自宅での作業、リモートアクセス、インターネットの使用、著作物の使用、著作物の使用、非公式の目的のためのシステムリソースの使用、システム権限の制限の使用などの問題をカバーする可能性があります。そして個々の説明責任。
$ S field (D) See: Security Level field.
$ ■フィールド（D）セキュリティレベルフィールドを参照してください。
$ S-BGP (I) See: Secure BGP.
$ S-BGP（i）Secure BGPを参照してください。
$ S-HTTP (I) See: Secure Hypertext Transfer Protocol.
$ S-HTTP（i）Secure Hypertext Transfer Protocolを参照してください。
$ S/Key (I) A security mechanism that uses a cryptographic hash function to generate a sequence of 64-bit, one-time passwords for remote user login. [R1760]
$ s / key（i）暗号化ハッシュ関数を使用して、リモートユーザログイン用の64ビットの1回限りのパスワードを生成するセキュリティメカニズム。[R1760]
Tutorial: The client generates a one-time password by applying the MD4 cryptographic hash function multiple times to the user's secret key. For each successive authentication of the user, the number of hash applications is reduced by one. (Thus, an intruder using wiretapping cannot compute a valid password from knowledge of one previously used.) The server verifies a password by hashing the currently presented password (or initialization value) one time and comparing the hash result with the previously presented password.
チュートリアル：クライアントは、MD4暗号化ハッシュ関数をユーザーの秘密鍵に複数回適用することによってワンタイムパスワードを生成します。ユーザの連続認証ごとに、ハッシュアプリケーションの数が1つ減少する。（したがって、盗聴を使用した侵入者は、以前から使用されているものの知識から有効なパスワードを計算できません。）現在提示されているパスワード（または初期化値）を1回ハッシュし、ハッシュ結果と以前に提示されたパスワードを比較することによってパスワードを検証します。
$ S/MIME (I) See: Secure/MIME.
$ S / MIME（I）を参照してください。
$ SAD (I) See: Security Association Database.
$ sad（i）セキュリティアソシエーションデータベースを参照してください。
$ safety (I) The property of a system being free from risk of causing harm (especially physical harm) to its system entities. (Compare: security.)
$ 安全性（i）システムの財産（特に身体的危害）をシステム事業体に解放する危険性がない。（比較：セキュリティ。）
$ SAID (I) See: security association identifier.
$ 述べた（i）セキュリティアソシエーション識別子を参照してください。
$ salami swindle (D) /slang/ "Slicing off a small amount from each transaction. This kind of theft was made worthwhile by automation. Given a high transaction flow, even rounding down to the nearest cent and putting the 'extra' in a bogus account can be very profitable." [NCSSG]
$ サラミスワンドル（D）/スラング/「各取引から少量消灯しています。この種の盗難は自動化によって価値がある。高いトランザクションフローを与えられた。アカウントは非常に収益性が得られます。」[NCSSG]
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ salt (I) A data value used to vary the results of a computation in a security mechanism, so that an exposed computational result from one instance of applying the mechanism cannot be reused by an attacker in another instance. (Compare: initialization value.)
$ SALT（i）セキュリティメカニズムにおける計算の結果を変えるために使用されるデータ値を、そのメカニズムを適用する1つのインスタンスからの露出計算結果は、別のインスタンスの攻撃者によって再利用できない。（比較：初期化値）
Example: A password-based access control mechanism might protect against capture or accidental disclosure of its password file by applying a one-way encryption algorithm to passwords before storing them in the file. To increase the difficulty of off-line, dictionary attacks that match encrypted values of potential passwords against a copy of the password file, the mechanism can concatenate each password with its own random salt value before applying the one-way function.
例：パスワードベースのアクセス制御メカニズムは、ファイルに格納する前に、パスワードファイルのキャプチャまたは偶発的な開示から、一方向の暗号化アルゴリズムをパスワードに適用することによって保護することがあります。オフラインの困難さを増すために、パスワードファイルのコピーに対して潜在的なパスワードの暗号化された値に一致する辞書攻撃を増やすと、そのメカニズムは、一方向機能を適用する前に、各パスワードを独自のランダムな塩値と連結できます。
$ SAML (N) See: Security Assertion Markup Language (SAML).
$ SAML（N）は、セキュリティアサーションマークアップ言語（SAML）を参照してください。
$ sandbox (I) A restricted, controlled execution environment that prevents potentially malicious software, such as mobile code, from accessing any system resources except those for which the software is authorized.
$ SandBox（i）モバイルコードなどの悪意のあるソフトウェアが承認されているものを除く、潜在的に悪意のあるソフトウェアを妨げる制限された制御実行環境。
$ sanitize 1. (I) Delete sensitive data from a file, device, or system. (See: erase, zeroize.)
$ サニタイズ1.（i）ファイル、デバイス、またはシステムから機密データを削除します。（：消去、ゼロ化。）
2. (I) Modify data so as to be able either (a) to completely declassify it or (b) to downgrade it to a lower security level.
2. （i）（a）のどちらか（a）のどちらかを圧縮することができるようにデータを修正して（b）を下げるためにそれをより低いセキュリティレベルにダウングレードすることができる。
$ SAP (O) See: special access program.
$ SAP（O）特別アクセスプログラムを参照してください。
$ SASL (I) See: Simple Authentication and Security Layer.
$ SASL（i）：単純認証とセキュリティ層を参照してください。
$ SCA (I) See: subordinate certification authority.
$ SCA（I）下記の認証局を参照してください。
$ scavenging (I) /threat action/ See: secondary definition under "exposure".
$ 掃気（i）/脅威の対応/参照：「露出」の下の二次定義。
$ SCI (O) See: sensitive compartmented information.
$ SCI（O）は、敏感なコンパートメント情報を参照してください。
$ SCIF (O) See: sensitive compartmented information facility.
$ SCIF（O）敏感なコンパートメント情報施設を参照してください。
$ SCOMP (N) Secure COMmunications Processor; an enhanced, MLS version of the Honeywell Level 6 minicomputer. It was the first system to be rated in TCSEC Class A1. (See: KSOS.)
$ SCOMP（N）安全な通信プロセッサ。Honeywellレベル6のミニコンピュータの拡張されたMLSバージョン。TCSECクラスA1に評価される最初のシステムでした。（ksosを参照）
$ screen room (D) /slang/ Synonym for "shielded enclosure" in the context of electromagnetic emanations. (See: EMSEC, TEMPEST.)
$ 電磁放散の文脈における「シールドエンクロージャ」のスクリーンルーム（D）/スラング/シノニム。（Emsec、Tempest。）
Deprecated Term: To avoid international misunderstanding, IDOCs SHOULD NOT use this term.
廃止予定の用語：国際誤解を避けるために、IDOCはこの用語を使用しないでください。
$ screening router (I) Synonym for "filtering router".
$ スクリーニングルータ（I）「ルータのフィルタリング」の同義語。
$ script kiddy (D) /slang/ A cracker who is able to use existing attack techniques (i.e., to read scripts) and execute existing attack software, but is unable to invent new exploits or manufacture the tools to perform them; pejoratively, an immature or novice cracker.
$ 既存の攻撃技術を使用して既存の攻撃ソフトウェアを実行することができるが、それらを実行するために新しい攻撃技術を使用することができないスクリプトキディ（D）/ Slang / Cracker。PEJORATION、未熟または初心者のクラッカー。
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ SDE (N) See: Secure Data Exchange.
$ SDE（N）は、安全なデータ交換を参照してください。
$ SDNS (O) See: Secure Data Network System.
$ SDNS（O）Secure Data Network Systemを参照してください。
$ SDU (N) See: "service data unit" under "protocol data unit".
$ SDU（N）「プロトコルデータユニット」の「サービスデータユニット」を参照してください。
$ seal 1. (I) To use asymmetric cryptography to encrypt plain text with a public key in such a way that only the holder of the matching private key can learn what was the plain text. [Chau] (Compare: shroud, wrap.)
$ シール1.（i）一致する秘密鍵の保有者だけがプレーンテキストであることを学ぶことができるように、プレーンテキストを公開鍵で暗号化するために非対称暗号化を使用する。[Chau]（比較：シュラウド、ラップ。）
Deprecated Usage: An IDOC SHOULD NOT use this term with definition 1 unless the IDOC includes the definition, because the definition is not widely known and the concept can be expressed by using other, standard terms. Instead, use "salt and encrypt" or other terminology that is specific with regard to the mechanism being used.
廃止予定の使用法：定義が広く知られておらず、概念は他の標準用語を使用して表現できるため、IDocは定義1でこの用語を使用しないでください。代わりに、「塩と暗号化」または使用されているメカニズムに関して具体的な他の用語を使用してください。
Tutorial: The definition does *not* say "only the holder of the matching private key can decrypt the ciphertext to learn what was the plaintext"; sealing is stronger than that. If Alice simply encrypts a plaintext P with a public key K to produce ciphertext C = K(P), then if Bob guesses that P = X, Bob could verify the guess by checking whether K(P) = K(X). To "seal" P and block Bob's guessing attack, Alice could attach a long string R of random bits to P before encrypting to produce C = K(P,R); if Bob guesses that P = X, Bob can only test the guess by also guessing R. (See: salt.)
チュートリアル：定義は* * NOT * SONE *言っていません。「平文は、平文を学ぶために暗号文を復号化することができます」と言う。シーリングはそれより強いです。Aliceが公開鍵kを使って平文Pを単に暗号化する場合、BobがP = Xを推測する場合、BOBは、k（p）= k（x）かどうかをチェックすることによって推測を検証することができます。PとBOBの推測攻撃を「シール」するために、Aliceは、C = K（P、R）を生成するために暗号化する前に、ランダムビットの長い文字列RをPに接続することができます。BOBがP = Xを推測する場合、BOBはRを推測することによってのみ推測をテストすることしかできません（塩を参照）。
2. (D) To use cryptography to provide data integrity service for a data object. (See: sign.)
2. （d）データオブジェクトのデータ整合性サービスを提供するために暗号化を使用する。（参照してください。）
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2. Instead, use a term that is more specific with regard to the mechanism used to provide the data integrity service; e.g., use "sign" when the mechanism is digital signature.
非推奨の定義：IDocは定義2でこの用語を使用しないでください。代わりに、データ整合性サービスを提供するために使用されるメカニズムに関してより具体的な用語を使用します。例えば、メカニズムがデジタル署名の場合は「サイン」を使用してください。
$ secret 1a. (I) /adjective/ The condition of information being protected from being known by any system entities except those that are intended to know it. (See: data confidentiality.)
$ 秘密1A。（i）/形容詞/情報の条件は、それを知ることを意図しているものを除くすべてのシステムエンティティによって知られていることから保護されています。（データ機密性を参照してください。）
1b. (I) /noun/ An item of information that is protected thusly.
1b。（i）/名詞/保護されている情報の項目。
Usage: This term applies to symmetric keys, private keys, and passwords.
使用法：この用語は、対称鍵、秘密鍵、およびパスワードに適用されます。
$ secret key (D) A key that is kept secret or needs to be kept secret.
$ 秘密鍵（D）秘密に保たれるか、または秘密にされる必要があるキー。
Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts in a potentially misleading way. In the context of asymmetric cryptography, IDOCs SHOULD use "private key". In the context of symmetric cryptography, the adjective "secret" is unnecessary because all keys must be kept secret.
廃止予定語：IDocsはこの用語を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。非対称暗号化の文脈では、IDOCは「秘密鍵」を使用する必要があります。対称暗号化の文脈では、すべてのキーを秘密にする必要があるため、形容詞「秘密」は不要です。
$ secret-key cryptography (D) Synonym for "symmetric cryptography".
$ 秘密鍵暗号（D）「対称暗号化」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it could be confused with "asymmetric cryptography", in which the private key is kept secret.
廃止予定語：IDocsはこの用語を使用しないでください。秘密鍵が秘密にされている「非対称暗号」と混同することができます。
Derivation: Symmetric cryptography is sometimes called "secret-key cryptography" because entities that share the key, such as the originator and the recipient of a message, need to keep the key secret from other entities.
派生：Symmetric Cryptographyは、発信者やメッセージの受信者などのキーを共有するエンティティが他のエンティティから鍵を秘密にする必要があるため、「Secret-Key暗号化」と呼ばれます。
$ Secure BGP (S-BGP) (I) A project of BBN Technologies, sponsored by the U.S. DoD's Defense Advanced Research Projects Agency, to design and demonstrate an architecture to secure the Border Gateway Protocol (RFC 1771) and to promote deployment of that architecture in the Internet.
$ Secure BGP（S-BGP）（I）米国のDODの国防上級研究プロジェクト機構が後援するBBN技術のプロジェクトは、国境ゲートウェイプロトコル（RFC 1771）を設計し、そのアーキテクチャの展開を推進するためのアーキテクチャを設計して実証するプロジェクト。インタネットの中には。
Tutorial: S-BGP incorporates three security mechanisms: - A PKI supports authentication of ownership of IP address blocks, autonomous system (AS) numbers, an AS's identity, and a BGP router's identity and its authorization to represent an AS. This PKI parallels and takes advantage of the Internet's existing IP address and AS number assignment system. - A new, optional, BGP transitive path attribute carries digital signatures (in "attestations") covering the routing information in a BGP UPDATE. These signatures along with certificates from the S-BGP PKI enable the receiver of a BGP routing UPDATE to validate the attribute and gain trust in the address prefixes and path information that it contains. - IPsec provides data and partial sequence integrity, and enables BGP routers to authenticate each other for exchanges of BGP control traffic.
チュートリアル：S-BGPは3つのセキュリティメカニズムを組み込んでいます。このPKIは、インターネットの既存のIPアドレスと番号割当システムを利用しています。 - 新しい、オプションのBGP推移パス属性は、BGPアップデート内のルーティング情報をカバーするデジタル署名（「検証」）を搬送します。S-BGP PKIからの証明書と共にこれらのシグネチャを使用すると、BGPルーティングアップデートの受信側を有効にして属性を検証し、それが含むアドレスプレフィックスとパス情報を信頼します。 - IPSecはデータと部分的なシーケンスの整合性を提供し、BGPルータはBGP制御トラフィックの交換のために互いに認証できるようになります。
$ Secure Data Exchange (SDE) (N) A LAN security protocol defined by the IEEE 802.10 standard.
$ Secure Data Exchange（SDE）（N）IEEE 802.10規格によって定義されたLANセキュリティプロトコル。
$ Secure Data Network System (SDNS) (O) An NSA program that developed security protocols for electronic mail (see: MSP), OSIRM Layer 3 (see: SP3), OSIRM Layer 4 (see: SP4), and key establishment (see: KMP).
$ セキュアデータネットワークシステム（SDNS）（O）電子メールのセキュリティプロトコルを開発したNSAプログラム（MSP）、OSIRMレイヤ3（SP3参照）、OSIRMレイヤ4（SP4参照）、およびキー設立（参照）KMP）。
$ secure distribution (I) See: trusted distribution.
$ 安全な配布（I）信頼できる配布を参照してください。
$ Secure Hash Algorithm (SHA) (N) A cryptographic hash function (specified in SHS) that produces an output (see: "hash result") -- of selectable length of either 160, 224, 256, 384, or 512 bits -- for input data of any length < 2**64 bits.
$ 安全なハッシュアルゴリズム（SHA）（SHA）（N）出力を生成する暗号化ハッシュ関数（SHSで指定）（「ハッシュ結果」） - 160,224,256,384、または512ビットの選択可能な長さの選択 - 任意の長さ<2 ** 64ビットの入力データの場合。
$ Secure Hash Standard (SHS) (N) The U.S. Government standard [FP180] that specifies SHA.
$ 安全なハッシュ標準（SHS）（N）SHAを指定する米国政府標準[FP180]。
$ Secure Hypertext Transfer Protocol (S-HTTP) (I) An Internet protocol [R2660] for providing client-server security services for HTTP communications. (Compare: https.)
$ Secure HyperText Transfer Protocol（S-HTTP）（i）HTTP通信用のクライアントサーバーセキュリティサービスを提供するためのインターネットプロトコル[R2660]。（比較：https。）
Tutorial: S-HTTP was originally specified by CommerceNet, a coalition of businesses interested in developing the Internet for commercial uses. Several message formats may be incorporated into S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP supports choice of security policies, key management mechanisms, and cryptographic algorithms through option negotiation between parties for each transaction. S-HTTP supports modes of operation for both asymmetric and symmetric cryptography. S-HTTP attempts to avoid presuming a particular trust model, but it attempts to facilitate multiply rooted, hierarchical trust and anticipates that principals may have many public-key certificates.
チュートリアル：S-HTTPはもともと商業用途のためのインターネットの開発に興味がある企業の連合であるCorcrolseReで指定されました。いくつかのメッセージフォーマットは、S - HTTPクライアントおよびサーバ、特にCMSおよびMOSSに組み込まれてもよい。S-HTTPは、各取引のパーティー間のオプション交渉を通じて、セキュリティポリシー、鍵管理メカニズム、および暗号化アルゴリズムの選択をサポートしています。S-HTTPは、非対称性と対称暗号化の両方の動作モードをサポートしています。S-HTTPは特定の信頼モデルの推定を避けようとしていますが、乗算の階層的な信頼を容易にし、プリンシパルに多くの公開鍵証明書がある可能性があると予測しています。
$ Secure/MIME (S/MIME) (I) Secure/Multipurpose Internet Mail Extensions, an Internet protocol [R3851] to provide encryption and digital signatures for Internet mail messages.
$ Secure / MIME（S / MIME）（i）インターネットメールメッセージの暗号化とデジタル署名を提供するためのインターネットプロトコル[R3851]。
$ secure multicast (I) Refers generally to providing security services for multicast groups of various types (e.g., 1-to-N and M-to-N) and to classes of protocols used to protect multicast packets.
$ セキュアマルチキャスト（i）は、一般に、さまざまなタイプのマルチキャストグループ（例えば、1からN、M-To-N）およびマルチキャストパケットを保護するために使用されるプロトコルのクラスのセキュリティサービスを提供することを指す。
Tutorial: Multicast applications include video broadcast and multicast file transfer, and many of these applications require network security services. The Multicast Security Reference Framework [R3740] covers three functional areas: - Multicast data handling: Security-related treatment of multicast data by the sender and the receiver. - Group key management: Secure distribution and refreshment of keying material. (See: Group Domain of Interpretation.) - Multicast security policy: Policy translation and interpretation across the multiple administrative domains that typically are spanned by a multicast application.
チュートリアル：マルチキャストアプリケーションには、ビデオブロードキャストとマルチキャストファイル転送があり、これらのアプリケーションの多くはネットワークセキュリティサービスを必要とします。マルチキャストセキュリティリファレンスフレームワーク[R3740]は、3つの機能領域をカバーします。 - マルチキャストデータ処理：送信者と受信者によるマルチキャストデータのセキュリティ関連の扱い。 - グループ鍵管理：キーイング材料の安全な配布とリフレッシュ。 - マルチキャストセキュリティポリシー：通常、マルチキャストアプリケーションによってスパンされている複数の管理ドメイン全体でのポリシー変換と解釈。
$ Secure Shell(trademark) (SSH(trademark)) (N) Refers to a protocol for secure remote login and other secure network services.
$ Secure Shell（TradeMark）（SSH（登録商標））（N）は、安全なリモートログインおよびその他の安全なネットワークサービスのためのプロトコルを指します。
Usage: On the Web site of SSH Communication Security Corporation, at http://www.ssh.com/legal_notice.html, it says, "SSH [and] the SSH logo ... are either trademarks or registered trademarks of SSH." This Glossary seeks to make readers aware of this trademark claim but takes no position on its validity.
使用法：SSH Communication Security CorporationのWebサイトで、http：//www.ssh.com/legal_notice.htmlによると、「SSH [と] SSHロゴ...はSSHの商標または登録商標です。""この用語集は、この商標の主張を読者に知らせることを目指していますが、その妥当性に位置していません。
Tutorial: SSH has three main parts: - Transport layer protocol: Provides server authentication, confidentiality, and integrity; and can optionally provide compression. This layer typically runs over a TCP connection, but might also run on top of any other reliable data stream. - User authentication protocol: Authenticates the client-side user to the server. It runs over the transport layer protocol. - Connection protocol: Multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol.
チュートリアル：SSHには3つの主要部分があります。 - トランスポート層プロトコル：サーバ認証、機密性、および整合性を提供します。そしてオプションで圧縮を提供することができます。このレイヤーは通常TCP接続を介して実行されますが、他の信頼できるデータストリームの上にも実行される可能性があります。 - ユーザー認証プロトコル：クライアントサイドユーザーをサーバーに認証します。トランスポート層プロトコルを介して実行されます。 - 接続プロトコル：暗号化されたトンネルをいくつかの論理チャネルに多重化します。ユーザー認証プロトコルを介して実行されます。
$ Secure Sockets Layer (SSL) (N) An Internet protocol (originally developed by Netscape Communications, Inc.) that uses connection-oriented end-to-end encryption to provide data confidentiality service and data integrity service for traffic between a client (often a web browser) and a server, and that can optionally provide peer entity authentication between the client and the server. (See: Transport Layer Security.) Tutorial: SSL has two layers; SSL's lower layer, the SSL Record Protocol, is layered on top of an IPS Transport-Layer protocol and encapsulates protocols that run in the upper layer. The upper-layer protocols are the three SSL management protocols -- SSL Handshake Protocol, SSL Change Cipher Spec Protocol, or SSL Alert Protocol -- and some Application-Layer protocol (e.g., HTTP).
$ Secure Sockets Layer（SSL）（N）コネクション指向のエンドツーエンド暗号化を使用して、クライアント間のトラフィックのためのデータの機密保持サービスとデータ整合性サービスを提供するインターネットプロトコル（Netscape Communications、Inc。によって開発されました）。Webブラウザとサーバー、およびサーバー、およびクライアントとサーバー間のピアエンティティ認証をオプションで提供できます。（検索：トランスポートレイヤセキュリティ）チュートリアル：SSLには2つのレイヤがあります。SSLの下位レイヤー、SSLレコードプロトコルは、IPSトランスポート層プロトコルの上に階層化され、上位層で実行されるプロトコルをカプセル化します。上位層のプロトコルは、SSLハンドシェイクプロトコル、SSL変更Cipher Spec Protocol、またはSSL Alert Protocol - および一部のアプリケーション層プロトコル（例えば、HTTP）です。
The SSL management protocols provide asymmetric cryptography for server authentication (verifying the server's identity to the client) and optional client authentication (verifying the client's identity to the server), and also enable them, before the application protocol transmits or receives data, to negotiate a symmetric encryption algorithm and secret session key (to use for data confidentiality service) and a keyed hash (to use for data integrity service).
SSL管理プロトコルは、サーバ認証のための非対称暗号化（クライアントへのサーバの識別情報の検証）およびオプションのクライアント認証（サーバへのクライアントの識別の検証）およびそれらを有効にする（Application Protocolが送信または受信する前に、対称暗号化アルゴリズムとシークレットセッションキー（データ機密保持サービスに使用する）およびキー付きハッシュ（Data Integrityサービスに使用する）。
SSL is independent of the application it encapsulates, and any application can layer on top of SSL transparently. However, many Internet applications might be better served by IPsec.
SSLはそれがカプセル化したアプリケーションとは無関係であり、任意のアプリケーションはSSLの上に透過的にレイヤーすることができます。ただし、多くのインターネットアプリケーションはIPsecによって提供される可能性があります。
$ secure state 1a. (I) A system condition in which the system is in conformance with the applicable security policy. (Compare: clean system, transaction.)
$ 安全な状態1a。（i）適用可能なセキュリティポリシーに適合しているシステム状態。（比較：クリーンシステム、トランザクション。）
1b. (I) /formal model/ A system condition in which no subject can access any object in an unauthorized manner. (See: secondary definition under "Bell-LaPadula model".)
1b。（i）/正式モデル/被験者が不正な方法で任意のオブジェクトにアクセスできないシステム状態。（「ベルララドゥラモデル」の「二次定義」。）
$ security 1a. (I) A system condition that results from the establishment and maintenance of measures to protect the system.
$ セキュリティ1A。（i）システムを保護するための対策の確立と維持から生じるシステム状態。
1b. (I) A system condition in which system resources are free from unauthorized access and from unauthorized or accidental change, destruction, or loss. (Compare: safety.)
1b。（i）システムリソースが不正アクセスから解放され、不正または偶発的な変化、破壊、または損失から解放されるシステム状態。（比較：安全。）
2. (I) Measures taken to protect a system.
2. （i）システムを保護するための対策。
Tutorial: Parker [Park] suggests that providing a condition of system security may involve the following six basic functions, which overlap to some extent: - "Deterrence": Reducing an intelligent threat by discouraging action, such as by fear or doubt. (See: attack, threat action.) - "Avoidance": Reducing a risk by either reducing the value of the potential loss or reducing the probability that the loss will occur. (See: risk analysis. Compare: "risk avoidance" under "risk".)
チュートリアル：Parker [Park]は、システムセキュリティの条件を提供することが、ある程度重複する次の6つの基本機能を提供することができると提案しています。（攻撃、脅威の対応。） - 「回避」：潜在的な損失の価値を減らすか、損失が発生する可能性を減らすことによってリスクを減らす。（リスク分析を参照してください。比較：「リスク」の「リスク回避」）
- "Prevention": Impeding or thwarting a potential security violation by deploying a countermeasure. - "Detection": Determining that a security violation is impending, is in progress, or has recently occurred, and thus make it possible to reduce the potential loss. (See: intrusion detection.) - "Recovery": Restoring a normal state of system operation by compensating for a security violation, possibly by eliminating or repairing its effects. (See: contingency plan, main entry for "recovery".) - "Correction": Changing a security architecture to eliminate or reduce the risk of reoccurrence of a security violation or threat consequence, such as by eliminating a vulnerability.
- 「防止」：対策を展開することによって潜在的なセキュリティ違反を妨げるか阻止する。 - 「検出」：セキュリティ違反が差し迫っていると判断しているか、最近発生しているため、潜在的な損失を減らすことができます。（侵入検知を参照してください。） - 「回復」：セキュリティ違反を補正することで、おそらく効果を排除または修復することで、通常のシステム操作の状態を復元します。（緊急時刻、「回復」のメインエントリ。） - 「修正」：セキュリティアーキテクチャの変更：脆弱性を排除するなど、セキュリティ違反または脅威の影響のリスクを排除または軽減します。
$ security architecture (I) A plan and set of principles that describe (a) the security services that a system is required to provide to meet the needs of its users, (b) the system components required to implement the services, and (c) the performance levels required in the components to deal with the threat environment (e.g., [R2179]). (See: defense in depth, IATF, OSIRM Security Architecture, security controls, Tutorial under "security policy".)
$ セキュリティアーキテクチャ（i）システムがそのユーザのニーズを満たすために必要なセキュリティサービス、（b）サービスを実装するために必要なシステムコンポーネント、および（c）のシステムコンポーネントを記述するプランおよびセットコンポーネントに脅威環境に対処するために必要なパフォーマンスレベル（例：[R2179]）。（詳細：詳細、IATF、OSIRDセキュリティアーキテクチャ、セキュリティ管理、セキュリティ管理、セキュリティポリシーの下にあるチュートリアル）。
Tutorial: A security architecture is the result of applying the system engineering process. A complete system security architecture includes administrative security, communication security, computer security, emanations security, personnel security, and physical security. A complete security architecture needs to deal with both intentional, intelligent threats and accidental threats.
チュートリアル：セキュリティアーキテクチャはシステムエンジニアリングプロセスを適用した結果です。完全なシステムセキュリティアーキテクチャには、管理者セキュリティ、通信セキュリティ、コンピュータセキュリティ、発行セキュリティ、人員セキュリティ、および物理的セキュリティが含まれます。完全なセキュリティアーキテクチャは、意図的で知的な脅威と偶発的な脅威の両方に対処する必要があります。
$ Security Assertion Markup Language (SAML) (N) A protocol consisting of XML-based request and response message formats for exchanging security information, expressed in the form of assertions about subjects, between on-line business partners. [SAML]
$ セキュリティアサーションマークアップ言語（SAML）（n）オンラインビジネスパートナの間で、被験者に関するアサーションの形で表されるセキュリティ情報を交換するためのXMLベースの要求および応答メッセージフォーマットで構成されるプロトコル。[SAML]
$ security association 1. (I) A relationship established between two or more entities to enable them to protect data they exchange. (See: association, ISAKMP, SAD. Compare: session.)
$ セキュリティアソシエーション1.（i）自分が交換するデータを保護できるようにするために、2つ以上のエンティティの間で確立された関係を示します。（協会、ISAKMP、悲しい。比較：セッション。）
Tutorial: The relationship is represented by a set of data that is shared between the entities and is agreed upon and considered a contract between them. The data describes how the associated entities jointly use security services. The relationship is used to negotiate characteristics of security mechanisms, but the relationship is usually understood to exclude the mechanisms themselves.
チュートリアル：この関係は、エンティティ間で共有されている一連のデータによって表され、それらの間の契約が合意されています。データは、関連エンティティが共同セキュリティサービスを使用する方法を説明します。この関係は、セキュリティメカニズムの特性をネゴシエートするために使用されますが、関係は通常メカニズム自体を除外すると理解されています。
2. (I) /IPsec/ A simplex (uni-directional) logical connection created for security purposes and implemented with either AH or ESP (but not both). The security services offered by a security association depend on the protocol (AH or ESP), the IPsec mode (transport or tunnel), the endpoints, and the election of optional services within the protocol. A security association is identified by a triple consisting of (a) a destination IP address, (b) a protocol (AH or ESP) identifier, and (c) a Security Parameter Index.
2. （i）/ IPSec / Aシンプレックス（UNI方向）セキュリティ目的で作成され、AHまたはESP（両方ではない）で実装された論理接続。セキュリティアソシエーションによって提供されるセキュリティサービスは、プロトコル（AHまたはESP）、IPsecモード（トランスポートまたはトンネル）、エンドポイント、およびプロトコル内のオプションサービスの選択によって異なります。セキュリティアソシエーションは、（a）宛先IPアドレス、（b）プロトコル（AHまたはESP）識別子、および（c）セキュリティパラメータインデックスからなるトリプルによって識別される。
3. (O) "A set of policy and cryptographic keys that provide security services to network traffic that matches that policy". [R3740] (See: cryptographic association, group security association.)
3. （O） "そのポリシーに一致するネットワークトラフィックにセキュリティサービスを提供するポリシーと暗号化キーのセット。[R3740]（参照：暗号化協会、グループセキュリティ協会）
4. (O) "The totality of communications and security mechanisms and functions (e.g., communications protocols, security protocols, security mechanisms and functions) that securely binds together two security contexts in different end systems or relay systems supporting the same information domain." [DoD6]
4. （O） "通信とセキュリティメカニズムと機能（例えば、通信プロトコル、セキュリティプロトコル、セキュリティメカニズム、および機能）は、異なるエンドシステムまたは同じ情報ドメインをサポートする中継システムで2つのセキュリティコンテキストをまとめてバインドします。[DOD6]
$ Security Association Database (SAD) (I) /IPsec/ In an IPsec implementation that operates in a network node, a database that contains parameters to describe the status and operation of each of the active security associations that the node has established with other nodes. Separate inbound and outbound SADs are needed because of the directionality of IPsec security associations. [R4301] (Compare: SPD.)
$ セキュリティアソシエーションデータベース（SAD）/ IPSec /ネットワークノードで動作するIPsec実装では、ノードが他のノードと確立された各アクティブなセキュリティアソシエーションのステータスと動作を記述するためのパラメータを含むデータベース。IPSecセキュリティアソシエーションの方向性のために、別のインバウンドおよびアウトバウンドの悲しいとは別のインバウンドの悲しみが必要です。[R4301]（比較：SPD）
$ security association identifier (SAID) (I) A data field in a security protocol (such as NLSP or SDE), used to identify the security association to which a PDU is bound. The SAID value is usually used to select a key for decryption or authentication at the destination. (See: Security Parameter Index.)
$ セキュリティアソシエーション識別子（i）PDUがバインドされているセキュリティアソシエーションを識別するために使用されるセキュリティプロトコル（NLSPまたはSDEなど）のデータフィールド。前記値は通常、宛先での復号化または認証のためのキーを選択するために使用される。（：セキュリティパラメータインデックスを参照してください。）
$ security assurance 1. (I) An attribute of an information system that provides grounds for having confidence that the system operates such that the system's security policy is enforced. (Compare: trust.)
$ セキュリティ保証1.（i）システムのセキュリティポリシーが強制されるようにシステムが操作する自信を持つための根拠を提供する情報システムの属性。（比較：信頼してください。）
2. (I) A procedure that ensures a system is developed and operated as intended by the system's security policy.
2. （i）システムのセキュリティポリシーの意図としてシステムを確実に開発および運用する手順。
3. (D) "The degree of confidence one has that the security controls operate correctly and protect the system as intended." [SP12]
3. （d） "信頼度の程度は、セキュリティコントロールが正しく動作し、意図したようにシステムを保護することを持っています。」[SP12]
Deprecated Definition: IDOCs SHOULD NOT use definition 3; it is a definition for "assurance level" rather than for "assurance".
非推奨の定義：IDocsは定義3を使用しないでください。「保証」ではなく「保証レベル」の定義です。
4. (D) /U.S. Government, identity authentication/ The (a) "degree of confidence in the vetting process used to establish the identity of the individual to whom the [identity] credential was issued" and the (b) "degree of confidence that the individual who uses the credential is the individual to whom the credential was issued". [M0404]
4. （d）/u.S。政府、アイデンティティ認証/（A） "IDENTITY]信任状が発行された個人の身元を確立するために使用された獣医プロセスへの信頼度「（B）」の信頼度信任状は、信任状が発行された個人です。[M0404]
Deprecated Definition: IDOCs SHOULD NOT use definition 4; it mixes concepts in a potentially misleading way. Part "a" is a definition for "assurance level" (rather than "security assurance") of an identity registration process; and part "b" is a definition for "assurance level" (rather than "security assurance") of an identity authentication process. Also, the processes of registration and authentication should be defined and designed separately to ensure clarity in certification.
廃止予定の定義：IDocは定義4を使用しないでください。潜在的に誤解を招くような方法で概念を混ぜる。部分「A」は、（保証レベル "（「セキュリティ保証」ではなく）識別登録プロセスの定義です。また、ID認証プロセスの「保証レベル」（「保証保証」ではなく）の定義です。また、認証を明確にするために、登録および認証のプロセスを別々に定義および設計する必要があります。
$ security audit (I) An independent review and examination of a system's records and activities to determine the adequacy of system controls, ensure compliance with established security policy and procedures, detect breaches in security services, and recommend any changes that are indicated for countermeasures. [I7498-2, NCS01] (Compare: accounting, intrusion detection.)
$ Security Audit（i）システムの記録と活動の独立したレビューと検討システムコントロールの妥当性を判断し、確立されたセキュリティポリシーと手順に準拠し、セキュリティサービスの違反を検出し、対策に示されている変更を推奨します。[I7498-2、NCS01]（比較：会計、侵入検知）
Tutorial: The basic audit objective is to establish accountability for system entities that initiate or participate in security-relevant events and actions. Thus, means are needed to generate and record a security audit trail and to review and analyze the audit trail to discover and investigate security violations.
チュートリアル：基本監査目的は、セキュリティ関連のイベントやアクションに参加または参加するシステムエンティティの説明責任を確立することです。したがって、セキュリティ監査証跡を生成し記録し、監査証跡を検討して分析してセキュリティ違反を発見し調査するための手段が必要です。
$ security audit trail (I) A chronological record of system activities that is sufficient to enable the reconstruction and examination of the sequence of environments and activities surrounding or leading to an operation, procedure, or event in a security-relevant transaction from inception to final results. [NCS04] (See: security audit.)
$ セキュリティ監査証跡（i）セキュリティ関連トランザクションでの環境のシーケンスや活動の復元と検討を可能にするのに十分であるシステム活動の年間記録 - 開始から最終的な結果へのセキュリティ関連トランザクション。[NCS04]（セキュリティ監査を参照）
$ security by obscurity (O) Attempting to maintain or increase security of a system by keeping secret the design or construction of a security mechanism.
$ セキュリティメカニズムの設計または構築を秘密にすることによってシステムのセキュリティを維持または増加させることを試みることを試みる。
Tutorial: This approach has long been discredited in cryptography, where the phrase refers to trying to keep an algorithm secret, rather than just concealing the keys [Schn]. One must assume that mass-produced or widely fielded cryptographic devices eventually will be lost or stolen and, therefore, that the algorithms will be reverse engineered and become known to the adversary. Thus, one should rely on only those algorithms and protocols that are strong enough to have been published widely, and have been peer reviewed for long enough that their flaws have been found and removed. For example, NIST used a long, public process to select AES to replace DES.
チュートリアル：このアプローチは、句が鍵を隠すのではなく、アルゴリズムの秘密を維持しようとしていることを指す暗号化では長い間信用されています。大量生産または広く分類された暗号装置が最終的に紛失または盗まれ、したがって、そのアルゴリズムがリバース操作され、敵対者に知られるようになると仮定しなければならない。したがって、広く公開されているのに十分なほど強いアルゴリズムとプロトコルのみに頼るべきであり、それらの欠陥が見つけられ除去されたことが十分な長さで査読されています。たとえば、NISTはDESを置き換えるためにAESを選択するために長いパブリックプロセスを使用しました。
In computer and network security, the principle of "no security by obscurity" also applies to security mechanisms other than cryptography. For example, if the design and implementation of a protocol for access control are strong, then reading the protocol's source code should not enable you to find a way to evade the protection and penetrate the system.
コンピュータおよびネットワークのセキュリティでは、「不明瞭さによるセキュリティなし」の原則は、暗号化以外のセキュリティメカニズムにも当てはまります。たとえば、アクセス制御のためのプロトコルの設計と実装が強い場合、プロトコルのソースコードを読み取ることで、保護を回避してシステムを貫通させる方法を見つけることができません。
$ security class (D) Synonym for "security level".
$ セキュリティクラス（D）「セキュリティレベル」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term. Instead, use "security level", which is more widely established and understood.
廃止予定語：IDocsはこの用語を使用しないでください。代わりに、「セキュリティレベル」を使用します。これは、より広く確立され理解されています。
$ security clearance (I) A determination that a person is eligible, under the standards of a specific security policy, for authorization to access sensitive information or other system resources. (See: clearance level.)
$ セキュリティクリアランス（i）機密情報または他のシステムリソースにアクセスするための承認のために、特定のセキュリティポリシーの標準の下で、人が適格であると判断した。（参照：クリアランスレベル）
$ security compromise (I) A security violation in which a system resource is exposed, or is potentially exposed, to unauthorized access. (Compare: data compromise, exposure, violation.)
$ セキュリティ妥協点（i）システムリソースが露出されている、または潜在的に露出しているセキュリティ違反、許可されていないアクセスに。（比較：データの妥協、露出、違反）
$ security controls (N) The management, operational, and technical controls (safeguards or countermeasures) prescribed for an information system which, taken together, satisfy the specified security requirements and adequately protect the confidentiality, integrity, and availability of the system and its information. [FP199] (See: security architecture.)
$ セキュリティコントロール（N）管理、運用上、および技術的管理（保障措置または対策）は、協力して、指定されたセキュリティ要件を満たし、システムの機密性、整合性、およびその情報を適切に保護する、およびその情報とその情報を適切に保護します。[FP199]（セキュリティアーキテクチャを参照）
$ security doctrine (I) A specified set of procedures or practices that direct or provide guidance for how to comply with security policy. (Compare: security mechanism, security policy.) Tutorial: Security policy and security doctrine are closely related. However, policy deals mainly with strategy, and doctrine deals with tactics.
$ Security Doctrine（i）セキュリティポリシーに準拠する方法について指導またはガイダンスを指示または提供する、指定された手順または慣行のセット。（比較：セキュリティメカニズム、セキュリティポリシー。）チュートリアル：セキュリティポリシーとセキュリティの教義は密接に関連しています。しかし、政策は主に戦略を備えており、戦術を教えています。
Security doctrine is often understood to refer mainly to administrative security, personnel security, and physical security. For example, security mechanisms and devices that implement them are normally designed to operate in a limited range of environmental and administrative conditions, and these conditions must be met to complement and ensure the technical protection afforded by the hardware, firmware, and software in the devices. Security doctrine specifies how to achieve those conditions. (See: "first law" under "Courtney's laws".)
セキュリティの教義は、主に行政セキュリティ、人事セキュリティ、および物理的なセキュリティを主に参照することがよくあります。たとえば、それらを実装するセキュリティメカニズムやデバイスは通常、限られた環境および管理条件で動作するように設計されており、これらの条件は、デバイス内のハードウェア、ファームウェア、およびソフトウェアが提供する技術的保護を補完し、確実にする必要があります。。セキュリティDoctrineこれらの条件を達成する方法を指定します。（「Courtney's Laws」の下にある「最初の法律」。）
$ security domain (I) See: domain.
$ セキュリティドメイン（i）ドメインを参照してください。
$ security environment (I) The set of external entities, procedures, and conditions that affect secure development, operation, and maintenance of a system. (See: "first law" under "Courtney's laws".)
$ セキュリティ環境（i）システムの安全な開発、操作、および保守に影響を与える外部エンティティ、手順、および条件のセット。（「Courtney's Laws」の下にある「最初の法律」。）
$ security event (I) An occurrence in a system that is relevant to the security of the system. (See: security incident.)
$ セキュリティイベント（i）システムのセキュリティに関連するシステムでの発生。（セキュリティインシデントを参照してください。）
Tutorial: The term covers both events that are security incidents and those that are not. In a CA workstation, for example, a list of security events might include the following: - Logging an operator into or out of the system. - Performing a cryptographic operation, e.g., signing a digital certificate or CRL. - Performing a cryptographic card operation: creation, insertion, removal, or backup. - Performing a digital certificate lifecycle operation: rekey, renewal, revocation, or update. - Posting a digital certificate to an X.500 Directory. - Receiving a key compromise notification. - Receiving an improper certification request. - Detecting an alarm condition reported by a cryptographic module. - Failing a built-in hardware self-test or a software system integrity check.
チュートリアル：この用語は、セキュリティ事件であるイベントとそうでないイベントをカバーします。たとえば、CAワークステーションでは、セキュリティイベントのリストには次のものが含まれます。 - オペレータをシステムにログオウすることがあります。 - 暗号操作を実行する、例えばデジタル証明書またはCRLに署名する。 - 暗号化カード操作の実行：作成、挿入、削除、またはバックアップ。 - デジタル証明書ライフサイクル操作を実行する：リリーキー、更新、失効、または更新。 - デジタル証明書をX.500ディレクトリに投稿します。 - 妥協の通知を受信します。 - 不適切な認証要求を受信します。 - 暗号化モジュールによって報告されたアラーム状態を検出します。 - 内蔵のハードウェアセルフテストまたはソフトウェアシステムの整合性チェックに失敗する。
$ security fault analysis (I) A security analysis, usually performed on hardware at the level of gate logic, gate-by-gate, to determine the security properties of a device when a hardware fault is encountered.
$ セキュリティ障害解析（i）通常、ゲートロジックのレベルでハードウェアで実行されたセキュリティ分析は、ハードウェア障害が発生したときにデバイスのセキュリティプロパティを決定します。
$ security function (I) A function in a system that is relevant to the security of the system; i.e., a system function that must operate correctly to ensure adherence to the system's security policy.
$ セキュリティ機能（i）システムのセキュリティに関連するシステム内の関数。すなわち、システムのセキュリティポリシーを順守するために正しく動作しなければならないシステム機能。
$ security gateway 1. (I) An internetwork gateway that separates trusted (or relatively more trusted) hosts on one side from untrusted (or less trusted) hosts on the other side. (See: firewall and guard.)
$ セキュリティゲートウェイ1.（i）信頼された（または比較的信頼できる）ホストを片側に片側に区切るインターネットワークゲートウェイ。（：ファイアウォールとガードを参照してください。）
2. (O) /IPsec/ "An intermediate system that implements IPsec protocols." [R4301]
2. （O）/ IPSec /「IPSecプロトコルを実装する中間システム」[R4301]
Tutorial: IPsec's AH or ESP can be implemented on a gateway between a protected network and an unprotected network, to provide security services to the protected network's hosts when they communicate across the unprotected network to other hosts and gateways.
チュートリアル：IPsecのAHまたはESPは、保護されていないネットワークと保護されていないネットワークの間のゲートウェイに実装され、保護されていないネットワークを他のホストやゲートウェイに通信するときに保護されていないネットワークのホストにセキュリティサービスを提供できます。
$ security incident 1. (I) A security event that involves a security violation. (See: CERT, security event, security intrusion, security violation.)
$ セキュリティインシデント1.（i）セキュリティ違反を含むセキュリティイベント。（「証明書、セキュリティイベント、セキュリティ侵入、セキュリティ違反」を参照してください。
Tutorial: In other words, a security event in which the system's security policy is disobeyed or otherwise breached.
チュートリアル：言い換えれば、システムのセキュリティポリシーが解決されているか、そうでなければ侵害されているセキュリティイベント。
2. (D) "Any adverse event [that] compromises some aspect of computer or network security." [R2350]
2. （d）「任意の有害事象」コンピュータまたはネットワークセキュリティのいくつかの側面を損なう。」[R2350]
Deprecated Definition: IDOCs SHOULD NOT use definition 2 because (a) a security incident may occur without actually being harmful (i.e., adverse) and because (b) this Glossary defines "compromise" more narrowly in relation to unauthorized access.
廃止予定の定義：IDocは定義2を使用しないでください（a）実際に有害であること（すなわち、有害）で発生し、（b）この用語集は、不正アクセスに関して「妥協」をより狭く定義しているからです。
3. (D) "A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard computer security practices." [SP61]
3. （D）「コンピュータセキュリティポリシー、許容される使用ポリシー、または標準のコンピュータセキュリティ慣行の違反または差し迫った脅威。」[SP61]
Deprecated Definition: IDOCs SHOULD NOT use definition 3 because it mixes concepts in way that does not agree with common usage; a security incident is commonly thought of as involving a realization of a threat (see: threat action), not just a threat.
廃止予定の定義：IDocは、一般的な使用法に同意しない方法で概念を混在させるため、定義3を使用しないでください。セキュリティ事件は一般的に脅威の実現を伴うものと考えられています（脅威の処置を参照）、ただの脅威ではなく、
$ security intrusion (I) A security event, or a combination of multiple security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system or system resource without having authorization to do so.
$ セキュリティ侵入（i）侵入者が獲得したセキュリティインシデントを構成するセキュリティイベント、または複数のセキュリティイベントの組み合わせは、許可を実行することなくシステムまたはシステムリソースにアクセスしようとします。
$ security kernel (I) "The hardware, firmware, and software elements of a trusted computing base that implement the reference monitor concept. It must mediate all accesses, be protected from modification, and be verifiable as correct." [NCS04] (See: kernel, TCB.)
$ セキュリティカーネル（i） "参照モニタの概念を実装する信頼できるコンピューティングベースのハードウェア、ファームウェア、およびソフトウェア要素。それはすべてのアクセスを仲介しなければなりません、修正から保護され、正しいものとして検証可能です。」[NCS04]（カーネル、TCBを参照）
Tutorial: A security kernel is an implementation of a reference monitor for a given hardware base. [Huff]
チュートリアル：セキュリティカーネルは、特定のハードウェアベースの参照モニタの実装です。[ハフ]
$ security label (I) An item of meta-data that designates the value of one or more security-relevant attributes (e.g., security level) of a system resource. (See: [R1457]. Compare: security marking.)
$ セキュリティラベル（i）システムリソースの1つ以上のセキュリティ関連属性（例えばセキュリティレベル）の値を指定するメタデータの項目。（参照：[R1457]。比較：セキュリティマーキング。）
Deprecated usage: To avoid confusion, IDOCs SHOULD NOT use "security label" for "security marking", or vice versa, even though that is commonly done (including in some national and international standards that should know better).
廃止予定の使用法：混乱を避けるために、IDocは「セキュリティマーキング」の場合は「セキュリティラベル」を使用しないでください。
Tutorial: Humans and automated security mechanisms use a security label of a system resource to determine, according to applicable security policy, how to control access to the resource (and they affix appropriate, matching security markings to physical instances of the resource). Security labels are most often used to support data confidentiality policy, and sometimes used to support data integrity policy.
チュートリアル：人間と自動セキュリティメカニズムシステムリソースのセキュリティラベルを使用して、適用可能なセキュリティポリシーに従って、リソースへのアクセスを制御する方法（およびそれらは適切なセキュリティマーキングとリソースの物理インスタンスにマッチングする方法）を決定します。セキュリティラベルは、データの機密性ポリシーをサポートするために最もよく使用され、データの整合性ポリシーをサポートするために使用されることがあります。
As explained in [R1457], the form that is taken by security labels of a protocol's packets varies depending on the OSIRM layer in which the protocol operates. Like meta-data generally, a security label of a data packet may be either explicit (e.g., IPSO) or implicit (e.g., Alice treats all messages received from Bob as being labeled "Not For Public Release"). In a connectionless protocol, every packet might have an explicit label; but in a connection-oriented protocol, all packets might have the same implicit label that is determined at the time the connection is established.
[R1457]で説明されているように、プロトコルのパケットのセキュリティラベルによって取られる形式は、プロトコルが動作するOSIRM層によって異なります。一般的に、データパケットのセキュリティラベルのように、データパケットのセキュリティラベルは、明示的（例えば、IPSO）または暗黙のいずれかであり得る（例えば、Aliceは、Bobから受信したすべてのメッセージを「公開リリースではないとして）。コネクションレスプロトコルでは、すべてのパケットに明示的なラベルが付いている可能性があります。しかし、接続指向プロトコルでは、すべてのパケットに接続が確立された時点で決定されるのと同じ暗黙のラベルがある可能性があります。
Both classified and unclassified system resources may require a security label. (See: FOUO.)
分類されていないシステムリソースの両方がセキュリティラベルを必要とする可能性があります。（参照：fouo。）
$ security level (I) The combination of a hierarchical classification level and a set of non-hierarchical category designations that represents how sensitive a specified type or item of information is. (See: dominate, lattice model. Compare: classification level.) Usage: IDOCs that use this term SHOULD state a definition for it. The term is usually understood to involve sensitivity to disclosure, but it also is used in many other ways and could easily be misunderstood.
$ Security Level（i）特定の種類または情報項目の機密性があるかを表す階層分類レベルと一連の非階層カテゴリ指定の組み合わせ。（比較して格子モデルを比較します。比較：分類レベル。）使用法この項を使用するIDocは、定義を定義します。この用語は、通常、開示に対する感度を含むと理解されていますが、それはまた他の多くの方法で使用されており、容易に誤解される可能性があります。
$ Security Level field (I) A 16-bit field that specifies a security level value in the security option (option type 130) of version 4 IP's datagram header format.
$ セキュリティレベルフィールド（i）バージョン4 IPのデータグラムヘッダー形式のセキュリティオプション（オプションタイプ130）にセキュリティレベルの値を指定する16ビットフィールド。
Deprecated Abbreviation: IDOCs SHOULD NOT use the abbreviation "S field", which is potentially ambiguous.
廃止予定の省略形：IDOCは省略形の「Sフィールド」を使用しないでください。これは潜在的にあいまいです。
$ security management infrastructure (SMI) (I) System components and activities that support security policy by monitoring and controlling security services and mechanisms, distributing security information, and reporting security events.
$ セキュリティ管理インフラストラクチャ（SMI）（I）セキュリティサービスとメカニズムを監視および管理し、セキュリティ情報の配布、およびセキュリティイベントの報告をサポートするシステムコンポーネントとアクティビティ。
Tutorial: The associated functions are as follows [I7498-4]: - Controlling (granting or restricting) access to system resources: This includes verifying authorizations and identities, controlling access to sensitive security data, and modifying access priorities and procedures in the event of attacks. - Retrieving (gathering) and archiving (storing) security information: This includes logging security events and analyzing the log, monitoring and profiling usage, and reporting security violations. - Managing and controlling the encryption process: This includes performing the functions of key management and reporting on key management problems. (See: PKI.)
チュートリアル：関連する関数は次のとおりです[I7498-4]： - システムリソースへのアクセス（許可または制限）にアクセスしてください。攻撃 - セキュリティ情報を取得する（収集）およびアーカイブ（保存）セキュリティ情報：セキュリティイベントのロギングおよびログ、監視、およびプロファイリングの使用、およびセキュリティ違反の報告を含む。 - 暗号化プロセスの管理と制御：これには、鍵管理の機能と鍵管理の問題に関する報告の機能を実行します。（PKIを参照してください。
$ security marking (I) A physical marking that is bound to an instance of a system resource and that represents a security label of the resource, i.e., that names or designates the value of one or more security-relevant attributes of the resource. (Compare: security label.)
$ セキュリティマーキング（i）システムリソースのインスタンスにバインドされ、リソースのセキュリティラベルを表す、すなわち、リソースの1つまたは複数のセキュリティ関連属性の値を表す、または指定する物理的なマーキング。（比較：セキュリティラベル。）
Tutorial: A security label may be represented by various equivalent markings depending on the physical form taken by the labeled resource. For example, a document could have a marking composed of a bit pattern [FP188] when the document is stored electronically as a file in a computer, and also a marking of printed alphabetic characters when the document is in paper form.
チュートリアル：セキュリティラベルは、ラベル付きリソースによって撮影された物理的な形に応じてさまざまな同等のマーキングによって表されることがあります。例えば、文書がコンピュータ内のファイルとして電子的に記憶されているとき、そして文書が紙の形式のときに印刷されたアルファベットのマーキングをマーキングすることができる。
$ security mechanism (I) A method or process (or a device incorporating it) that can be used in a system to implement a security service that is provided by or within the system. (See: Tutorial under "security policy". Compare: security doctrine.)
$ セキュリティメカニズム（i）システム内またはシステム内に提供されるセキュリティサービスを実装するためにシステム内で使用することができる方法またはプロセス（またはそれを組み込んだデバイス）。（「セキュリティポリシー」の下のチュートリアル。比較：セキュリティDoctrine。）
Usage: Usually understood to refer primarily to components of communication security, computer security, and emanation security.
使用法：通常、通信セキュリティ、コンピュータのセキュリティ、およびエメンテーションセキュリティのコンポーネントに主に理解されていました。
Examples: Authentication exchange, checksum, digital signature, encryption, and traffic padding.
例：認証交換、チェックサム、デジタル署名、暗号化、およびトラフィックパディング。
$ security model (I) A schematic description of a set of entities and relationships by which a specified set of security services are provided by or within a system. Example: Bell-LaPadula model, OSIRM. (See: Tutorial under "security policy".)
$ セキュリティモデル（i）指定されたセキュリティサービスのセットがシステム内で提供されている一連のエンティティと関係の概略説明。例：ベルラップラドゥラモデル、オスミー。（「セキュリティポリシー」の「チュートリアル」を参照してください。）
$ security parameters index (SPI) 1. (I) /IPsec/ A 32-bit identifier used to distinguish among security associations that terminate at the same destination (IP address) and use the same security protocol (AH or ESP). Carried in AH and ESP to enable the receiving system to determine under which security association to process a received packet.
$ セキュリティパラメータインデックス（SPI）1。（i）/ IPSec /同じ宛先（IPアドレス）で終了し、同じセキュリティプロトコル（AHまたはESP）を使用するセキュリティアソシエーションを区別するために使用される32ビット識別子。AHとESPで運ばれて、受信システムが受信したパケットを処理するためのセキュリティアソシエーションの下にあることを判断できるようにします。
2. (I) /mobile IP/ A 32-bit index identifying a security association from among the collection of associations that are available between a pair of nodes, for application to mobile IP protocol messages that the nodes exchange.
2. （i）/モバイルIP / A 32ビットインデックスは、ノードが交換するモバイルIPプロトコルメッセージへのアプリケーションのために、一対のノード間で利用可能な関連付けの集まりの中からセキュリティアソシエーションを識別する。
$ security perimeter (I) A physical or logical boundary that is defined for a domain or enclave and within which a particular security policy or security architecture applies. (See: insider, outsider.)
$ セキュリティ境界（i）ドメインまたはエンクレーブに対して定義され、特定のセキュリティポリシーまたはセキュリティアーキテクチャが適用される物理的または論理的な境界。（参照：インサイダー、部外者。）
$ security policy 1. (I) A definite goal, course, or method of action to guide and determine present and future decisions concerning security in a system. [NCS03, R3198] (Compare: certificate policy.)
$ セキュリティポリシー1.（i）システム内のセキュリティに関する現在および将来の決定を指導し、決定するための明確な目標、コース、または行動方法。[NCS03、R3198]（Compare：証明書ポリシー。）
2a. (I) A set of policy rules (or principles) that direct how a system (or an organization) provides security services to protect sensitive and critical system resources. (See: identity-based security policy, policy rule, rule-based security policy, rules of behavior. Compare: security architecture, security doctrine, security mechanism, security model, [R1281].)
2A。（i）機密システムリソースを保護するためにシステム（または組織）がセキュリティサービスを提供する方法を指示する一連のポリシー規則（または原則）。（識別ベースのセキュリティポリシー、ポリシールール、ルールベースのセキュリティポリシー、行動規則。比較：セキュリティアーキテクチャ、セキュリティ教師、セキュリティメカニズム、セキュリティモデル、[R1281]。）
2b. (O) A set of rules to administer, manage, and control access to network resources. [R3060, R3198]
2b。（O）ネットワークリソースへのアクセス、管理、および制御するための一連の規則。[R3060、R3198]
2c. (O) /X.509/ A set of rules laid down by an authority to govern the use and provision of security services and facilities.
2c。（o）/ x.509/セキュリティサービスと施設の使用と提供を統治する権限によって配置された一連の規則。
2d. (O) /Common Criteria/ A set of rules that regulate how assets are managed, protected, and distributed within a TOE.
2D。（O）/共通基準/資産が管理され、保護され、およびTOE内に配布され、配布された一連の規則。
Tutorial: Ravi Sandhu suggests that security policy is one of four layers of the security engineering process (as shown in the following diagram). Each layer provides a different view of security, ranging from what services are needed to how services are implemented.
チュートリアル：Ravi Sandhuは、セキュリティポリシーがセキュリティエンジニアリングプロセスの4つの層のうちの1つであることを示唆しています（次の図に示すように）。各層は、サービスの実装方法に必要なサービスが必要なサービスからの範囲のセキュリティの異なるビューを提供します。
What Security Services
Should Be Provided? +- - - - - - - - - - - - -+
^ +- - - - - - - - - - - -| Mission Functions View |
| | Security Policy |- - - - - - - - - - - - -+
| +- - - - - - - - - - - -| Domain Practices View |
| | Security Model |- - - - - - - - - - - - -+
| +- - - - - - - - - - - -| Enclave Services View |
| | Security Architecture |- - - - - - - - - - - - -+
| +- - - - - - - - - - - -| Agent Mechanisms View |
| | Security Mechanism |- - - - - - - - - - - - -+
v +- - - - - - - - - - - -| Platform Devices View |
How Are Security +- - - - - - - - - - - - -+
Services Implemented?
We suggest that each of Sandhu's four layers is a mapping between two points of view that differ in their degree of abstraction, according to the perspectives of various participants in system design, development, and operation activities, as follows:. - Mission functions view: The perspective of a user of system resources. States time-phased protection needs for resources and identifies sensitive and critical resources -- networks, hosts, applications, and databases. Independent of rules and practices used to achieve protection. - Domain practices view: The perspective of an enterprise manager who sets protection standards for resources. States rules and practices for protection. Identifies domain members; i.e., entities (users/providers) and resources (including data objects). Independent of system topology. Not required to be hierarchical. - Enclave services view: The perspective of a system designer who allocates security functions to major components. Assigns security services to system topology structures and their contents. Independent of security mechanisms. Hierarchical across all domains. - Agent mechanisms view: The perspective of a system engineer who specifies security mechanisms to implement security services. Specifies mechanisms to be used by protocol, database, and application engines. Independent of type and manufacture of platforms and other physical devices. - Platform devices view: The perspective of an as-built description of the system in operation. Specifies exactly how to build or assemble the system, and also specifies procedures for operating the system.
Sandhuの4つの層は、システム設計、開発、運営活動におけるさまざまな参加者の展望によると、次のように、抽象化の程度が異なる2つの観点からのマッピングであることをお勧めします。 - ミッション機能ビュー：システムリソースのユーザーのパースペクティブ。状態の時間段階保護はリソースに対して必要とされ、敏感で重要なリソース - ネットワーク、ホスト、アプリケーション、およびデータベースを識別します。保護を達成するために使用される規則や慣行とは無関係。 - ドメイン慣行ビュー：リソースの保護基準を設定するEnterprise Managerの観点。保護のための州の規則と慣行。ドメインメンバーを識別します。すなわち、エンティティ（ユーザ/プロバイダ）およびリソース（データオブジェクトを含む）。システムトポロジーとは無関係です。階層的である必要はありません。 - エンクリューブサービスビュー：セキュリティ機能を主要コンポーネントに割り当てるシステム設計者の観点。システムトポロジ構造とその内容にセキュリティサービスを割り当てます。セキュリティメカニズムとは無関係です。すべてのドメインにわたって階層的に。 - エージェントメカニズムビュー：セキュリティサービスを実装するためのセキュリティメカニズムを指定するシステムエンジニアの観点。プロトコル、データベース、およびアプリケーションエンジンによって使用されるメカニズムを指定します。プラットフォームやその他の物理デバイスの種類と製造とは無関係です。 - プラットフォームデバイスビュー：操作中のシステムのまとめの説明の観点。システムの構築または組み立て方法を正確に指定し、システムを操作するための手順も指定します。
$ Security Policy Database (SPD) (I) /IPsec/ In an IPsec implementation operating in a network node, a database that contains parameters that specify policies set by a user or administrator to determine what IPsec services, if any, are to be provided to IP datagrams sent or received by the node, and in what fashion they are provided. For each datagram, the SPD specifies one of three choices: discard the datagram, apply IPsec services (e.g., AH or ESP), or bypass IPsec. Separate inbound and outbound SPDs are needed because of the directionality of IPsec security associations. [R4301] (Compare: SAD.)
$ セキュリティポリシーデータベース（I）/ IPsec / IPSecの実装では、ネットワークノードで動作しているIPsec実装で、ユーザーまたは管理者によって設定されたポリシーを指定するパラメータを含むデータベースが含まれています。ノードによって送受信されるIPデータグラム、およびそれらがどのような方法で受信されます。各データグラムについて、SPDは3つの選択肢のうちの1つを指定します。データグラムを破棄し、IPsecサービス（たとえば、AHまたはESP）を適用するか、またはIPSecをバイパスします。IPSecセキュリティアソシエーションの方向性のために、別々のインバウンドおよびアウトバウンドSPDが必要です。[R4301]（比較：悲しい）
$ Security Protocol 3 (SP3) (O) A protocol [SDNS3] developed by SDNS to provide connectionless data security at the top of OSIRM Layer 3. (Compare: IPsec, NLSP.)
$ セキュリティプロトコル3（SP3）（O）SDNSによって開発され、OSIRMレイヤ3の上部に接続レスデータセキュリティを提供するためにSDNSが開発しました。（比較：IPSec、NLSP）
$ Security Protocol 4 (SP4) (O) A protocol [SDNS4] developed by SDNS to provide either connectionless or end-to-end connection-oriented data security at the bottom of OSIRM Layer 4. (See: TLSP.)
$ セキュリティプロトコル4（SP4）（O）SDNSによって開発され、OSIRMレイヤ4の下部に接続レスまたはエンドツーエンドの接続指向のデータセキュリティを提供するためにSDNSが開発しました。
$ security-relevant event (D) Synonym for "security event".
$ セキュリティ関連イベント（D）「セキュリティイベント」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it is wordy.
廃止予定語：IDocsはこの用語を使用しないでください。それは知られています。
$ security-sensitive function (D) Synonym for "security function".
$ セキュリティ依存関数（D）「セキュリティ機能」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this term; it is wordy.
廃止予定語：IDocsはこの用語を使用しないでください。それは知られています。
$ security service 1. (I) A processing or communication service that is provided by a system to give a specific kind of protection to system resources. (See: access control service, audit service, availability service, data confidentiality service, data integrity service, data origin authentication service, non-repudiation service, peer entity authentication service, system integrity service.)
$ Security Service 1.（i）システムリソースに特定の種類の保護を与えるためのシステムによって提供される処理または通信サービス。（アクセス制御サービス、監査サービス、可用性サービス、データ機密保持サービス、データ整合性サービス、データ原産地認証サービス、非否認サービス、ピアエンティティ認証サービス、システムインテグリティサービス）。
Tutorial: Security services implement security policies, and are implemented by security mechanisms.
チュートリアル：セキュリティサービスはセキュリティポリシーを実装し、セキュリティメカニズムによって実装されています。
2. (O) "A service, provided by a layer of communicating open systems, [that] ensures adequate security of the systems or the data transfers." [I7498-2]
2. （O） "コミュニケーションシステムのレイヤーによって提供されるサービス、[それ]はシステムの適切なセキュリティまたはデータ転送を保証します。」[I7498-2]
$ security situation (I) /ISAKMP/ The set of all security-relevant information (e.g., network addresses, security classifications, manner of operation such as normal or emergency) that is needed to decide the security services that are required to protect the association that is being negotiated.
$ セキュリティ状況（i）/ isakmp /すべてのセキュリティ関連情報のセット（ネットワークアドレス、セキュリティ分類、通常または緊急などの操作方法）のセキュリティは、それを保護するために必要なセキュリティサービスを決定する必要があります。交渉中です。
$ security target (N) /Common Criteria/ A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE.
$ セキュリティターゲット（N）/共通基準/識別されたつま先の評価の基礎として使用される一連のセキュリティ要件と仕様。
Tutorial: A security target (ST) is a statement of security claims for a particular information technology security product or system, and is the basis for agreement among all parties as to what security the product or system offers. An ST parallels the structure of a protection profile, but has additional elements that include product-specific detailed information. An ST contains a summary specification, which defines the specific measures taken in the product or system to meet the security requirements.
チュートリアル：セキュリティターゲット（ST）は、特定の情報技術セキュリティ製品またはシステムのセキュリティ請求の声明であり、製品またはシステムが提供するセキュリティに関するすべての当事者の間の合意の基礎です。STは保護プロファイルの構造を並べ替えますが、製品固有の詳細情報を含む追加の要素を持っています。STには、セキュリティ要件を満たす製品またはシステムで行われた特定の対策を定義する要約仕様が含まれています。
$ security token (I) See: token.
$ セキュリティトークン（i）トークンを参照してください。
$ security violation (I) An act or event that disobeys or otherwise breaches security policy. (See: compromise, penetration, security incident.)
$ セキュリティ違反（i）DisobeまたはSecurityポリシーを侵害する行為またはイベント。（妥協、浸透、セキュリティ事件。）
$ seed (I) A value that is an input to a pseudorandom number generator.
$ シード（i）擬似乱数発生器への入力である値。
$ selective-field confidentiality (I) A data confidentiality service that preserves confidentiality for one or more parts (i.e., fields) of each packet. (See: selective-field integrity.)
$ 選択的フィールド機密性（i）各パケットの1つまたは複数の部分（フィールド）について機密性を保持するデータ機密性サービス。（：選択的フィールドの整合性を参照してください。）
Tutorial: Data confidentiality service usually is applied to entire SDUs, but some situations might require protection of only part of each packet. For example, when Alice uses a debit card at an automated teller machine (ATM), perhaps only her PIN is enciphered for confidentiality when her transaction request is transmitted from the ATM to her bank's computer.
チュートリアル：データ機密保持サービスは通常SDU全体に適用されますが、状況によっては各パケットの一部のみを保護する必要がある場合があります。たとえば、Aliceが自動預け払い機（ATM）でデビットカードを使用する場合、おそらく彼女の取引要求がATMから彼女の銀行のコンピュータに送信されたときに機密性のために彼女のPINのみが暗号化されます。
In any given operational situation, there could be many different reasons for using selective field confidentiality. In the ATM example, there are at least four possibilities: The service may provide a fail-safe mode of operation, ensuring that the bank can still process transactions (although with some risk) even when the encryption system fails. It may make messages easier to work with when doing system fault isolation. It may avoid problems with laws that prevent shipping enciphered data across international borders. It may improve efficiency by reducing processing load at a central computer site.
特定の運用状況では、選択的フィールドの機密性を使用するための多くの異なる理由があります。ATMの例では、少なくとも4つの可能性があります。サービスはフェイルセーフな動作モードを提供することができ、暗号化システムが失敗した場合でも取引を処理することができます。システム障害の分離を実行するときは、メッセージを処理するのが簡単になることがあります。国際的な国境を越えた通知データの輸送を妨げる法律に関する問題を回避することがあります。中央コンピュータサイトでの処理負荷を軽減することで効率を向上させることができます。
$ selective-field integrity (I) A data integrity service that preserves integrity for one or more parts (i.e., fields) of each packet. (See: selective-field confidentiality.)
$ 選択的フィールドの整合性（i）各パケットの1つまたは複数の部分（フィールド）に対して完全性を保持するデータ整合性サービス。（参照フィールドの機密性を参照してください。）
Tutorial: Data integrity service may be implemented in a protocol to protect the SDU part of packets, the PCI part, or both. - SDU protection: When service is provided for SDUs, it usually is applied to entire SDUs, but it might be applied only to parts of SDUs in some situations. For example, an IPS Application-Layer protocol might need protection of only part of each packet, and this might enable faster processing. - PCI protection: To prevent active wiretapping, it might be desirable to apply data integrity service to the entire PCI, but some PCI fields in some protocols need to be mutable in transit. For example, the "Time to Live" field in IPv4 is changed each time a packet passes through a router in the Internet Layer. Thus, the value that the field will have when the packet arrives at its destination is not predictable by the sender and cannot be included in a checksum computed by the sender. (See: Authentication Header.)
チュートリアル：データ整合性サービスは、パケットのSDU部分、PCI部、またはその両方を保護するためのプロトコルで実装されてもよい。 - SDU保護：SDU用にサービスが提供されている場合、通常SDU全体に適用されますが、状況によってはSDUの一部にのみ適用される可能性があります。たとえば、IPSアプリケーション層プロトコルは各パケットの一部のみの保護を必要とし、これがより速い処理を可能にする可能性があります。 - PCI保護：アクティブな盗聴を防ぐために、データ整合性サービスをPCI全体に適用することが望ましいかもしれませんが、一部のプロトコルの一部のPCIフィールドは輸送中に変更可能である必要があります。たとえば、IPv4の「Live to Live」フィールドは、パケットがインターネットレイヤ内のルータを通過するたびに変更されます。したがって、パケットがその宛先に到着したときにフィールドが持つ値は送信者によって予測可能であり、送信者によって計算されたチェックサムに含まれない。（認証ヘッダーを参照してください。）
$ self-signed certificate (I) A public-key certificate for which the public key bound by the certificate and the private key used to sign the certificate are components of the same key pair, which belongs to the signer. (Compare: root certificate.)
$ 自己署名証明書（i）証明書にバインドされた公開鍵と証明書に署名する秘密鍵が、署名者に属するのと同じ鍵ペアのコンポーネントである公開鍵証明書です。（比較：ルート証明書。）
Tutorial: In a self-signed X.509 public-key certificate, the issuer's DN is the same as the subject's DN.
チュートリアル：自己署名されたX.509公開鍵証明書では、発行者のDNは被験者のDNと同じです。
$ semantic security (I) An attribute of an encryption algorithm that is a formalization of the notion that the algorithm not only hides the plain text but also reveals no partial information about the plain text; i.e., whatever is computable about the plain text when given the cipher text, is also computable without the cipher text. (Compare: indistinguishability.)
$ 意味セキュリティ（i）アルゴリズムがプレーンテキストを隠すだけでなく、プレーンテキストに関する部分的な情報を明らかにするという概念の形式化である暗号化アルゴリズムの属性。すなわち、暗号テキストが与えられたときにプレーンテキストについて計算可能なものは何でも、暗号テキストなしで計算可能である。（比較：区別性。）
$ semiformal (I) Expressed in a restricted syntax language with defined semantics. [CCIB] (Compare: formal, informal.)
$ セミフォーマル（i）は、定義されたセマンティクスを持つ制限されたシンタックス言語で表現されています。[CCIB]（比較：正式、非公式）
$ sensitive (I) A condition of a system resource such that the loss of some specified property of that resource, such as confidentiality or integrity, would adversely affect the interests or business of its owner or user. (See: sensitive information. Compare: critical.)
$ 機密性や整合性などのそのリソースの特定のプロパティの損失が、その所有者またはユーザーの利益またはビジネスに悪影響を及ぼすように、システムリソースの状態（i）システムリソースの状態。（：機密情報を参照してください。比較：クリティカル。）
$ sensitive compartmented information (SCI) (O) /U.S. Government/ Classified information concerning or derived from intelligence sources, methods, or analytical processes, which is required to be handled within formal control systems established by the Director of Central Intelligence. [C4009] (See: compartment, SAP, SCIF. Compare: collateral information.)
$ 敏感なコンパートメント情報（SCI）/ U.S。インテリジェンスソース、メソッド、または分析プロセスに関する政府/分類された情報。中央知性のディレクターによって確立された正式な制御システム内で処理される必要がある。[C4009]（参照：コンパートメント、SAP、SCIF。比較：担保情報）
$ sensitive compartmented information facility (SCIF) (O) /U.S. Government/ "An accredited area, room, group of rooms, building, or installation where SCI may be stored, used, discussed, and/or processed." [C4009] (See: SCI. Compare: shielded enclosure.)
$ 敏感なコンパートメント情報施設（SCIF）（O）/U.S。政府/「認定された地域、部屋、部屋のグループ、建物のグループ、建物の建物、または設置、または設置されている可能性がある、議論、議論、および/または処理された。」[C4009]（SCI。比較：シールドエンクロージャーを参照）
$ sensitive information 1. (I) Information for which (a) disclosure, (b) alteration, or (c) destruction or loss could adversely affect the interests or business of its owner or user. (See: data confidentiality, data integrity, sensitive. Compare: classified, critical.)
$ （a）開示、（b）変更、または（c）破壊または損失が、所有者またはユーザの興味や事業に悪影響を及ぼす可能性がある。（データ機密性、データの整合性、敏感な。比較：分類された、重大）
2. (O) /U.S. Government/ Information for which (a) loss, (b) misuse, (c) unauthorized access, or (d) unauthorized modification could adversely affect the national interest or the conduct of federal programs, or the privacy to which individuals are entitled under the Privacy Act of 1974, but that has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept classified in the interest of national defense or foreign policy.
2. （O）/U.S。政府/損失、（B）誤用、（C）不正アクセス、または（D）許可されていない修正は、国家の利益または連邦プログラムの行動、または個人が訴えるプライバシーに悪影響を及ぼす可能性があります。1974年のプライバシー法では、執行命令または国家防衛または外交政策の利益に分類されるように述べられている議会の行為によって確立された基準では特に承認されていません。
Tutorial: Systems that are not U.S. national security systems, but contain sensitive U.S. Federal Government information, must be protected according to the Computer Security Act of 1987 (Public Law 100-235). (See: national security.)
チュートリアル：米国国家セキュリティシステムではないが、敏感な米国連邦政府情報を含むシステムは、1987年のコンピュータセキュリティ法（公的法100-235）に従って保護されなければならない。（国家安全保障を参照してください。）
$ sensitivity label (D) Synonym for "classification label".
$ 感度ラベル（D）「分類ラベル」の同義語。
Deprecated term: IDOCs SHOULD NOT use this term because the definition of "sensitive" involves not only data confidentiality, but also data integrity.
廃止予定の用語：「敏感」の定義はデータ機密性だけでなくデータの整合性を含むため、IDocはこの用語を使用しないでください。
$ sensitivity level (D) Synonym for "classification level".
$ 感度レベル（D）「分類レベル」の同義語。
Deprecated term: IDOCs SHOULD NOT use this term because the definition of "sensitive" involves not only data confidentiality, but also data integrity.
廃止予定の用語：「敏感」の定義はデータ機密性だけでなくデータの整合性を含むため、IDocはこの用語を使用しないでください。
$ separation of duties (I) The practice of dividing the steps in a system process among different individual entities (i.e., different users or different roles) so as to prevent a single entity acting alone from being able to subvert the process. Usage: a.k.a. "separation of privilege". (See: administrative security, dual control.)
$ 業務の分離（i）単一のエンティティがプロセスを遮断することができることを防ぐために、異なる個々のエンティティ（すなわち、異なるユーザまたは異なる役割）の間のシステムプロセスにおけるステップを分割することの実際。使用法：a.k.a.「特権の分離」（管理セキュリティ、デュアルコントロールを参照してください。）
$ serial number See: certificate serial number.
$ シリアル番号証明書のシリアル番号を参照してください。
$ Serpent (O) A symmetric, 128-bit block cipher designed by Ross Anderson, Eli Biham, and Lars Knudsen as a candidate for the AES.
$ Serpent（O）Ross Anderson、Eli Biham、およびAESの候補としてのLARS Knundenによって設計された対称的な128ビットブロック暗号。
$ server (I) A system entity that provides a service in response to requests from other system entities called clients.
$ サーバー（i）クライアントと呼ばれる他のシステムエンティティからの要求に応答してサービスを提供するシステムエンティティ。
$ service data unit (SDU) (N) See: secondary definition under "protocol data unit".
$ サービスデータユニット（SDU）（N）「プロトコルデータユニット」の下のセカンダリ定義。
$ session 1a. (I) /computer usage/ A continuous period of time, usually initiated by a login, during which a user accesses a computer system.
$ セッション1A。（i）/コンピュータ使用量/通常ログインによって開始され、その間にユーザがコンピュータシステムにアクセスする。
1b. (I) /computer activity/ The set of transactions or other computer activities that are performed by or for a user during a period of computer usage.
1b。（i）/コンピュータ活動/コンピュータの使用期間中にユーザによって実行される、またはユーザによって実行されるトランザクションまたは他のコンピュータ活動のセット。
2. (I) /access control/ A temporary mapping of a principal to one or more roles. (See: role-based access control.)
2. （i）/アクセス制御/プリンシパルの一時的マッピング1つ以上の役割への一時的なマッピング。（「役割ベースのアクセス制御」を参照してください。
Tutorial: A user establishes a session as a principal and activates some subset of roles to which the principal has been assigned. The authorizations available to the principal in the session are the union of the permissions of all the roles activated in the session. Each session is associated with a single principal and, therefore, with a single user. A principal may have multiple, concurrent sessions and may activate a different set of roles in each session.
チュートリアル：ユーザーはプリンシパルとしてセッションを確立し、プリンシパルが割り当てられている役割のいくつかのサブセットをアクティブにします。セッションのプリンシパルで利用可能な権限は、セッションでアクティブ化されたすべての役割の権限の連合です。各セッションは単一のプリンシパルに関連付けられ、したがって単一のユーザーで関連付けられています。プリンシパルは複数の同時セッションを持ち、各セッションで異なる役割のセットを有効にすることができます。
3. (I) /computer network/ A persistent but (normally) temporary association between a user agent (typically a client) and a second process (typically a server). The association may persist across multiple exchanges of data, including multiple connections. (Compare: security association.)
3. （i）/コンピュータネットワーク/ユーザエージェント（通常はクライアント）と第2のプロセス（通常はサーバ）との間の一時的な関連付け（通常）一時的な関連付け。関連付けは、複数の接続を含む複数のデータの交換にまたがって存続することがあります。（比較：セキュリティ協会）
$ session key (I) In the context of symmetric encryption, a key that is temporary or is used for a relatively short period of time. (See: ephemeral, KDC, session. Compare: master key.)
$ セッションキー（i）対称暗号化の文脈では、一時的なキーであるか、または比較的短い期間使用されます。（参照：Ephemeral、KDC、セッション。比較：マスターキーを比較してください。）
Tutorial: A session key is used for a defined period of communication between two system entities or components, such as for the duration of a single connection or transaction set; or the key is used in an application that protects relatively large amounts of data and, therefore, needs to be rekeyed frequently.
チュートリアル：セッションキーは、単一の接続またはトランザクションセットの間、2つのシステムエンティティまたはコンポーネント間で定義された通信期間に使用されます。またはキーは、比較的大量のデータを保護するアプリケーションで使用されているため、頻繁に再確認される必要があります。
$ SET(trademark) (O) See: SET Secure Electronic Transaction(trademark).
$ SET（登録商標）（o）See：Secure Electronic Transaction（商標）を設定します。
$ SET private extension (O) One of the private extensions defined by SET for X.509 certificates. Carries information about hashed root key, certificate type, merchant data, cardholder certificate requirements, encryption support for tunneling, or message support for payment instructions.
$ Private Extensionを設定します（o）X.509証明書に設定して定義されたプライベート拡張機能の1つ。ハッシュされたルートキー、証明書の種類、マーチャントデータ、カード会員証明書の要件、トンネリングのための暗号化サポート、または支払い指示のメッセージサポートに関する情報を搭載しています。
$ SET qualifier (O) A certificate policy qualifier that provides information about the location and content of a SET certificate policy.
$ SET修飾子（O）設定証明書ポリシーの場所と内容に関する情報を提供する証明書ポリシー修飾子。
Tutorial: Besides the policies and qualifiers inherited from its own certificate, each CA in the SET certification hierarchy may add one qualifying statement to the root policy when the CA issues a certificate. The additional qualifier is a certificate policy for that CA. Each policy in a SET certificate may have these qualifiers: (a) a URL where a copy of the policy statement may be found; (b) an electronic mail address where a copy of the policy statement may be found; (c) a hash result of the policy statement, computed using the indicated algorithm; and (d) a statement declaring any disclaimers associated with the issuing of the certificate.
チュートリアル：独自の証明書から継承されたポリシーと修飾子のほかに、CAが証明書を発行したときに、各CAはそれぞれのCAの各CAを根本ポリシーに追加することができます。追加修飾子はそのCAの証明書ポリシーです。セット証明書の各ポリシーには、これらの修飾子がある可能性があります。（a）ポリシーステートメントのコピーが見つかる可能性があるURL。（b）ポリシーステートメントのコピーが見つかる可能性がある電子メールアドレス。（c）指示されたアルゴリズムを使用して計算されたPolicyステートメントのハッシュ結果。（d）証明書の発行に関連する免責事項を宣言する文。
$ SET Secure Electronic Transaction(trademark) or SET(trademark) (N) A protocol developed jointly by MasterCard International and Visa International and published as an open standard to provide confidentiality of transaction information, payment integrity, and authentication of transaction participants for payment card transactions over unsecured networks, such as the Internet. [SET1] (See: acquirer, brand, cardholder, dual signature, electronic commerce, IOTP, issuer, merchant, payment gateway, third party.)
$ セキュア電子取引（登録商標）またはSET（登録商標）（登録商標）（N）MasterCard International and Visa Internationalによって共同開発され、支払いカード取引のための取引情報の機密性、支払いの整合性、および取引の参加者の認証を提供するためのオープンスタンダードとして発行されたプロトコルインターネットなどの無担保ネットワークの上。[SET1]（accirer、ブランド、カード保有者、デュアルシグネチャー、電子商取引、IOTP、発行者、マーチャント、支払いゲートウェイ、第三者）。
Tutorial: This term and acronym are trademarks of SETCo. MasterCard and Visa announced the SET standard on 1 February 1996.
チュートリアル：この用語と頭字語はSetCoの商標です。MasterCardとVisaは1996年2月1日にセット基準を発表しました。
$ SETCo (O) Abbreviation of "SET Secure Electronic Transaction LLC", formed on 19 December 1997 by MasterCard and Visa for implementing the SET Secure Electronic Transaction(trademark) standard. A later memorandum of understanding added American Express and JCB Credit Card Company as co-owners of SETCo.
$ Setco（O）Set Secure Electronic Transaction（商標）規格を実装するためのマスターカードとビザにより、1997年12月19日にマスターカードとビザによる「セキュア電子取引LLC」の略語。SetCoの共同所有者として、アメリカンエキスプレスとJCBクレジットカード会社を追加した後の覚書。
$ SHA, SHA-1, SHA-2 (N) See: Secure Hash Algorithm.
$ SHA、SHA-1、SHA-2（N）Secure Hashアルゴリズムを参照してください。
$ shared identity (I) See: secondary definition under "identity".
$ 共有ID（i）「ID」の下の2次定義を参照してください。
$ shared secret (D) Synonym for "cryptographic key" or "password".
$ 共有秘密（D）「暗号鍵」または「パスワード」の同義語。
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.
廃止予定の使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されており、簡単に誤解される可能性があるため、定義を記載する必要があります。
$ shielded enclosure (O) "Room or container designed to attenuate electromagnetic radiation, acoustic signals, or emanations." [C4009] (See: emanation. Compare: SCIF.)
$ シールドエンクロージャ（O） "電磁放射線、音響信号、または発行を減衰させるように設計された部屋または容器。[C4009]（次のような：放置を参照してください。比較：SCIF。）
$ short title (O) "Identifying combination of letters and numbers assigned to certain items of COMSEC material to facilitate handling, accounting, and controlling." [C4009] (Compare: KMID, long title.)
$ 短いタイトル（O）は、ComSec資料の特定の項目に割り当てられた文字と数字の組み合わせを識別して、処理、会計、および制御を容易にします。」[C4009]（比較：kmid、長いタイトル）
$ shroud (D) /verb/ To encrypt a private key, possibly in concert with a policy that prevents the key from ever being available in cleartext form beyond a certain, well-defined security perimeter. [PKC12] (See: encrypt. Compare: seal, wrap.)
$ シュラウド（D）/動詞/秘密鍵を暗号化するために、おそらく鍵を特定の明確なセキュリティ境界を超えてクリアテキスト形式で利用できるようにすることができます。[PKC12]（「暗号化」を参照してください。比較：シール、ラップ。）
Deprecated Term: IDOCs SHOULD NOT use this term as defined here; the definition duplicates the meaning of other, standard terms. Instead, use "encrypt" or other terminology that is specific with regard to the mechanism being used.
廃止予定の用語：IDOCはここで定義されているようにこの用語を使用しないでください。定義は他の標準的な用語の意味を複製します。代わりに、使用されているメカニズムに関して特定の「暗号化」またはその他の用語を使用してください。
$ SHS (N) See: Secure Hash Standard.
$ SHS（N）Secure Secure Hash Standard。
$ sign (I) Create a digital signature for a data object. (See: signer.)
$ サイン（i）データオブジェクトのデジタル署名を作成します。（参照：署名者を参照してください。）
$ signal analysis (I) Gaining indirect knowledge (inference) of communicated data by monitoring and analyzing a signal that is emitted by a system and that contains the data but is not intended to communicate the data. (See: emanation. Compare: traffic analysis.)
$ システムによって放出され、データを含むがデータを通信することを意図していない信号を監視および分析することによって、通信データの信号分析（I）は、通信データの間接知識（推論）を得る。（次のように見ます。比較：交通分析。）
$ signal intelligence (I) The science and practice of extracting information from signals. (See: signal security.)
$ シグナルインテリジェンス（i）信号から情報を抽出するための科学と実践。（参照：信号のセキュリティを参照してください。）
$ signal security (N) (I) The science and practice of protecting signals. (See: cryptology, security.)
$ シグナルセキュリティ（N）（i）信号を保護するための科学と実践。（参照：暗号化、セキュリティ。）
Tutorial: The term "signal" denotes (a) communication in almost any form and also (b) emanations for other purposes, such as radar. Signal security is opposed by signal intelligence, and each discipline includes opposed sub-disciplines as follows [Kahn]:
チュートリアル：「信号」という用語は、ほとんどすべての形で（a）通信を表します。信号のセキュリティは信号のインテリジェンスによって対向し、各分野は次のように対向しているサブ分野を含みます[KAHN]：
Signal Security Signal Intelligence
------------------------------ ---------------------------------
1. Communication Security 1. Communication Intelligence
1a. Cryptography 1a. Cryptanalysis
1b. Traffic Security 1b. Traffic Analysis
1c. Steganography 1c. Detection and Interception
2. Electronic Security 2. Electronic Intelligence
2a. Emission Security 2a. Electronic Reconnaissance
2b. Counter-Countermeasures 2b. Countermeasures
------------------------------ ---------------------------------
$ signature (O) A symbol or process adopted or executed by a system entity with present intention to declare that a data object is genuine. (See: digital signature, electronic signature.)
$ 署名（o）データオブジェクトが本物であることを宣言することを意図して、システムエンティティによって採用または実行されたシンボルまたはプロセス。（を参照してください。デジタル署名、電子署名。）
$ signature certificate (I) A public-key certificate that contains a public key that is intended to be used for verifying digital signatures, rather than for encrypting data or performing other cryptographic functions.
$ 署名証明書（i）データを暗号化するか他の暗号機能を実行するのではなく、デジタル署名を検証するために使用されることを意図した公開鍵を含む公開鍵証明書。
Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" extension that indicates the purpose for which the certified public key is intended. (See: certificate profile.)
チュートリアル：v3 x.509公開鍵証明書には、認証された公開鍵が意図されている目的を示す「KeyUsage」拡張子がある可能性があります。（証明書プロファイルを参照してください。）
$ signed receipt (I) An S/MIME service [R2634] that (a) provides, to the originator of a message, proof of delivery of the message and (b) enables the originator to demonstrate to a third party that the recipient was able to verify the signature of the original message.
$ 署名された領収書（i）S / MIMEサービス[R2634]（a）は、メッセージの発信者に、メッセージの配信証明と（b）が発信者が受信者ができる第三者に発行者を実証することを可能にします。元のメッセージの署名を確認するため。
Tutorial: The receipt is bound to the original message by a signature; consequently, the service may be requested only for a message that is signed. The receipt sender may optionally also encrypt the receipt to provide confidentiality between the receipt sender and the receipt recipient.
チュートリアル：領収書は署名によって元のメッセージにバインドされています。その結果、サービスは署名されているメッセージに対してのみ要求されることがあります。領収書送信者は、領収書送信者と領収書受信者との間の機密性を提供するために、任意選択で領収書を暗号化することができる。
$ signer (N) A human being or organization entity that uses a private key to sign (i.e., create a digital signature on) a data object. [DSG]
$ 署名者（n）秘密鍵を使用する（すなわち、デジタル署名を作成する）、データオブジェクトを使用する人間または組織エンティティ。[DSG]
$ SILS (N) See: Standards for Interoperable LAN/MAN Security.
$ SILS（N）：相互運用可能なLAN / MANセキュリティの標準を参照してください。
$ simple authentication 1. (I) An authentication process that uses a password as the information needed to verify an identity claimed for an entity. (Compare: strong authentication.)
$ 簡易認証1.（i）エンティティを主張したアイデンティティを検証するために必要な情報としてパスワードを使用する認証プロセス。（比較：強力な認証）
2. (O) "Authentication by means of simple password arrangements." [X509]
2. （o）「簡単なパスワード契約による認証」[X509]
$ Simple Authentication and Security Layer (SASL) (I) An Internet specification [R2222, R4422] for adding authentication service to connection-based protocols. (Compare: EAP, GSS-API.) Tutorial: To use SASL, a protocol includes a command for authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. The command names a registered security mechanism. SASL mechanisms include Kerberos, GSS-API, S/KEY, and others. Some protocols that use SASL are IMAP4 and POP3.
接続ベースのプロトコルに認証サービスを追加するためのインターネット仕様[R2222、R4422]。（比較：EAP、GSS-API。）チュートリアル：SASLを使用するには、プロトコルには、ユーザーをサーバーに認証するためのコマンドを含み、オプションで後続のプロトコルインタラクションの保護をネゴシエートするためのコマンドが含まれています。コマンドは登録されたセキュリティメカニズムに名前を付けます。SASLメカニズムには、Kerberos、GSS-API、S / Keyなどがあります。SASLを使用するプロトコルによっては、IMAP4とPOP3です。
$ Simple Key Management for Internet Protocols (SKIP) (I) A key-distribution protocol that uses hybrid encryption to convey session keys that are used to encrypt data in IP packets. (See: SKIP reference in [R2356].)
$ インターネットプロトコルの単純な鍵管理（SKIP）（i）IPパケット内のデータを暗号化するために使用されるセッションキーを伝達するためにハイブリッド暗号化を使用する鍵配布プロトコル。（[R2356]の「リファレンスをスキップする」。）
Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at Sun Microsystems and proposed as the standard key management protocol for IPsec, but IKE was chosen instead. Although IKE is mandatory for an IPsec implementation, the use of SKIP is not excluded.
チュートリアル：SkipはSun MicrosystemsでAshar AzizとWhitfield Diffieによって設計され、IPsecの標準的な鍵管理プロトコルとして提案されていましたが、代わりに選択されました。IPSec実装に必須であるが、スキップの使用は除外されません。
SKIP uses the Diffie-Hellman-Merkle algorithm (or could use another key-agreement algorithm) to generate a key-encrypting key for use between two entities. A session key is used with a symmetric algorithm to encrypt data in one or more IP packets that are to be sent from one entity to the other. A symmetric KEK is established and used to encrypt the session key, and the encrypted session key is placed in a SKIP header that is added to each IP packet that is encrypted with that session key.
スキップDiffie-Hellman-Merkleアルゴリズムを使用して、2つのエンティティ間で使用するためのキー暗号化キーを生成するために使用します。セッションキーは、1つまたは複数のエンティティから他のエンティティから送信されるべき1つまたは複数のIPパケット内のデータを暗号化するために対称アルゴリズムと共に使用されます。Symmetric KEKが確立され、セッションキーを暗号化するために使用され、暗号化されたセッションキーはそのセッションキーで暗号化されている各IPパケットに追加されるスキップヘッダーに配置されます。
$ Simple Mail Transfer Protocol (SMTP) (I) A TCP-based, Application-Layer, Internet Standard protocol (RFC 821) for moving electronic mail messages from one computer to another.
$ 単純メール転送プロトコル（SMTP）（i）あるコンピュータから別のコンピュータへの電子メールメッセージを移動させるためのTCPベースのアプリケーション層、インターネット標準プロトコル（RFC 821）。
$ Simple Network Management Protocol (SNMP) (I) A (usually) UDP-based, Application-Layer, Internet Standard protocol (RFCs 3410-3418) for conveying management information between system components that act as managers and agents.
$ マネージャとエージェントとして機能するシステムコンポーネント間で管理情報を伝達するための、Simple Network Management Protocol（SNMP）（通常）UDPベースのアプリケーション層、インターネット標準プロトコル（RFCS 3410-3418）。
$ Simple Public Key Infrastructure (SPKI) (I) A set of experimental concepts (RFCs 2692, 2693) that were proposed as alternatives to the concepts standardized in PKIX.
$ 単純な公開鍵インフラ（SPKI）（I）PKIXで標準化された概念に代わるものとして提案された実験的概念（RFCS 2692,2693）のセット。
$ simple security property (N) /formal model/ Property of a system whereby a subject has read access to an object only if the clearance of the subject dominates the classification of the object. See: Bell-LaPadula model.
$ Simple Security Property（N）/正式モデル/システムのクリアランスがオブジェクトの分類を支配する場合にのみ、対象に読み取りアクセス権を読み取りました。ベルラパドゥラモデルを参照してください。
$ single sign-on 1. (I) An authentication subsystem that enables a user to access multiple, connected system components (such as separate hosts on a network) after a single login at only one of the components. (See: Kerberos.)
$ シングルサインオン1.（i）1つのコンポーネントのみに1回のログイン後に、ユーザーが複数の接続されたシステムコンポーネント（ネットワーク上の別々のホストなど）にアクセスできるようにする認証サブシステム。（参照：Kerberos。）
2. (O) /Liberty Alliance/ A security subsystem that enables a user identity to be authenticated at an identity provider -- i.e., at a service that authenticates and asserts the user's identity -- and then have that authentication be honored by other service providers.
2. （O）/ Liberty Alliance /ユーザーIDを認証することを可能にするセキュリティサブシステム、すなわち、ユーザの識別情報を認証してアサートし、その後認証を他のサービスプロバイダによって尊重させることができる。
Tutorial: A single sign-on subsystem typically requires a user to log in once at the beginning of a session, and then during the session transparently grants access by the user to multiple, separately protected hosts, applications, or other system resources, without further login action by the user (unless, of course, the user logs out). Such a subsystem has the advantages of being user friendly and enabling authentication to be managed consistently across an entire enterprise. Such a subsystem also has the disadvantage of requiring all the accessed components to depend on the security of the same authentication information.
チュートリアル：シングルサインオンサブシステムでは、通常、セッションの開始時に1回ログインする必要があり、セッション中にユーザーによるアクセスが透過的に複数の、別々に保護されているホスト、アプリケーション、またはその他のシステムリソースに透過的にアクセスできます。ユーザーによるログインアクション（もちろんユーザーがログアウトしていない限り）。そのようなサブシステムは、ユーザフレンドリーであり、認証を企業全体にわたって一貫して管理することを可能にするという利点を有する。そのようなサブシステムはまた、アクセスされたすべてのコンポーネントが同じ認証情報のセキュリティに依存することを要求するという欠点を有する。
$ singular identity (I) See: secondary definition under "identity".
$ 単数識別（i）「ID」の下の二次定義を参照してください。
$ site (I) A facility -- i.e., a physical space, room, or building together with its physical, personnel, administrative, and other safeguards -- in which system functions are performed. (See: node.)
$ サイト（i）施設、すなわち、物理的なスペース、部屋、またはその身体的、人員、管理上、およびその他の保護措置と共にシステム機能が実行される。（参照：ノードを参照してください。）
$ situation (I) See: security situation.
$ 状況（i）セキュリティの状況を参照してください。
$ SKEME (I) A key-distribution protocol from which features were adapted for IKE. [SKEME]
$ Skeme（i）どの機能がIKEに適合された鍵配布プロトコル。[スケメ]
$ SKIP (I) See: Simple Key Management for Internet Protocols.
$ スキップ（I）インターネットプロトコルのための単純な鍵管理を参照してください。
$ SKIPJACK (N) A type 2, 64-bit block cipher [SKIP, R2773] with a key size of 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, Key Exchange Algorithm.) Tutorial: SKIPJACK was developed by NSA and formerly classified at the U.S. DoD "Secret" level. On 23 June 1998, NSA announced that SKIPJACK had been declassified.
$ SKIPJACK（N）タイプ2,64ビットブロック暗号[スキップ、R2773]キーサイズは80ビットです。（Capstone、Clipper、Fortezza、鍵交換アルゴリズム）チュートリアル：SkipjackはNSAによって開発され、以前は米国のDOD "Secret"レベルで分類されていました。1998年6月23日、NSAはSkipjackが分解されたと発表しました。
$ slot (O) /MISSI/ One of the FORTEZZA PC card storage areas that are each able to hold an X.509 certificate plus other data, including the private key that is associated with a public-key certificate.
$ スロット（O）/ MISSI /公開鍵証明書に関連付けられている秘密鍵を含む、それぞれX.509証明書とその他のデータを保持することができるFortezza PCカード記憶領域の1つ。
$ smart card (I) A credit-card sized device containing one or more integrated circuit chips that perform the functions of a computer's central processor, memory, and input/output interface. (See: PC card, smart token.)
$ スマートカード（i）コンピュータの中央プロセッサ、メモリ、および入出力インタフェースの機能を実行する1つ以上の集積回路チップを含むクレジットカードサイズの装置。（PCカード、スマートトークンを参照してください。）
Usage: Sometimes this term is used rather strictly to mean a card that closely conforms to the dimensions and appearance of the kind of plastic credit card issued by banks and merchants. At other times, the term is used loosely to include cards that are larger than credit cards, especially cards that are thicker, such as PC cards.
使用法：この用語は、銀行や商人によって発行されたプラスチッククレジットカードの種類の寸法と外観に密接に適合したカードを意味するために厳密に使用されることがあります。他の時には、用語は、クレジットカードよりも大きいカード、特にPCカードなどの厚いカードを含むようにゆるく使用されています。
$ smart token (I) A device that conforms to the definition of "smart card" except that rather than having the standard dimensions of a credit card, the token is packaged in some other form, such as a military dog tag or a door key. (See: smart card, cryptographic token.)
$ スマートトークン（i）「スマートカード」の定義に準拠したデバイスは、クレジットカードの標準的な寸法を持つのではなく、トークンは、軍事犬のタグやドアキーなどの他の形式でパッケージ化されている点を除いて説明します。（スマートカード、暗号化トークンを参照してください。）
$ SMI (I) See: security management infrastructure.
$ SMI（i）セキュリティ管理インフラストラクチャを参照してください。
$ SMTP (I) See: Simple Mail Transfer Protocol.
$ SMTP（i）簡易メール転送プロトコルを参照してください。
$ smurf attack (D) /slang/ A denial-of-service attack that uses IP broadcast addressing to send ICMP ping packets with the intent of flooding a system. (See: fraggle attack, ICMP flood.)
$ Smurf Attack（D）/ Slang / Slang / IPブロードキャストアドレッシングを使用してシステムをフラッディングの意図を持つICMP Pingパケットを送信するサービス拒否攻撃。（：攻撃、ICMP洪水を参照）
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term.
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。
Derivation: The Smurfs are a fictional race of small, blue creatures that were created by a cartoonist. Perhaps the inventor of this attack thought that a swarm of ping packets resembled a gang of smurfs. (See: Deprecated Usage under "Green Book".) Tutorial: The attacker sends ICMP echo request ("ping") packets that appear to originate not from the attacker's own IP address, but from the address of the host or router that is the target of the attack. Each packet is addressed to an IP broadcast address, e.g., to all IP addresses in a given network. Thus, each echo request that is sent by the attacker results in many echo responses being sent to the target address. This attack can disrupt service at a particular host, at the hosts that depend on a particular router, or in an entire network.
派生：Smurfsは、漫画家によって作成された小さな青い生き物の架空のレースです。おそらくこの攻撃の発明者は、Pingパケットの群れがSmurfsのギャングに似ていると考えました。チュートリアル：攻撃者は、攻撃者自身のIPアドレスからのものではなく、ホストまたはルータのアドレスから発生するICMPエコー要求（ "ping"）パケットを送信します。攻撃のターゲット。各パケットは、特定のネットワーク内のすべてのIPアドレスに、IPブロードキャストアドレス、例えばすべてのIPアドレスにアドレス指定されます。したがって、攻撃者によって送信される各エコー要求は、ターゲットアドレスに送信されている多くのエコー応答をもたらす。この攻撃は、特定のルータ、またはネットワーク全体に依存するホストで、特定のホストでサービスを中断する可能性があります。
$ sneaker net (D) /slang/ A process that transfers data between systems only manually, under human control; i.e., a data transfer process that involves an air gap.
$ Sneaker Net（D）/ Slang /システム間でのデータを手動でのみ転送するプロセス。すなわち、エアギャップを含むデータ転送プロセス。
Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term.
廃止予定の用語：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。
$ Snefru (N) A public-domain, cryptographic hash function (a.k.a. "The Xerox Secure Hash Function") designed by Ralph C. Merkle at Xerox Corporation. Snefru can produce either a 128-bit or 256-bit output (i.e., hash result). [Schn] (See: Khafre, Khufu.)
$ SNEFRU（n）Xerox CorporationのRALPH C.Merkleによって設計されたパブリックドメイン、暗号化ハッシュ関数（A.K.A. "ゼロックスセキュアハッシュ関数"）。SNEFRUは、128ビットまたは256ビットの出力（すなわちハッシュ結果）を生成することができる。[シュン]（参照：Khafre、Khufu。）
$ sniffing (D) /slang/ Synonym for "passive wiretapping"; most often refers to capturing and examining the data packets carried on a LAN. (See: password sniffing.)
$ 「受動的な盗聴」のためのスナフィン（D）/スラング/シノニム。ほとんどの場合、LAN上で運ばれるデータパケットのキャプチャおよび検討を指します。（パスワードのスニッフィングを参照してください。）
Deprecated Term: IDOCs SHOULD NOT use this term; it unnecessarily duplicates the meaning of a term that is better established. (See: Deprecated Usage under "Green Book".
廃止予定語：IDocsはこの用語を使用しないでください。それは不必要に確立された用語の意味を複製します。（「グリーンブック」の「廃止予定の使用方法」。
$ SNMP (I) See: Simple Network Management Protocol.
$ SNMP（i）簡単なネットワーク管理プロトコルを参照してください。
$ social engineering (D) Euphemism for non-technical or low-technology methods, often involving trickery or fraud, that are used to attack information systems. Example: phishing.
$ 社会工学（D）非技術的または低テクノロジーの方法のための婉曲表現は、情報システムを攻撃するために使用される意見や詐欺を伴う。例：フィッシング
Deprecated Term: IDOCs SHOULD NOT use this term; it is too vague. Instead, use a term that is specific with regard to the means of attack, e.g., blackmail, bribery, coercion, impersonation, intimidation, lying, or theft.
廃止予定語：IDocsはこの用語を使用しないでください。あまりにも漠然としています。代わりに、攻撃手段、例えば脅迫、贈収賄、強制、偽装、脅迫、横臥、または盗難の手段に関して特有の用語を使用してください。
$ SOCKS (I) An Internet protocol [R1928] that provides a generalized proxy server that enables client-server applications (e.g., TELNET, FTP, or HTTP; running over either TCP or UDP) to use the services of a firewall.
$ SOCKS（i）ファイアウォールのサービスを使用するために、クライアントサーバーアプリケーション（例えば、Telnet、FTP、またはHTTP; TCPまたはUDPを介して実行する）を有効にする一般化されたプロキシサーバー[R1928]。
Tutorial: SOCKS is layered under the IPS Application Layer and above the Transport Layer. When a client inside a firewall wishes to establish a connection to an object that is reachable only through the firewall, it uses TCP to connect to the SOCKS server, negotiates with the server for the authentication method to be used, authenticates with the chosen method, and then sends a relay request. The SOCKS server evaluates the request, typically based on source and destination addresses, and either establishes the appropriate connection or denies it.
チュートリアル：靴下は、IPSアプリケーション層の下およびトランスポート層の上に階層化されます。ファイアウォール内のクライアントがファイアウォールを介してのみ到達可能なオブジェクトへの接続を確立したい場合は、TCPを使用してSOCKSサーバーに接続し、使用する認証方法のサーバーと交渉し、選択されたメソッドで認証します。そしてリレー要求を送信します。SOCKS Serverは、通常、ソースアドレスと宛先アドレスに基づいて要求を評価し、適切な接続を確立するか、またはそれを拒否します。
$ soft TEMPEST (O) The use of software techniques to reduce the radio frequency information leakage from computer displays and keyboards. [Kuhn] (See: TEMPEST.)
$ ソフトテンペスト（O）コンピュータディスプレイおよびキーボードからの無線周波数情報漏洩を減らすためのソフトウェア技術の使用。[kuhn]（参照：テンペストを参照）
$ soft token (D) A data object that is used to control access or authenticate authorization. (See: token.)
$ ソフトトークン（D）アクセス権を制御するために使用されるデータオブジェクト。（：トークンを参照してください。）
Deprecated Term: IDOCs SHOULD NOT use this term as defined here; the definition duplicates the meaning of other, standard terms. Instead, use "attribute certificate" or another term that is specific with regard to the mechanism being used.
廃止予定の用語：IDOCはここで定義されているようにこの用語を使用しないでください。定義は他の標準的な用語の意味を複製します。代わりに、「属性証明書」または使用されているメカニズムに関して具体的な別の用語を使用してください。
$ software (I) Computer programs (which are stored in and executed by computer hardware) and associated data (which also is stored in the hardware) that may be dynamically written or modified during execution. (Compare: firmware.)
$ 実行中に動的に書き込まれるかまたは修正され得るソフトウェア（I）コンピュータプログラム（コンピュータハードウェアに格納され実行される）および関連データ（ハードウェアに格納される）。（比較：ファームウェア。）
$ software error (I) /threat action/ See: secondary definitions under "corruption", "exposure", and "incapacitation".
$ ソフトウェアエラー（I）/脅威の対応/参照：「破損」、「露出」、および「無能力」の下の二次定義。
$ SORA (O) See: SSO-PIN ORA.
$ Sora（O）SEA：SSOピンORA。
$ source authentication (D) Synonym for "data origin authentication" or "peer entity authentication". (See: data origin authentication, peer entity authentication).
$ ソース認証（D）「データ発信認証」または「ピアエンティティ認証」の同義語。（Data Origin認証、ピアエンティティ認証を参照）。
Deprecated Term: IDOCs SHOULD NOT use this term because it is ambiguous and, in either meaning, duplicates the meaning of internationally standardized terms. If the intent is to authenticate the original creator or packager of data received, then use "data origin authentication". If the intent is to authenticate the identity of the sender of data in the current instance, then use "peer entity authentication".
廃止予定の用語：IDocは、あいまいであり、どちらの意味でも、国際的に標準化された用語の意味を複製してください。意図が受信したデータの元の作成者またはパッケージャを認証する場合は、「データ発信認証」を使用してください。インストールが現在のインスタンス内のデータの送信者のIDを認証する場合は、「ピアエンティティ認証」を使用してください。
$ source integrity (I) The property that data is trustworthy (i.e., worthy of reliance or trust), based on the trustworthiness of its sources and the trustworthiness of any procedures used for handling data in the system. Usage: a.k.a. Biba integrity. (See: integrity. Compare: correctness integrity, data integrity.)
$ ソースの整合性（i）データが信頼できるプロパティ（すなわち、信頼または信頼に値する）、およびシステム内のデータを処理するために使用されるすべての手順の信頼性に基づいて。使用法：a.k.a.bibaの整合性。（整合性。比較：正当性の整合性、データの整合性。）
Tutorial: For this kind of integrity, there are formal models of unauthorized modification (see: Biba model) that logically complement the more familiar models of unauthorized disclosure (see: Bell-LaPadula model). In these models, objects are labeled to indicate the credibility of the data they contain, and there are rules for access control that depend on the labels.
チュートリアル：この種の整合性のために、不正な修正の正式なモデルがあります（Biba Modelを参照）、不正な開示のより身近なモデルを論理的に補完する（Bell-Lapadulaモデルを参照）。これらのモデルでは、オブジェクトは含まれるデータの信頼性を示すためにラベル付けされ、ラベルに依存するアクセス制御のためのルールがあります。
$ SP3 (O) See: Security Protocol 3.
$ SP3（o）セキュリティプロトコル3を参照してください。
$ SP4 (O) See: Security Protocol 4.
$ SP4（o）セキュリティプロトコル4を参照してください。
$ spam 1a. (I) /slang verb/ To indiscriminately send unsolicited, unwanted, irrelevant, or inappropriate messages, especially commercial advertising in mass quantities.
$ スパム1A。（i）/スラング動詞/無差別に、求められていない、望ましくない、無関係、または不適切なメッセージ、特に大量の商業的広告を送る。
1b. (I) /slang noun/ Electronic "junk mail". [R2635]
1b。（i）/スラング名詞/電子「迷惑メール」。[R2635]
Deprecated Usage: IDOCs SHOULD NOT use this term in uppercase letters, because SPAM(trademark) is a trademark of Hormel Foods Corporation. Hormel says, "We do not object to use of this slang term [spam] to describe [unsolicited advertising email], although we do object to the use of our product image in association with that term. Also, if the term is to be used, it SHOULD be used in all lower-case letters to distinguish it from our trademark SPAM, which SHOULD be used with all uppercase letters." (See: metadata.)
廃止予定の使用法：SPAM（登録商標）がHormel Foods Corporationの商標であるため、IDOCは大文字で使用しないでください。Hormelは、「迷惑な広告メール」を説明するために、このSlang用語[スパムの使用に対象としていません。使用される、それはすべての大文字で使用されるべきである商標スパムとそれを区別するためにすべての小文字で使用されるべきです。」（：メタデータを参照してください。）
Tutorial: In sufficient volume, spam can cause denial of service. (See: flooding.) According to Hormel, the term was adopted as a result of a Monty Python skit in which a group of Vikings sang a chorus of 'SPAM, SPAM, SPAM ...' in an increasing crescendo, drowning out other conversation. This lyric became a metaphor for the unsolicited advertising messages that threaten to overwhelm other discourse on the Internet.
チュートリアル：十分な量で、スパムはサービス拒否を引き起こす可能性があります。Hormelによると、ヴァイキングのグループが「スパム、スパム、スパム...」のコーラスを歌ったMonty Python Skitの結果として採用され、溺死しています。会話。この歌詞は、インターネット上で他の談話を圧倒することを脅かす迷惑な広告メッセージのための比喩となりました。
$ SPD (I) See: Security Policy Database.
$ SPD（i）セキュリティポリシーデータベースを参照してください。
$ special access program (SAP) (O) /U.S. Government/ "Sensitive program, [that is] approved in writing by a head of agency with [i.e., who has] original top secret classification authority, [and] that imposes need-to-know and access controls beyond those normally provided for access to Confidential, Secret, or Top Secret information. The level of controls is based on the criticality of the program and the assessed hostile intelligence threat. The program may be an acquisition program, an intelligence program, or an operations and support program." [C4009] (See: formal access approval, SCI. Compare: collateral information.)
$ 特別アクセスプログラム（SAP）/ U.S。政府/「敏感なプログラム、すなわち、オリジナルのトップ秘密の分類局を持っている編成の責任者による書面で承認されています。機密、秘密、または上の秘密の情報へ。コントロールのレベルは、プログラムの重要性と評価された敵対的インテリジェンスの脅威に基づいています。プログラムは、取得プログラム、インテリジェンスプログラム、または操作およびサポートプログラムです。[C4009]（「正式なアクセス承認、SCI」を参照。比較：担保情報。
$ SPI (I) See: Security Parameters Index.
$ SPI（i）セキュリティパラメータ索引を参照してください。
$ SPKI (I) See: Simple Public Key Infrastructure.
$ SPKI（I）：単純な公開鍵インフラストラクチャ。
$ split key (I) A cryptographic key that is generated and distributed as two or more separate data items that individually convey no knowledge of the whole key that results from combining the items. (See: dual control, split knowledge.)
$ 分割キー（i）生成され、それぞれの別々のデータ項目として生成され分散された暗号鍵は、その鍵全体を組み合わせることから生じる全体の知識を知らせない。（「デュアルコントロール、分割知識」を参照してください。
$ split knowledge 1. (I) A security technique in which two or more entities separately hold data items that individually do not convey knowledge of the information that results from combining the items. (See: dual control, split key.)
$ 分割知識1.（i）2人以上のエンティティが、それを個別に個別に個別にデータ項目を保持しているセキュリティ手法である。（「デュアルコントロール、分割キー」を参照してください。
2. (O) "A condition under which two or more entities separately have key components [that] individually convey no knowledge of the plaintext key [that] will be produced when the key components are combined in the cryptographic module." [FP140]
2. （O）「暗号化モジュールで結合した場合、平文キーの知識を個別に伝えていないという条件が、平文キーの知識を個別に伝えるための条件。[FP140]
$ spoof (I) /threat action/ See: secondary definition under "masquerade".
$ スプーフ（i）/脅威の対応/参照：「Masquerade」の下のセカンダリ定義。
$ spoofing attack (I) Synonym for "masquerade attack".
$ スプーフィング攻撃（i）「マスカレード攻撃」の同義語。
$ spread spectrum (N) A TRANSEC technique that transmits a signal in a bandwidth much greater than the transmitted information needs. [F1037] Example: frequency hopping.
$ スペクトル拡散（n）送信された情報の必要性よりはるかに大きい帯域幅で信号を送信するトランコン技術。[F1037]例：周波数ホッピング。
Tutorial: Usually uses a sequential, noise-like signal structure to spread the normally narrowband information signal over a relatively wide band of frequencies. The receiver correlates the signals to retrieve the original information signal. This technique decreases potential interference to other receivers, while achieving data confidentiality and increasing immunity of spread spectrum receivers to noise and interference.
チュートリアル：通常、順次ノイズのような信号構造を使用して、比較的広い周波数帯域に渡って通常の狭帯域情報信号を広げます。受信機は信号を相関させて元の情報信号を検索する。この技術は他の受信機への潜在的な干渉を減少させながら、データの機密性を達成し、雑音および干渉に対するスペクトラム拡散受信機の耐性の増大を達成しながら、潜在的な干渉を減少させる。
$ spyware (D) /slang/ Software that an intruder has installed surreptitiously on a networked computer to gather data from that computer and send it through the network to the intruder or some other interested party. (See: malicious logic, Trojan horse.)
$ 侵入者がそのコンピュータからのデータを収集し、それをネットワークを通して侵入者または他の利害関係者に送信するために、侵入者がネットワークドコンピュータ上でひそかにインストールされたスパイウェア（D）/ Solang。（：悪意のある論理、トロイの木馬。）
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.
廃止予定の使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されており、簡単に誤解される可能性があるため、定義を記載する必要があります。
Tutorial: Some examples of the types of data that might be gathered by spyware are application files, passwords, email addresses, usage histories, and keystrokes. Some examples of motivations for gathering the data are blackmail, financial fraud, identity theft, industrial espionage, market research, and voyeurism.
チュートリアル：Spywareによって収集される可能性があるデータの種類のいくつかの例は、アプリケーションファイル、パスワード、電子メールアドレス、使用履歴、およびキーストロークです。データを集めるための動機のいくつかの例は、脅迫、財務詐欺、アイデンティティ盗難、産業スパイ、市場調査、そして盗撮です。
$ SSH(trademark) (N) See: Secure Shell(trademark).
$ SSH（登録商標）（N）：Secure Shell（商標）を参照してください。
$ SSL (I) See: Secure Sockets Layer.
$ SSL（I）Secure Sockets Layerを参照してください。
$ SSO (I) See: system security officer.
$ SSO（I）System Security Officer。
$ SSO PIN (O) /MISSI/ One of two PINs that control access to the functions and stored data of a FORTEZZA PC card. Knowledge of the SSO PIN enables a card user to perform the FORTEZZA functions intended for use by an end user and also the functions intended for use by a MISSI CA. (See: user PIN.)
$ SSOピン（O）/ MISSI / Fortezza PCカードの機能へのアクセスを制御する2つのピンのうちの1つ。SSOピンの知識は、カードユーザがエンドユーザによる使用を意図したFortezza機能と、Missi CAによる使用を目的とした機能とを実行することを可能にする。（以下を参照してください。）
$ SSO-PIN ORA (SORA) (O) /MISSI/ A MISSI organizational RA that operates in a mode in which the ORA performs all card management functions and, therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards issued to end users.
$ SSOピンORA（SORA）（O）/ MISSI / A MISSI組織RAは、ORAがすべてのカード管理機能を実行するモードで動作し、したがって、エンドユーザーに発行されたFortezza PCカード用のSSOピンの知識を必要とします。
$ Standards for Interoperable LAN/MAN Security (SILS) 1. (N) The IEEE 802.10 standards committee. (See: [FP191].)
$ 相互運用可能なLAN / MANセキュリティ（SILS）の規格1.（N）IEEE 802.10規格委員会。（[参照] [FP191]を参照）
2. (N) A set of IEEE standards, which has eight parts: (a) Model, including security management, (b) Secure Data Exchange protocol, (c) Key Management, (d) [has been incorporated in (a)], (e) SDE Over Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are incorporated in IEEE Standard 802.10-1998.
2. （n）セキュリティ管理、（B）セキュアデータ交換プロトコル、（C）キー管理、（D）を含む8つの部分を有するIEEE規格のセット（a）【（a）】（e）SDEイーサネット2.0、（F）SDEサブレイヤ管理、（G）SDEセキュリティラベル、および（H）SDE PICS準拠。部分B、E、F、G、およびHは、IEEE規格802.10-1998に組み込まれています。
$ star property (N) See: *-property.
$ Star Property（N）：* -property。
$ Star Trek attack (D) /slang/ An attack that penetrates your system where no attack has ever gone before.
$ Star Trek Attack（D）/ Slang /攻撃が行われたことがないシステムを貫通する攻撃。
Deprecated Usage: IDOCs SHOULD NOT use this term; it is a joke for Trekkies. (See: Deprecated Usage under "Green Book".)
廃止予定の使用法：IDOCはこの用語を使用しないでください。それはトレッキーのための冗談です。（「グリーンブック」の「廃止予定の使用」。）
$ static (I) /adjective/ Refers to a cryptographic key or other parameter that is relatively long-lived. (Compare: ephemeral.)
$ 静的（i）/形容詞/は、比較的長い間命名されている暗号鍵または他のパラメータを指します。（比較：エフェメラル。）
$ steganography (I) Methods of hiding the existence of a message or other data. This is different than cryptography, which hides the meaning of a message but does not hide the message itself. Examples: For classic, physical methods, see [Kahn]; for modern, digital methods, see [John]. (See: cryptology. Compare: concealment system, digital watermarking.)
$ Steganography（i）メッセージまたはその他のデータの存在を隠す方法。これは暗号とは異なり、メッセージの意味を隠しますが、メッセージ自体を隠しません。例：古典的な、物理的方法については、[KAHN]を参照してください。モダンでデジタル方式の場合は、[John]を参照してください。（CRYPTOLOGYを参照してください。比較：隠蔽システム、デジタル透かし）
$ storage channel (I) See: covert storage channel.
$ ストレージチャネル（i）Covert Storage Channelを参照してください。
$ storage key (I) A cryptographic key used by a device for protecting information that is being maintained in the device, as opposed to protecting information that is being transmitted between devices. (See: cryptographic token, token copy. Compare: traffic key.)
$ 記憶鍵（i）装置間で送信されている情報を保護するのとは対照的に、装置内に維持されている情報を保護するための装置によって使用される暗号鍵。（参照：暗号化トークン、トークンコピー。比較：Traffic Key。）
$ stream cipher (I) An encryption algorithm that breaks plain text into a stream of successive elements (usually, bits) and encrypts the n-th plaintext element with the n-th element of a parallel key stream, thus converting the plaintext stream into a ciphertext stream. [Schn] (See: block cipher.)
$ ストリーム暗号（i）プレーンテキストを連続した要素のストリーム（通常はビット）に分割し、並列キーストリームのn番目の要素を暗号化し、それによって平文ストリームをaに変換する暗号化アルゴリズム。暗号文ストリーム。[SCHN]（「暗号化」を参照してください。
$ stream integrity service (I) A data integrity service that preserves integrity for a sequence of data packets, including both (a) bit-by-bit datagram integrity of each individual packet in the set and (b) packet-by-packet sequential integrity of the set as a whole. (See: data integrity. Compare: datagram integrity service.)
$ Stream Integrity Service（i）セット内の各個々のパケットのビットごとのデータグラムの整合性を含む、一連のデータパケットの整合性を保持するデータインテグリティサービス、および（B）パケットごとの順次整合性全体としてセットの。（データの整合性を参照してください。比較：データグラム整合性サービスを比較してください。）
Tutorial: Some internetwork applications need only datagram integrity, but others require that an entire stream of packets be protected against insertion, reordering, deletion, and delay: - "Insertion": The destination receives an additional packet that was not sent by the source. - "Reordering": The destination receives packets in a different order than that in which they were sent by the source. - "Deletion": A packet sent by the source is not ever delivered to the intended destination. - "Delay": A packet is detained for some period of time at a relay, thus hampering and postponing the packet's normal timely delivery from source to destination.
チュートリアル：インターネットワークアプリケーションの中にはデータグラムの整合性だけが必要ですが、他のユーザーは挿入、並べ替え、削除、および遅延から保護されることを要求します。 - 「挿入」：宛先は、ソースによって送信されなかった追加のパケットを受信します。 - 「並べ替え」：宛先は、ソースによって送信されたものとは異なる順序でパケットを受け取ります。 - 「削除」：ソースによって送信されたパケットは、意図された宛先に配信されていません。 - "遅延"：リレーで何らかの時間をかけてパケットが拘束されているため、ソースから宛先へのパケットの通常のタイムリーな配信を妨げて延期します。
$ strength 1. (I) /cryptography/ A cryptographic mechanism's level of resistance to attacks [R3766]. (See: entropy, strong, work factor.)
$ 強度1.（i）/暗号化/暗号メカニズムの攻撃に対する抵抗のレベル[R3766]。（：エントロピー、強い、仕事係数。）
2. (N) /Common Criteria/ "Strength of function" is a "qualification of a TOE security function expressing the minimum efforts assumed necessary to defeat its expected security behavior by directly attacking its underlying security mechanisms": (See: strong.) - Basic: "A level of the TOE strength of function where analysis shows that the function provides adequate protection against casual breach of TOE security by attackers possessing a low attack potential." - Medium: "... against straightforward or intentional breach ... by attackers possessing a moderate attack potential." - High: "... against deliberately planned or organized breach ... by attackers possessing a high attack potential."
2. （N）/共通基準/「機能の強さ」は、「基礎となるセキュリティメカニズムを直接攻撃することで予想されるセキュリティ行動を阻害するために必要な最低限の努力を表すTOEセキュリティ機能の資格」です。「分析が、この関数が低攻撃の可能性を持つ攻撃者による攻撃者によるさまざまな防犯に対する適切な保護を提供する機能のTOE強度のレベル。」 - 中程度：「...中等度の攻撃の可能性を持っている攻撃者による簡単または意図的な違反に対する...」 - 高い：「...故意に計画された、または組織化された違反...高い攻撃力を持っている攻撃者による違反...」
$ strong 1. (I) /cryptography/ Used to describe a cryptographic algorithm that would require a large amount of computational power to defeat it. (See: strength, work factor, weak key.)
$ （i）/暗号化/それを倒すために大量の計算力を必要とする暗号化アルゴリズムを説明するために使用されます。（強さ、仕事係数、弱いキーを参照してください。）
2. (I) /COMPUSEC/ Used to describe a security mechanism that would be difficult to defeat. (See: strength, work factor.)
2. （i）/ compusec /敗北するのが難しいセキュリティメカニズムを説明するために使用されます。（筋力、仕事係数を参照）
$ strong authentication 1. (I) An authentication process that uses a cryptographic security mechanism -- particularly public-key certificates -- to verify the identity claimed for an entity. (Compare: simple authentication.)
$ 強力な認証1.（i）暗号化セキュリティメカニズムを使用する認証プロセス - 特に公開鍵証明書 - エンティティに主張されているIDを検証します。（比較：簡単な認証。）
2. (O) "Authentication by means of cryptographically derived credentials." [X509]
2. （O）「暗号化された資格情報による認証」[X509]
$ subject 1a. (I) A process in a computer system that represents a principal and that executes with the privileges that have been granted to that principal. (Compare: principal, user.)
$ 被験者1A。（i）プリンシパルを表すコンピュータシステムで、そのプリンシパルに付与された特権で実行されるプロセス。（比較：プリンシパル、ユーザー。）
1b. (I) /formal model/ A system entity that causes information to flow among objects or changes the system state; technically, a process-domain pair. A subject may itself be an object relative to some other subject; thus, the set of subjects in a system is a subset of the set of objects. (See: Bell-LaPadula model, object.)
1b。（i）/正式モデル/情報をオブジェクト間でフローするか、システム状態を変更するシステムエンティティ。技術的にはプロセスドメインのペア。対象は、その他の主題に対する対象となることがあります。したがって、システム内の被験者のセットは、一組のオブジェクトのサブセットである。（：ベルララドゥラモデル、オブジェクト。）
2. (I) /digital certificate/ The name (of a system entity) that is bound to the data items in a digital certificate; e.g., a DN that is bound to a key in a public-key certificate. (See: X.509.)
2. （i）/デジタル証明書/デジタル証明書のデータ項目にバインドされている名前（システムエンティティの）。例えば、公開鍵証明書の鍵にバインドされているDN。（X.509を参照）
$ subject CA (D) The CA that is the subject of a cross-certificate issued by another CA. [X509] (See: cross-certification.)
$ 件名CA（D）他のCAが発行した相互証明書の主題であるCA。[X509]（以下を参照してください。
Deprecated Term: IDOCs SHOULD NOT use this term because it is not widely known and could be misunderstood. Instead, say "the CA that is the subject of the cross-certificate".
廃止予定の用語：IDocは、それが広く知られていないため、誤解されている可能性があるため、IDOCはこの用語を使用しないでください。代わりに、「証明書の主題であるCA」を言う。
$ subnetwork (N) An OSI term for a system of packet relays and connecting links that implement OSIRM layer 2 or 3 to provide a communication service that interconnects attached end systems. Usually, the relays are all of the same type (e.g., X.25 packet switches, or interface units in an IEEE 802.3 LAN). (See: gateway, internet, router.)
$ サブネットワーク（n）osmirmレイヤ2または3を実装するためにOSIRMレイヤ2または3を実装するためのネットワークシステムのシステムのOSI用語は、接続されたエンドシステムを相互接続する通信サービスを提供する。通常、リレーはすべて同じタイプ（例えば、X.25パケットスイッチ、またはIEEE 802.3 LAN内のインタフェース単位）です。（参照：ゲートウェイ、インターネット、ルーター。）
$ subordinate CA (SCA) 1. (I) A CA whose public-key certificate is issued by another (superior) CA. (See: certification hierarchy. Compare: cross-certification.)
$ 下位CA（SCA）1。（i）別の（上司）CAから公開鍵証明書が発行されたCA。（参照：認証階層。比較：CROSS-CERTIFICATIONS）
2. (O) /MISSI/ The fourth-highest (i.e., bottom) level of a MISSI certification hierarchy; a MISSI CA whose public-key certificate is signed by a MISSI CA rather than by a MISSI PCA. A MISSI SCA is the administrative authority for a subunit of an organization, established when it is desirable to organizationally distribute or decentralize the CA service. The term refers both to that authoritative office or role, and to the person who fills that office. A MISSI SCA registers end users and issues their certificates and may also register ORAs, but may not register other CAs. An SCA periodically issues a CRL.
2. （O）/ MISSI / MISSI認証階層の4番目の最高（すなわち下）レベル。Public-Key証明書がMissi PCAではなくミッションCAによって署名されているMISSI CA。Missi SCAは、CAサービスを組織的に配布または分散化することが望ましい場合に設立された組織のサブユニットの管理権限です。この用語は、その権威ある事務所または役割の両方を指し、その事務所を埋める人に。Missi SCAはエンドユーザーを登録し、証明書を発行し、ORASを登録することもありますが、他のCAを登録することはできません。SCAは定期的にCRLを発行します。
$ subordinate DN (I) An X.500 DN is subordinate to another X.500 DN if it begins with a set of attributes that is the same as the entire second DN except for the terminal attribute of the second DN (which is usually the name of a CA). For example, the DN <C=FooLand, O=Gov, OU=Treasurer, CN=DukePinchpenny> is subordinate to the DN <C=FooLand, O=Gov, CN=KingFooCA>.
$ 下位DN（i）2番目のDNの端末属性を除いて、2番目のDNと同じ属性のセットで始まる場合は、X.500 DNが別のX.500 DNに下位（通常は名前です。caの。たとえば、DN <C = ooland、O = GOV、OU = Great、CN = DukePinchpenny>は、DN = oholand、o = gov、cn = Kingfooca>に従属しています。
$ subscriber (I) /PKI/ A user that is registered in a PKI and, therefore, can be named in the "subject" field of a certificate issued by a CA in that PKI. (See: registration, user.)
$ 加入者（i）/ PKI / PKIに登録されているユーザは、そのPKIでCAが発行した証明書の「件名」フィールドに命名することができる。（登録、ユーザー。）
Usage: This term is needed to distinguish registered users from two other kinds of PKI users: - Users that access the PKI but are not identified to it: For example, a relying party may access a PKI repository to obtain the certificate of some other party. (See: access.) - Users that do not access the PKI: For example, a relying party (see: certificate user) may use a digital certificate that was obtained from a database that is not part of the PKI that issued the certificate.
使用法：この用語は、登録ユーザーを他の2種類のPKIユーザーと区別するために必要です。。（アクセスしてください。） - PKIにアクセスしないユーザー：たとえば、信頼当事者（証明書ユーザーを参照）は、証明書を発行したPKIの一部ではないデータベースから取得されたデジタル証明書を使用できます。
$ substitution 1. (I) /cryptography/ A method of encryption in which elements of the plain text retain their sequential position but are replaced by elements of cipher text. (Compare: transposition.)
$ 置換1.（i）/暗号化/平文の要素がそれらの順次位置を保持するが暗号テキストの要素に置き換えられる暗号化の方法。（比較：転置。）
2. (I) /threat action/ See: secondary definition under "falsification".
2. （i）/脅威の処置/参照：「改ざん」の下の二次定義。
$ subsystem (I) A collection of related system components that together perform a system function or deliver a system service.
$ サブシステム（i）一緒にシステム機能を実行するか、システムサービスを提供する関連システムコンポーネントのコレクション。
$ superencryption (I) An encryption operation for which the plaintext input to be transformed is the ciphertext output of a previous encryption operation. (Compare: hybrid encryption.)
$ 上限顕微構成（i）変換される平文入力が、前回の暗号化操作の暗号文出力である暗号化操作。（比較：ハイブリッド暗号化。）
$ superuser (I) /UNIX/ Synonym for "root".
$ スーパーユーザー（I）/ UNIX / /「root」の同義語。
$ survivability (I) The ability of a system to remain in operation or existence despite adverse conditions, including natural occurrences, accidental actions, and attacks. (Compare: availability, reliability.)
$ 生存能力（i）自然発生、偶発的な行動、および攻撃を含む悪条件の悪条件にもかかわらず、システムが運用または存在のままである能力。（比較：可用性、信頼性。）
$ swIPe (I) An encryption protocol for IP that provides confidentiality, integrity, and authentication and can be used for both end-to-end and intermediate-hop security. [Ioan] (Compare: IPsec.)
$ スワイプ（i）機密性、整合性、および認証を提供するIP用の暗号化プロトコルで、エンドツーエンドおよび中間ホップのセキュリティの両方に使用できます。[IOAN]（比較：IPSec。）
Tutorial: The swIPe protocol is an IP predecessor that is concerned only with encryption mechanisms; policy and key management are handled outside the protocol.
チュートリアル：スワイププロトコルは、暗号化メカニズムのみに関心があるIP前身です。ポリシーと鍵管理はプロトコルの外部で処理されます。
$ syllabary (N) /encryption/ A list of individual letters, combinations of letters, or syllables, with their equivalent code groups, used for spelling out proper names or other unusual words that are not present in the basic vocabulary (i.e., are not in the codebook) of a code used for encryption.
$ シラバリ（N）/暗号化/個々の文字のリスト、文字の組み合わせ、文字、または音節、または基本的な語彙には存在しない他の異常な単語をスペルチェックするために使用されます（つまり、暗号化に使用されるコードのコードブック。
$ symmetric cryptography (I) A branch of cryptography in which the algorithms use the same key for both of two counterpart cryptographic operations (e.g., encryption and decryption). (See: asymmetric cryptography. Compare: secret-key cryptography.)
$ 対称暗号化（i）アルゴリズムが2つの対応する暗号化操作（例えば、暗号化および復号化）の両方に同じキーを使用する暗号化の分野。（非対称暗号化を参照。比較：秘密鍵暗号化）
Tutorial: Symmetric cryptography has been used for thousands of years [Kahn]. A modern example is AES.
チュートリアル：対称暗号化は何千年もの間使用されています[KAHN]。現代の例はAESです。
Symmetric cryptography has a disadvantage compared to asymmetric cryptography with regard to key distribution. For example, when Alice wants to ensure confidentiality for data she sends to Bob, she encrypts the data with a key, and Bob uses the same key to decrypt. However, keeping the shared key secret entails both cost and risk when the key is distributed to both Alice and Bob. (See: key distribution, key management.)
対称暗号化は、重要な分布に関して非対称暗号化と比較して不利な点を有する。たとえば、アリスがBobに送信するデータの機密性を確保したい場合、彼女はデータをキーで暗号化し、Bobは同じキーを使用して復号化するために同じキーを使用します。ただし、共有キーの秘密を維持すると、キーがAliceとBobの両方に分散されている場合のコストとリスクの両方が伴います。（参照：鍵配布、鍵管理。）
$ symmetric key (I) A cryptographic key that is used in a symmetric cryptographic algorithm. (See: symmetric cryptography.)
$ 対称鍵（i）対称暗号化アルゴリズムで使用される暗号鍵。（対称暗号化を参照してください。）
$ SYN flood (I) A denial-of-service attack that sends a large number of TCP SYN (synchronize) packets to a host with the intent of disrupting the operation of that host. (See: blind attack, flooding.)
$ Syn Flood（i）そのホストの操作を中断するという意図を持つホストに多数のTCP SYN（同期）パケットを送信するサービス拒否攻撃。（盲目の攻撃、洪水を参照してください。）
Tutorial: This attack seeks to exploit a vulnerability in the TCP specification or in a TCP implementation. Normally, two hosts use a three-way exchange of packets to establish a TCP connection: (a) host 1 requests a connection by sending a SYN packet to host 2; (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet to host 1; and (c) host 1 completes the connection by sending an ACK packet to host 2. To attack host 2, host 1 can send a series of TCP SYNs, each with a different phony source address. ([R2827] discusses how to use packet filtering to prevent such attacks from being launched from behind an Internet service provider's aggregation point.) Host 2 treats each SYN as a request from a separate host, replies to each with a SYN-ACK, and waits to receive the matching ACKs. (The attacker can use random or unreachable sources addresses in the SYN packets, or can use source addresses that belong to third parties, that then become secondary victims.)
チュートリアル：この攻撃は、TCP仕様またはTCP実装における脆弱性を悪用しようとしています。通常、2つのホストはTCP接続を確立するためにパケットの3方向交換を使用します。（a）ホスト1は、SYNパケットをホスト2に送信して接続を要求します。（b）ホスト2は、SYN-ACK（確認応答）パケットをホスト1に送信することによって応答します。（c）ホスト1ホスト2にACKパケットを送信することで接続を完了します。ホスト2を攻撃するために、ホスト1はそれぞれ異なる偽の送信元アドレスを持つ一連のTCP SYNを送信できます。（[R2827]パケットフィルタリングの使用方法は、インターネットサービスプロバイダの集約点の後ろからそのような攻撃を開始するのを防ぐ方法について説明します。一致するACKを受信するのを待ちます。（攻撃者は、SYNパケット内でランダムまたは到達不能なソースアドレスを使用することも、第三者に属するソースアドレスを使用することもできます。
For each SYN-ACK that is sent, the TCP process in host 2 needs some memory space to store state information while waiting for the matching ACK to be returned. If the matching ACK never arrives at host 2, a timer associated with the pending SYN-ACK will eventually expire and release the space. But if host 1 (or a cooperating group of hosts) can rapidly send many SYNs to host 2, host 2 will need to store state information for many pending SYN-ACKs and may run out of space. This can prevent host 2 from responding to legitimate connection requests from other hosts or even, if there are flaws in host 2's TCP implementation, crash when the available space is exhausted.
送信されるSYN-ACKごとに、ホスト2のTCPプロセスは、一致するACKが返されるのを待っている間に状態情報を格納するためのいくつかのメモリ容量が必要です。一致するACKがホスト2に到着しない場合、保留中のSYN-ACKに関連するタイマーは、最終的にはスペースを有効期限切れと解除します。ただし、ホスト1（またはホストの協力グループ）がホスト2に多くのSYNを迅速に送信できる場合、ホスト2は多くの保留中のSYN-ACKの状態情報を格納する必要があり、スペースが不足する可能性があります。これにより、ホスト2が他のホストからの正当な接続要求に応答するのを防ぐことも、ホスト2のTCP実装に欠陥がある場合は、使用可能なスペースが使い果たされたときにクラッシュします。
$ synchronization (I) Any technique by which a receiving (decrypting) cryptographic process attains an internal state that matches the transmitting (encrypting) process, i.e., has the appropriate keying material to process the cipher text and is correctly initialized to do so.
$ 同期（i）受信（復号化）暗号処理が送信（暗号化）プロセスと一致する内部状態を達成する任意の技術、すなわち、暗号テキストを処理するための適切なキーイングマテリアルを有し、そうするように正しく初期化される。
$ system (I) Synonym for "information system".
$ システム（I）「情報システム」の同義語。
Usage: This is a generic definition, and is the one with which the term is used in this Glossary. However, IDOCs that use the term, especially IDOCs that are protocol specifications, SHOULD state a more specific definition. Also, IDOCs that specify security features, services, and assurances need to define which system components and system resources are inside the applicable security perimeter and which are outside. (See: security architecture.)
使用法：これは一般的な定義であり、この用語集で用語が使用されているものです。ただし、プロトコル仕様である用語、特にIDocを使用するIDocは、より具体的な定義を述べるべきです。また、セキュリティ機能、サービス、および保証を指定するIDocは、どのシステムコンポーネントとシステムリソースが該当するセキュリティ周辺の内部であり、外部にあるかを定義する必要があります。（セキュリティアーキテクチャを参照してください。）
$ system architecture (N) The structure of system components, their relationships, and the principles and guidelines governing their design and evolution over time. [DoD10] (Compare: security architecture.)
$ システムアーキテクチャ（n）システムコンポーネントの構造、それらの関係、およびそれらの設計と進化を経験する原理とガイドラインの構造。[DOD10]（比較：セキュリティアーキテクチャ。）
$ system component 1. (I) A collection of system resources that (a) forms a physical or logical part of the system, (b) has specified functions and interfaces, and (c) is treated (e.g., by policies or specifications) as existing independently of other parts of the system. (See: subsystem.)
$ システム構成要素1.（i）（a）システムの物理部分または論理部分を形成するシステムリソースの集まり、（b）は関数とインタフェースを指定し、（c）は（例えば、ポリシーまたは仕様によって）扱われます。システムの他の部分とは無関係に存在します。（参照：サブシステム。）
2. (O) /ITSEC/ An identifiable and self-contained part of a TOE.
2. （O）/ ITSEC / TOEの識別可能で自己完結型の部分。
Usage: Component is a relative term because components may be nested; i.e., one component of a system may be a part of another component of that system.
使用法：コンポーネントがネストされる可能性があるため、コンポーネントは相対的な用語です。すなわち、システムの一構成要素は、そのシステムの他の構成要素の一部であり得る。
Tutorial: Components can be characterized as follows: - A "physical component" has mass and takes up space. - A "logical component" is an abstraction used to manage and coordinate aspects of the physical environment, and typically represents a set of states or capabilities of the system.
チュートリアル：コンポーネントは次のように特徴付けることができます。 - 「物理コンポーネント」は質量を持ち、スペースを取ります。 - 「論理コンポーネント」は、物理的環境の側面を管理し調整するために使用される抽象化であり、通常はシステムの一連の状態または機能を表します。
$ system entity (I) An active part of a system -- a person, a set of persons (e.g., some kind of organization), an automated process, or a set of processes (see: subsystem) -- that has a specific set of capabilities. (Compare: subject, user.)
$ システムエンティティ（i）システムの積極的な部分 - 人、一連の一連の一連の人物、自動化されたプロセス、または一連のプロセス（サブシステム） - それは特定のセットを持っています。能力の。（比較：件名、ユーザー。）
$ system high (I) The highest security level at which a system operates, or is capable of operating, at a particular time or in a particular environment. (See: system-high security mode.)
$ システムの高さ（i）システムが動作する最も高いセキュリティレベル、または特定の時間または特定の環境で動作することができる最高のセキュリティレベル。（System-High Security Modeを参照してください。）
$ system-high security mode (I) A mode of system operation wherein all users having access to the system possess all necessary authorizations (both security clearance and formal access approval) for all data handled by the system, but some users might not have need-to-know for all the data. (See: /system operation/ under "mode", formal access approval, protection level, security clearance.)
$ システム - ハイセキュリティモード（i）システムにアクセスできるすべてのユーザは、システムによって処理されるすべてのデータについて必要なすべての権限（セキュリティクリアランスと正式アクセス承認の両方）を所有していますが、一部のユーザーが必要としない可能性があります。すべてのデータのために知っています。（/システム操作/「モード」の下、正式アクセス承認、保護レベル、セキュリティクリアランス。）
Usage: Usually abbreviated as "system-high mode". This mode was defined in U.S. DoD policy that applied to system accreditation, but the term is widely used outside the Government.
使用法：通常、「システムハイモード」と省略されています。このモードはシステム認定に適用される米国のDODポリシーで定義されていましたが、この用語は政府外で広く使用されています。
$ system integrity 1. (I) An attribute or quality "that a system has when it can perform its intended function in a unimpaired manner, free from deliberate or inadvertent unauthorized manipulation." [C4009, NCS04] (See: recovery, system integrity service.)
$ システムの整合性1.（i）故意または不注意な不正な操作のない、意図されていない方法でその意図された機能を実行できるときにシステムが持っている属性または品質。」[C4009、NCS04]（recovery、System Integrity Serviceを参照）
2. (D) "Quality of an [information system] reflecting the logical correctness and reliability of the operating system; the logical completeness of the hardware and software implementing the protection mechanisms; and the consistency of the data structures and occurrence of the stored data." [from an earlier version of C4009]
2. （d）「情報システム」の品質オペレーティングシステムの論理的な正当性と信頼性を反映しています。保護メカニズムを実装するハードウェアとソフトウェアの論理的な完全性と、データ構造の一貫性と保存データの発生[以前のバージョンのC4009から]
Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it mixes several concepts in a potentially misleading way. Instead, IDOCs should use the term with definition 1 and, depending on what is meant, couple the term with additional, more specifically descriptive and informative terms, such as "correctness", "reliability", and "data integrity".
廃止予定の定義：IDOCは定義2を使用しないでください。代わりに、IDocは定義1で用語を使用し、何が意味されているのかによって、「正当性」、「信頼性」、および「データの整合性」など、その用語を追加、より具体的に説明的で情報処理用語と結合する必要があります。
$ system integrity service (I) A security service that protects system resources in a verifiable manner against unauthorized or accidental change, loss, or destruction. (See: system integrity.)
$ システムインテグリティサービス（i）不正または偶発的な変更、損失、または破壊に対してシステムリソースを検証可能な方法で保護するセキュリティサービス。（システムの整合性を参照してください。）
$ system low (I) The lowest security level supported by a system at a particular time or in a particular environment. (Compare: system high.)
$ システムLOW（i）特定の時間または特定の環境でシステムによってサポートされている最低のセキュリティレベル。（比較：システムハイ）
$ system resource (I) Data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment. (See: system component.)
情報システムに含まれる$ System Resource（i）データ。またはシステムによって提供されるサービス。または電力の処理や通信帯域幅などのシステム容量。またはシステム機器の項目（すなわち、ハードウェア、ファームウェア、ソフトウェア、またはドキュメント）。またはシステム操作と機器を収容する施設。（システムコンポーネントを参照してください。）
$ system security officer (SSO) (I) A person responsible for enforcement or administration of the security policy that applies to a system. (Compare: manager, operator.)
$ システムセキュリティ責任者（SSO）（I）システムに適用されるセキュリティポリシーの執行または管理を担当する人。（比較：マネージャー、オペレーター。）
$ system user (I) A system entity that consumes a product or service provided by the system, or that accesses and employs system resources to produce a product or service of the system. (See: access, [R2504]. Compare: authorized user, manager, operator, principal, privileged user, subject, subscriber, system entity, unauthorized user.)
$ システムユーザー（i）システムによって提供される製品またはサービスを消費する、またはシステムリソースを使用してシステムの製品またはサービスを作成するためにシステムリソースにアクセスして使用するシステムエンティティ。（アクセス、[R2504]を参照してください。比較ユーザー、マネージャ、オペレータ、プリンシパル、特権ユーザー、件名、加入者、システムエンティティ、不正なユーザー。）
Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood: - This term usually refers to an entity that has been authorized to access the system, but the term sometimes is used without regard for whether access is authorized. - This term usually refers to a living human being acting either personally or in an organizational role. However, the term also may refer to an automated process in the form of hardware, software, or firmware; to a set of persons; or to a set of processes. - IDOCs SHOULD NOT use the term to refer to a mixed set containing both persons and processes. This exclusion is intended to prevent situations that might cause a security policy to be interpreted in two different and conflicting ways.
使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されているため、この用語が簡単に使用できます。アクセスが許可されているかどうかに関係なく。 - この用語は通常、個人的にまたは組織的な役割のいずれかに行動する生きている人間を指します。ただし、この用語は、ハードウェア、ソフトウェア、またはファームウェアの形で自動化されたプロセスを指すこともあります。一組の人に。または一連のプロセスに。 - IDOCは、その用語を使用して、人物とプロセスの両方を含む混合セットを参照してください。この除外は、セキュリティポリシーを2つの異なる方法で解釈させる可能性がある状況を防ぐことを目的としています。
A system user can be characterized as direct or indirect: - "Passive user": A system entity that is (a) outside the system's security perimeter *and* (b) can receive output from the system but cannot provide input or otherwise interact with the system. - "Active user": A system entity that is (a) inside the system's security perimeter *or* (b) can provide input or otherwise interact with the system.
システムユーザーは直接的または間接的なものとして特徴付けることができます。 - 「パッシブユーザー」：システムのセキュリティ境界*と*（b）の外側の（a）のシステムエンティティは、システムからの出力を受信できますが、入力またはその他のインタラクションを提供できません。システム。 - "Active User"：システムのセキュリティ境界*または*（b）内の（a）のシステムエンティティは、システムと入力されているか、そうでなければ対話することができます。
$ TACACS (I) See: Terminal Access Controller (TAC) Access Control System.
$ TACACS（i）ターミナルアクセスコントローラ（TAC）アクセス制御システムを参照してください。
$ TACACS+ (I) A TCP-based protocol that improves on TACACS by separating the functions of authentication, authorization, and accounting and by encrypting all traffic between the network access server and authentication server. TACACS+ is extensible to allow any authentication mechanism to be used with TACACS+ clients.
$ TACACS（i）認証、許可、および会計の機能を分離し、ネットワークアクセスサーバーと認証サーバー間のすべてのトラフィックを暗号化することによって、TACACを改善するTCPベースのプロトコル。TACACSは、認証メカニズムをTACACSクライアントと使用できるようにするために拡張可能です。
$ tamper (I) Make an unauthorized modification in a system that alters the system's functioning in a way that degrades the security services that the system was intended to provide. (See: QUADRANT. Compare: secondary definitions under "corruption" and "misuse".)
$ タンパー（i）システムが提供することを意図しているセキュリティサービスを劣化させる方法でシステムの機能を変更するシステムで不正な変更を加えます。（象限を参照してください。比較：「破損」および「誤用」の下の二次定義。）
$ tamper-evident (I) A characteristic of a system component that provides evidence that an attack has been attempted on that component or system.
$ Tamper-Evident（i）そのコンポーネントまたはシステムで攻撃が試みられたという証拠を提供するシステムコンポーネントの特徴。
Usage: Usually involves physical evidence. (See: tamper.)
使用法：通常物理的証拠を含みます。（：改ざんを参照してください。）
$ tamper-resistant (I) A characteristic of a system component that provides passive protection against an attack. (See: tamper.)
$ 耐タンパ抵抗（I）攻撃に対する受動的保護を提供するシステム構成要素の特性。（：改ざんを参照してください。）
Usage: Usually involves physical means of protection.
使用法：通常、保護の身体的手段を含みます。
$ tampering (I) /threat action/ See: secondary definitions under "corruption" and "misuse".
$ 改ざん（I）/脅威の対応/参照：「破損」および「誤用」の下の二次定義。
$ target of evaluation (TOE) (N) /Common Criteria/ An information technology product or system that is the subject of a security evaluation, together with the product's associated administrator and user documentation. (Compare: protection profile.)
$ 評価の対象（TOE）（N）/共通基準/情報技術製品またはセキュリティ評価の対象となる情報技術およびユーザのマニュアル。（比較：保護プロファイル）
Tutorial: The security characteristics of the target of evaluation (TOE) are described in specific terms by a corresponding security target, or in more general terms by a protection profile. In Common Criteria philosophy, it is important that a TOE be evaluated against the specific set of criteria expressed in the target. This evaluation consists of rigorous analysis and testing performed by an accredited, independent laboratory. The scope of a TOE evaluation is set by the EAL and other requirements specified in the target. Part of this process is an evaluation of the target itself, to ensure that it is correct, complete, and internally consistent and can be used as the baseline for the TOE evaluation.
チュートリアル：評価ターゲットのセキュリティ特性（TOE）は、対応するセキュリティターゲット、または保護プロファイルによってより一般的な用語によって特定の用語で説明されています。一般的な基準哲学では、TOEはターゲット内で表現された特定の基準のセットに対して評価されることが重要です。この評価は、認定された独立した実験室によって行われた厳密な分析および試験からなる。TOE評価の範囲は、ターゲットで指定されたEALと他の要件によって設定されます。このプロセスの一部は、正しい、完全で、内部的に一貫性があることを確実にし、TOE評価のベースラインとして使用できることを確認するためのターゲット自体の評価です。
$ TCB (N) See: trusted computing base.
$ TCB（N）は、信頼できるコンピューティングベースを参照してください。
$ TCC field (I) See: Transmission Control Code field.
$ TCCフィールド（i）送信制御コードフィールドを参照してください。
$ TCG (N) See: Trusted Computing Group.
$ TCG（n）：信頼できるコンピューティンググループを参照してください。
$ TCP (I) See: Transmission Control Protocol.
$ TCP（i）送信制御プロトコルを参照してください。
$ TCP/IP (I) Synonym for "Internet Protocol Suite".
$ TCP / IP（i）「インターネットプロトコルスイート」の同義語。
$ TCSEC (N) See: Trusted Computer System Evaluation Criteria. (Compare: TSEC.)
$ TCSEC（N）：信頼できるコンピュータシステム評価基準を参照してください。（比較：TSEC。）
$ TDEA (I) See: Triple Data Encryption Algorithm.
$ TDEA（I）トリプルデータ暗号化アルゴリズムを参照してください。
$ teardrop attack (D) /slang/ A denial-of-service attack that sends improperly formed IP packet fragments with the intent of causing the destination system to fail.
$ ティアドロップ攻撃（D）/ Slang / Slang /宛先システムに不適切に形成されたIPパケットフラグメントを送信する拒否攻撃。
Deprecated Term: IDOCs that use this term SHOULD state a definition for it because the term is often used imprecisely and could easily be misunderstood. (See: Deprecated Usage under "Green Book".)
廃止予定の用語：この用語を使用するIDocは、その用語が不正確に使用され、簡単に誤解される可能性があるため、定義を定義します。（「グリーンブック」の「廃止予定の使用」。）
$ technical non-repudiation (I) See: (secondary definition under) non-repudiation.
$ 技術的な非否認（I）:(下の二次定義）非否認。
$ technical security (I) Security mechanisms and procedures that are implemented in and executed by computer hardware, firmware, or software to provide automated protection for a system. (See: security architecture. Compare: administrative security.)
$ 技術的セキュリティ（I）システムの自動保護を提供するためにコンピュータのハードウェア、ファームウェア、またはソフトウェアによって実行され実行されるセキュリティメカニズムと手順。（セキュリティアーキテクチャを参照してください。比較：管理セキュリティ。）
$ Telecommunications Security Word System (TSEC) (O) /U.S. Government/ A terminology for designating telecommunication security equipment. (Compare: TCSEC.)
$ 電気通信セキュリティワードシステム（TSEC）/U.S。政府/電気通信セキュリティ機器を指定するための用語。（比較：TCSEC。）
Tutorial: A TSEC designator has the following parts: - Prefix "TSEC/" for items and systems, or suffix "/TSEC" for assemblies. (Often omitted when the context is clear.) - First letter, for function: "C" COMSEC equipment system, "G" general purpose, "K" cryptographic, "H" crypto-ancillary, "M" manufacturing, "N" noncryptographic, "S" special purpose. - Second letter, for type or purpose: "G" key generation, "I" data transmission, "L" literal conversion, "N" signal conversion, "O" multipurpose, "P" materials production, "S" special purpose, "T" testing or checking, "U" television, "W" teletypewriter, "X" facsimile, "Y" speech. - Optional third letter, used only in designations of assemblies, for type or purpose: "A" advancing, "B" base or cabinet, "C" combining, "D" drawer or panel, "E" strip or chassis, "F" frame or rack, "G" key generator, "H" keyboard, "I" translator or reader, "J" speech processing, "K" keying or permuting, "L" repeater, "M" memory or storage, "O" observation, "P" power supply or converter, "R" receiver, "S" synchronizing, "T" transmitter, "U" printer, "V" removable COMSEC component, "W" logic programmer/programming, "X" special purpose. - Model number, usually two or three digits, assigned sequentially within each letter combination (e.g., KG-34, KG-84). - Optional suffix letter, used to designate a version. First version has no letter, next version has "A" (e.g., KG-84, KG-84A), etc.
チュートリアル：TSEC指定子には、次の部分があります。 - アセンブリの場合は、アイテムとシステムの場合は「TSEC /」、または接尾辞 "/ TSEC"です。 （コンテキストが明確な場合には省略しています。） - 機能のための最初の文字、 "C" Comsec機器システム、 "G"汎用、 "k"暗号化、 "H"暗号 - 補助、 "M"製造、 "n"非暗号化、「S」特殊目的。 - タイプまたは目的のための2番目の文字： "G"キーの生成、 "I"データ伝送、 "L"リテラル変換、 "n"信号変換、 "O"多目的、 "P"材料生産、 "S"特殊目的、 「u」テレビ、「W」テレピュレーション、「X」ファクシミリ、「Y」スピーチ。 - タイプまたは目的のために、アセンブリの指定においてのみ使用されるオプションの3番目の文字：「A」の進行、「B」ベースまたはキャビネット、「D」引き出しまたはパネル、E「ストリップまたはシャーシ」、「 "フレームまたはラック、" G "キージェネレータ、" H "キーボード、" i "翻訳者またはリーダー、" J "スピーチ処理、" K "キーイングまたはターミナル" L "リピータ、" M "メモリまたはストレージ" 「観察、「P」電源またはコンバータ、「R」受信機、「S」同期、「T」トランスミッタ、「U」プリンタ、「v」リムーバブルCOMSECコンポーネント、「W」ロジックプログラマ/プログラミング、「X」スペシャル目的。 - 各文字の組み合わせ内に順次割り当てられたモデル番号、通常は2桁または3桁（例えば、KG-34、KG-84）。 - オプションのサフィックス文字は、バージョンを指定するために使用されます。最初のバージョンには文字がない、次のバージョンは "A"（例えば、KG-84、KG-84A）などを持っています。
$ TELNET (I) A TCP-based, Application-Layer, Internet Standard protocol (RFC 854) for remote login from one host to another.
$ Telnet（i）1つのホストから別のホストへのリモートログインのためのTCPベースのアプリケーション層、インターネット標準プロトコル（RFC 854）。
$ TEMPEST 1. (N) Short name for technology and methods for protecting against data compromise due to electromagnetic emanations from electrical and electronic equipment. [Army, Russ] (See: inspectable space, soft TEMPEST, TEMPEST zone. Compare: QUADRANT)
$ Tempest 1.（n）電気電子機器からの電磁気分析によるデータの妥協点から保護するための技術と方法のための短い名前。[陸軍、Russ]（検査可能なスペース、柔らかい雰囲気、温度ゾーン。比較：象限）
2. (O) /U.S. Government/ "Short name referring to investigation, study, and control of compromising emanations from IS equipment." [C4009]
2. （O）/U.S。政府/「捜査、勉強、および妥協の妥当性を指す短編小名」[C4009]
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for "electromagnetic emanations security"; instead, use EMSEC. Also, the term is NOT an acronym for Transient Electromagnetic Pulse Surveillance Technology.
廃止予定の使用法：IDOCは、この用語を「電磁放棄セキュリティ」の同義語として使用しないでください。代わりに、EMSECを使用してください。また、この用語は過号的ではありません。過渡的な電磁パルス監視技術。
Tutorial: The U.S. Federal Government issues security policies that (a) state specifications and standards for techniques to reduce the strength of emanations from systems and reduce the ability of unauthorized parties to receive and make use of emanations and (b) state rules for applying those techniques. Other nations presumably do the same.
チュートリアル：米国連邦政府は、システムからの発展の強さを減らすための州の仕様および技術の規格を課し、発生した締約国の能力を減らすための州の仕様および基準を発行し、それらを適用するための状態規則を遂行する。テクニック他の国はおそらく同じことをする。
$ TEMPEST zone (O) "Designated area [i.e., a physical volume] within a facility where equipment with appropriate TEMPEST characteristics ... may be operated." [C4009] (See: emanation security, TEMPEST. Compare: control zone, inspectable space.)
適切な温度特性を有する機器が運転されることがある施設内の$ TEMPEST ZONE（O） "指定領域[すなわち物理ボリューム]。[C4009]（Emanation Security、Tempest。比較：コントロールゾーン、検査可能スペース。）
Tutorial: The strength of an electromagnetic signal decreases in proportion to the square of the distance between the source and the receiver. Therefore, EMSEC for electromagnetic signals can be achieved by a combination of (a) reducing the strength of emanations to a defined level and (b) establishing around that equipment an appropriately sized physical buffer zone from which unauthorized entities are excluded. By making the zone large enough, it is possible to limit the signal strength available to entities outside the zone to a level lower than can be received and read with known, state-of-the-art methods. Typically, the need for and size of a TEMPEST zone established by a security policy depends not only on the measured level of signal emitted by equipment, but also on the perceived threat level in the equipment's environment.
チュートリアル：電磁信号の強度は、ソースとレシーバ間の距離の2乗に比例して減少します。したがって、電磁信号のEMSECは、（a）の発行の強さを定義されたレベルに縮小することによって達成することができ、その機器の周りを確立する（b）不正なエンティティが除外された適切なサイズの物理的バッファゾーン。ゾーンを十分に大きくすることで、ゾーン外のエンティティに利用可能な信号強度を受信して既知の最先端の方法で読み取ることができる。通常、セキュリティポリシーによって確立された温度ゾーンの必要性とサイズは、機器によって放出された信号の測定レベルだけでなく、機器の環境における知覚された脅威レベルにも依存します。
$ Terminal Access Controller (TAC) Access Control System (TACACS) (I) A UDP-based authentication and access control protocol [R1492] in which a network access server receives an identifier and password from a remote terminal and passes them to a separate authentication server for verification. (See: TACACS+.)
$ 端末アクセスコントローラ（TAC）アクセス制御システム（TACACS）（I）ネットワークアクセスサーバがリモート端末から識別子とパスワードを受信し、それらを別の認証サーバに渡すUDPベースの認証およびアクセス制御プロトコル[R1492]検証のために。（TACACSを参照してください。）
Tutorial: TACACS can provide service not only for network access servers but also routers and other networked computing devices via one or more centralized authentication servers. TACACS was originally developed for ARPANET and has evolved for use in commercial equipment.
チュートリアル：TACACSは、ネットワークアクセスサーバーだけでなく、1つ以上の集中認証サーバーを介してルーターやその他のネットワークコンピューティングデバイスにもサービスを提供できます。TACACはもともとアルパネットのために開発されており、商業機器での使用のために進化しました。
$ TESS (I) See: The Exponential Encryption System.
$ TESS（i）指数暗号化システム：
$ The Exponential Encryption System (TESS) (I) A system of separate but cooperating cryptographic mechanisms and functions for the secure authenticated exchange of cryptographic keys, the generation of digital signatures, and the distribution of public keys. TESS uses asymmetric cryptography, based on discrete exponentiation, and a structure of self-certified public keys. [R1824]
$ 指数暗号化システム（TESS）（i）暗号化された暗号化された暗号化されたメカニズムと協力しているのは、暗号化キーの安全な認証された交換、デジタル署名の発生、および公開鍵の分布のための機能のシステム。テスは、離散的な指数に基づいて非対称暗号化、および自己認証された公開鍵の構造を使用します。[R1824]
$ theft (I) /threat action/ See: secondary definitions under "interception" and "misappropriation".
$ 盗難（I）/脅威の処置/参照：「傍受」および「不当適用」の下の二次定義。
$ threat 1a. (I) A potential for violation of security, which exists when there is an entity, circumstance, capability, action, or event that could cause harm. (See: dangling threat, INFOCON level, threat action, threat agent, threat consequence. Compare: attack, vulnerability.)
$脅威1A。（i）セキュリティに違反する可能性があり、存在する企業、状況、機能、行動、または害を及ぼす可能性があるイベントがある場合に存在する可能性があります。（：ダングリングの脅威、情報レベル、脅威の行動、脅威エージェント、脅威の結果。比較：攻撃、脆弱性。）
1b. (N) Any circumstance or event with the potential to adversely affect a system through unauthorized access, destruction, disclosure, or modification of data, or denial of service. [C4009] (See: sensitive information.)
1b。（n）許可されていないアクセス、破壊、開示、またはデータの修正、またはサービス拒否を通じてシステムに悪影響を及ぼす可能性のある状況またはイベント。[C4009]（機密情報を参照してください。）
Usage: (a) Frequently misused with the meaning of either "threat action" or "vulnerability". (b) In some contexts, "threat" is used more narrowly to refer only to intelligent threats; for example, see definition 2 below. (c) In some contexts, "threat" is used more broadly to cover both definition 1 and other concepts, such as in definition 3 below.
使用法：（a）「脅威行動」または「脆弱性」の意味でよく使われています。（b）いくつかの状況では、「脅威」は、インテリジェントな脅威のみを指すためにより狭く使用されています。たとえば、以下の定義2を参照してください。（c）いくつかの状況では、「脅威」は、以下の定義3などの定義1およびその他の概念の両方をカバーするために、より広く使用されている。
Tutorial: A threat is a possible danger that might exploit a vulnerability. Thus, a threat may be intentional or not: - "Intentional threat": A possibility of an attack by an intelligent entity (e.g., an individual cracker or a criminal organization). - "Accidental threat": A possibility of human error or omission, unintended equipment malfunction, or natural disaster (e.g., fire, flood, earthquake, windstorm, and other causes listed in [FP031]).
チュートリアル：脅威は、脆弱性を悪用する可能性がある可能性のある危険性です。したがって、脅威は意図的であるかもしれません： - 「意図的な脅威」：インテリジェントなエンティティによる攻撃の可能性（例えば、個々のクラッカーまたは刑事組織）。 - 「偶発的な脅威」：人間の誤りや省略、意図しない機器故障、または自然災害（例えば、火災、洪水、地震、暴風雨、その他の原因）の可能性。
The Common Criteria characterizes a threat in terms of (a) a threat agent, (b) a presumed method of attack, (c) any vulnerabilities that are the foundation for the attack, and (d) the system resource that is attacked. That characterization agrees with the definitions in this Glossary (see: diagram under "attack").
一般的な基準は、（a）脅威エージェント、（b）推定方法、（c）攻撃の基盤である脆弱性、攻撃された脆弱性、（d）攻撃された脅威、（d）攻撃された脅威の脅威、（d）攻撃されたシステムリソース。その特徴付けはこの用語集の定義と一致しています（「攻撃」の下にある図を参照）。
2. (O) The technical and operational ability of a hostile entity to detect, exploit, or subvert a friendly system and the demonstrated, presumed, or inferred intent of that entity to conduct such activity.
2. （O）その企業のその企業の意図をその企業の意図を検出、悪用、または縮退、推定、または推測することの意図をその企業の意図を検出、悪用、または縮退させる技術能力および運用能力。
Tutorial: To be likely to launch an attack, an adversary must have (a) a motive to attack, (b) a method or technical ability to make the attack, and (c) an opportunity to appropriately access the targeted system.
チュートリアル：攻撃を開始する可能性が高いため、（a）攻撃を動かす動機、（b）攻撃を行う方法または技術的能力、および（c）ターゲティングシステムに適切にアクセスする機会を持っている必要があります。
3. (D) "An indication of an impending undesirable event." [Park]
3. （d）「差し迫った望ましくないイベントの表示」[パーク]
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 3 because the definition is ambiguous; the definition was intended to include the following three meanings:
定義廃止された定義：定義があいまいであるため、IDocは定義3でこの用語を使用しないでください。定義は以下の3つの意味を含むことを意図していた。
- "Potential threat": A possible security violation; i.e., the same as definition 1. - "Active threat": An expression of intent to violate security. (Context usually distinguishes this meaning from the previous one.) - "Accomplished threat" or "actualized threat": That is, a threat action. Deprecated Usage: IDOCs SHOULD NOT use the term "threat" with this meaning; instead, use "threat action".
- 「潜在的な脅威」：可能なセキュリティ違反。すなわち、定義1. - 「積極的な脅威」：セキュリティに違反する意図の表現。（文脈は通常この意味を前のものと区別します。） - 「達成された脅威」または「実際の脅威」：つまり脅威の対応。廃止予定の使用法：IDocsは、この意味で「脅威」という用語を使用しないでください。代わりに、「脅威の処置」を使用してください。
$ threat action (I) A realization of a threat, i.e., an occurrence in which system security is assaulted as the result of either an accidental event or an intentional act. (See: attack, threat, threat consequence.)
$ 脅威の行動（i）脅威の実現、すなわちシステムセキュリティが偶発的なイベントまたは意図的な行為の結果として攻撃される出現。（攻撃、脅威、脅威の結果を参照してください。）
Tutorial: A complete security architecture deals with both intentional acts (i.e., attacks) and accidental events [FP031]. (See: various kinds of threat actions defined under the four kinds of "threat consequence".)
チュートリアル：完全なセキュリティアーキテクチャは、意図的な行為（すなわち攻撃）と偶発的なイベントの両方を扱う[FP031]。（参照：4種類の「脅威の結果」で定義されたさまざまな種類の脅威行動）。）
$ threat agent (I) A system entity that performs a threat action, or an event that results in a threat action.
$ Threat Agent（i）脅威アクション、または脅威アクションをもたらすイベントを実行するシステムエンティティ。
$ threat analysis (I) An analysis of the threat actions that might affect a system, primarily emphasizing their probability of occurrence but also considering their resulting threat consequences. Example: RFC 3833. (Compare: risk analysis.)
$ 脅威分析（i）システムに影響を与える可能性がある脅威行動の分析は、主に発生の可能性が強調されているが、その結果として生じる脅威の影響を検討しています。例：RFC 3833.（比較：リスク分析）
$ threat consequence (I) A security violation that results from a threat action.
$ 脅威の結果（i）脅威の行動から生じるセキュリティ違反。
Tutorial: The four basic types of threat consequence are "unauthorized disclosure", "deception", "disruption", and "usurpation". (See main Glossary entries of each of these four terms for lists of the types of threat actions that can result in these consequences.)
チュートリアル：4つの基本的な種類の脅威の結果は、「不正な開示」、「詐欺」、「中断」、および「USURPATION」です。（これらの結果をもたらす可能性がある脅威の種類のリストについては、これらの4つの項の主要な用語集エントリを参照してください。）
$ thumbprint 1. (I) A pattern of curves formed by the ridges on the tip of a thumb. (See: biometric authentication, fingerprint.)
$ Thumbprint 1.（i）親指の先端の尾根によって形成された曲線のパターン。（参照：バイオメトリック認証、指紋）
2. (D) Synonym for some type of "hash result". (See: biometric authentication. Compare: fingerprint.)
2. （d）ある種の「ハッシュ結果」の同義語。（バイオメトリック認証を参照してください。比較：指紋）
Deprecated Usage: IDOCs SHOULD NOT use this term with definition 2 because that meaning mixes concepts in a potentially misleading way.
廃止予定の使用法：IDocは定義2でこの用語を使用しないでください。
$ ticket (I) Synonym for "capability token".
$ チケット（i）「機能トークン」の同義語。
Tutorial: A ticket is usually granted by a centralized access control server (ticket-granting agent) to authorize access to a system resource for a limited time. Tickets can be implemented with either symmetric cryptography (see: Kerberos) or asymmetric cryptography (see: attribute certificate).
チュートリアル：通常、システムリソースへのアクセスを期間限定で承認するための集中型アクセス制御サーバー（チケット付与エージェント）によって認可されます。チケットは、対称暗号化（kerberos）または非対称暗号化のどちらかで実装できます（属性証明書を参照）。
$ tiger team (O) A group of evaluators employed by a system's managers to perform penetration tests on the system.
$ Tiger Team（O）システム管理者がシステム上で侵入テストを実行するために雇用されている評価者のグループ。
Deprecated Usage: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under "Green Book".)
廃止予定の使用法：他の文化がこの概念に異なる比喩を使用する可能性があります。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。（「グリーンブック」の「廃止予定の使用」。）
$ time stamp 1. (I) /noun/ With respect to a data object, a label or marking in which is recorded the time (time of day or other instant of elapsed time) at which the label or marking was affixed to the data object. (See: Time-Stamp Protocol.)
$ タイムスタンプ1.（i）/名詞/データオブジェクトの場合、ラベルまたはマーキングがデータオブジェクトに添付された時間（経過時間の時刻またはその他の瞬間）を記録されているラベルまたはマーキング。（タイムスタンププロトコルを参照してください。）
2. (O) /noun/ "With respect to a recorded network event, a data field in which is recorded the time (time of day or other instant of elapsed time) at which the event took place." [A1523]
2. （O）/名詞/「記録されたネットワークイベントに関して、イベントが発生した時間（経過時間の経過時間またはその他の瞬間）を記録されているデータフィールド。[A1523]
Tutorial: A time stamp can be used as evidence to prove that a data object existed (or that an event occurred) at or before a particular time. For example, a time stamp might be used to prove that a digital signature based on a private key was created while the corresponding public-key certificate was valid, i.e., before the certificate either expired or was revoked. Establishing this proof would enable the certificate to be used after its expiration or revocation, to verify a signature that was created earlier. This kind of proof is required as part of implementing PKI services, such as non-repudiation service, and long-term security services, such as audit.
チュートリアル：タイムスタンプは、特定の時間以前にデータオブジェクトが存在していることを証明する証拠として使用できます。たとえば、タイムスタンプを使用して、対応する公開鍵証明書が有効な、すなわち証明書が失効したか失効された前に、秘密鍵に基づくデジタル署名が作成されたことを証明することができます。この証明を確立することで、早期に作成された署名を検証するために、証明書を有効期限または失効後に使用することができます。このような証明は、否認防止サービス、および監査などの長期的なセキュリティサービスなどのPKIサービスを実施する部分として必要です。
$ Time-Stamp Protocol (I) An Internet protocol (RFC 3161) that specifies how a client requests and receives a time stamp from a server for a data object held by the client.
$ タイムスタンププロトコル（i）クライアントがクライアントが保持するデータオブジェクトのためにサーバーからタイムスタンプを要求して受信する方法を指定するインターネットプロトコル（RFC 3161）。
Tutorial: The protocol describes the format of (a) a request sent to a time-stamp authority and (b) the response that is returned containing a time stamp. The authority creates the stamp by concatenating (a) a hash value of the input data object with (b) a UTC time value and other parameters (policy OID, serial number, indication of time accuracy, nonce, DN of the authority, and various extensions), and then signing that dataset with the authority's private key as specified in CMS. Such an authority typically would operate as a trusted third-party service, but other operational models might be used.
チュートリアル：プロトコルは、タイムスタンプ権限に送信された要求の形式を記述し、（b）タイムスタンプを含む応答を返します。この権限は、（a）入力データオブジェクトのハッシュ値（a）を（b）UTCの時間値および他のパラメータ（ポリシーOID、シリアル番号、時間の正確さの時間の正確さの表示、権限の無数、DN、およびさまざまなもの）を連結することによってスタンプを作成します。Extensions）、そしてそのデータセットにCMSで指定されているようにそのデータセットに署名します。そのような権限は通常、信頼できるサードパーティのサービスとして動作するでしょうが、他の運用モデルが使用される可能性があります。
$ timing channel (I) See: covert timing channel.
$ タイミングチャネル（i）Covert Timing Channelを参照してください。
$ TKEY (I) A mnemonic referring to an Internet protocol (RFC 2930) for establishing a shared secret key between a DNS resolver and a DNS name server. (See: TSIG.)
$ TKEY（i）DNSリゾルバとDNSネームサーバ間の共有秘密鍵を確立するためのインターネットプロトコル（RFC 2930）を参照するニーモニック。（：Tsig。）
$ TLS (I) See: Transport Layer Security.
$ TLS（i）：トランスポート層のセキュリティを参照してください。
$ TLSP (N) See: Transport Layer Security Protocol.
$ TLSP（n）：トランスポート層セキュリティプロトコルを参照してください。
$ TOE (N) See: target of evaluation.
$ TOE（N）は評価の対象を参照してください。
$ token 1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.)
$ トークン1.（i）/暗号化/参照：暗号化トークン。（比較：ドングル）
2. (I) /access control/ An object that is used to control access and is passed between cooperating entities in a protocol that synchronizes use of a shared resource. Usually, the entity that currently holds the token has exclusive access to the resource. (See: capability token.)
2. （i）/アクセス制御/アクセスを制御するために使用され、共有リソースの使用を同期させるプロトコル内の協調エンティティ間で渡されるオブジェクト。通常、現在トークンを保持しているエンティティにはリソースへの排他的アクセスがあります。（能力トークンを参照してください。）
Usage: This term is heavily overloaded in the computing literature; therefore, IDOCs SHOULD NOT use this term with any definition other than 1 or 2.
使用法：この用語はコンピューティングの文献に大きく過負荷になっています。したがって、IDocは1または2以外の定義でこの用語を使用しないでください。
3a. (D) /authentication/ A data object or a physical device used to verify an identity in an authentication process.
3A。（D）/認証/データオブジェクトまたは認証プロセスにおける識別情報を検証するために使用される物理デバイス。
3b. (D) /U.S. Government/ Something that the claimant in an authentication process (i.e., the entity that claims an identity) possesses and controls, and uses to prove the claim during the verification step of the process. [SP63]
3b。（d）/u.S。政府/認証プロセスにおける請求者（すなわち、身元を主張する企業）は、プロセスの検証ステップの間にクレームを証明するために使用するために使用する。[SP63]
Deprecated usage: IDOCs SHOULD NOT use this term with definitions 3a and 3b; instead, use more specifically descriptive and informative terms such as "authentication information" or "cryptographic token", depending on what is meant.
廃止予定の使用法：IDOCは定義3Aおよび3Bでこの用語を使用しないでください。代わりに、何を意味するのかに応じて、「認証情報」や「暗号トークン」などのより具体的に説明的で報知的な用語を使用してください。
NIST defines four types of claimant tokens for electronic authentication in an information system [SP63]. IDOCs SHOULD NOT use these four NIST terms; they mix concepts in potentially confusing ways and duplicate the meaning of better-established terms. These four terms can be avoided by using more specifically descriptive terms as follows: - NIST "hard token": A hardware device that contains a protected cryptographic key. (This is a type of "cryptographic token", and the key is a type of "authentication information".) - NIST "one-time password device token": A personal hardware device that generates one-time passwords. (One-time passwords are typically generated cryptographically. Therefore, this is a type of "cryptographic token", and the key is a type of "authentication information".) - NIST "soft token": A cryptographic key that typically is stored on disk or some other magnetic media. (The key is a type of "authentication information"; "authentication key" would be a better description.) - NIST "password token": A secret data value that the claimant memorizes. (This is a "password" that is being used as "authentication information".)
NISTは、情報システムでの電子認証のための4種類の請求トークンを定義しています[SP63]。 IDOCはこれら4つのNIST用語を使用しないでください。彼らは潜在的に混乱している方法で概念を混ぜ合わせ、そしてより良い確立された用語の意味を複製します。これら4つの用語は、以下のようにより具体的に説明的な用語を使用することによって回避することができます。 - NIST "ハードトークン"：保護された暗号鍵を含むハードウェアデバイス。 （これは「暗号化トークンの一種」であり、キーは「認証情報」の一種です。） - NIST「ワンタイムパスワードデバイストークン」：ワンタイムパスワードを生成するパーソナルハードウェアデバイス。 （ワンタイムパスワードは通常暗号的に生成されます。したがって、これは「暗号化トークン」の種類であり、そのキーは「認証情報」の一種である。） - NIST「ソフトトークン」：通常格納されている暗号鍵ディスクまたは他の磁気媒体。 （鍵は「認証情報」の一種です。「認証キー」はより良い説明になります。） - NIST「パスワードトークン」：請求者が記憶する秘密データ値。 （これは認証情報 "として使用されている「パスワード」です。）
$ token backup (I) A token management operation that stores sufficient information in a database (e.g., in a CAW) to recreate or restore a security token (e.g., a smart card) if it is lost or damaged.
$ トークンバックアップ（i）データベース内に十分な情報（たとえば、CAW内で）を格納して、それが紛失または損傷している場合にはセキュリティトークン（例えばスマートカード）を再作成または復元するためのトークン管理操作。
$ token copy (I) A token management operation that copies all the personality information from one security token to another. However, unlike in a token restore operation, the second token is initialized with its own, different local security values such as PINs and storage keys.
$ トークン・コピー（i）すべての個性情報をあるセキュリティ・トークンから別のセキュリティー・トークンにコピーするトークン管理操作。ただし、トークンの復元操作とは異なり、2番目のトークンは、ピンやストレージキーなどの独自の異なるローカルセキュリティ値で初期化されます。
$ token management (I) The process that includes initializing security tokens (e.g., "smart card"), loading data into the tokens, and controlling the tokens during their lifecycle. May include performing key management and certificate management functions; generating and installing PINs; loading user personality data; performing card backup, card copy, and card restore operations; and updating firmware.
$ トークン管理（i）セキュリティトークンの初期化（例えば、「スマートカード」）、トークンにデータをロードし、それらのライフサイクル中にトークンを制御することを含むプロセス。鍵管理および証明書管理機能を実行することを含み得る。ピンの生成とインストールユーザーパーソナリティデータをロードする。カードのバックアップ、カードのコピー、およびカードの復元操作の実行。ファームウェアを更新する。
$ token restore (I) A token management operation that loads a security token with data for the purpose of recreating (duplicating) the contents previously held by that or another token. (See: recovery.)
$ トークンの復元（i）以前に保持されている内容を再作成（複製）したことを目的として、セキュリティトークンをロードするトークン管理操作。（回復を参照してください。）
$ token storage key (I) A cryptographic key used to protect data that is stored on a security token.
$ トークンストレージキー（i）セキュリティトークンに保存されているデータを保護するために使用される暗号化キー。
$ top CA (I) Synonym for "root" in a certification hierarchy. (See: apex trust anchor.)
$ TOP CA（i）認証階層内の「root」の同義語。（参照：Apex Trust Anchor。）
$ top-level specification (I) "A non-procedural description of system behavior at the most abstract level; typically a functional specification that omits all implementation details." [NCS04] (See: formal top-level specification, Tutorial under "security policy".)
$ 最上位仕様（i）「最も抽象レベルでのシステム動作の非手続き的な説明。通常、すべての実装の詳細を省略する機能仕様」。[NCS04]（参照：正式なトップレベルの仕様、「セキュリティポリシー」の下にあるチュートリアル。）
Tutorial: A top-level specification is at a level of abstraction below "security model" and above "security architecture" (see: Tutorial under "security policy").
チュートリアル：最上位の仕様は、「セキュリティモデル」および「セキュリティアーキテクチャ」を下回る抽象化レベルにあります（「セキュリティポリシー」の下のチュートリアル）。
A top-level specification may be descriptive or formal: - "Descriptive top-level specification": One that is written in a natural language like English or an informal design notation. - "Formal top-level specification": One that is written in a formal mathematical language to enable theorems to be proven that show that the specification correctly implements a set of formal requirements or a formal security model. (See: correctness proof.)
最上位の仕様は、説明的または正式なものであり得る - 「説明的なトップレベル仕様」：英語のような自然言語で書かれているもの、または非公式の設計表記法。 - 「フォーマルトップレベル仕様」：正式な数学的言語で書かれているものは、仕様が正しく正式な要件または正式なセキュリティモデルを正しく実装することを示すことを証明することを証明するものです。（参照：正確性証明）
$ TPM (N) See: Trusted Platform Module.
$ TPM（N）：信頼できるプラットフォームモジュール。
$ traceback (I) Identification of the source of a data packet. (See: masquerade, network weaving.)
$ トレースバック（i）データパケットのソースの識別。（：マスカレード、ネットワーク織機。）
$ tracker (N) An attack technique for achieving unauthorized disclosure from a statistical database. [Denns] (See: Tutorial under "inference control".)
$ Tracker（N）統計データベースから不正な開示を達成するための攻撃技術。[Denns]（「推論コントロール」の下にあるチュートリアルを参照してください。）
$ traffic analysis 1. (I) Gaining knowledge of information by inference from observable characteristics of a data flow, even if the information is not directly available (e.g., when the data is encrypted).
$ トラフィック分析1.（i）情報が直接利用可能ではない（例えば、データが暗号化されている場合）、データフローの観察可能な特性からの推論による情報の知識を得る。
These characteristics include the identities and locations of the source(s) and destination(s) of the flow, and the flow's presence, amount, frequency, and duration of occurrence. The object of the analysis might be information in SDUs, information in the PCI, or both. (See: inference, traffic-flow confidentiality, wiretapping. Compare: signal analysis.)
これらの特性には、流れの識別情報と場所と、流れの存在場所と、流れの存在、量、頻度、および発生期間が含まれます。分析の目的は、SDU、PCI内の情報、またはその両方の情報であり得る。（参照：推論、トラフィックフロー機密性、盗聴。比較：信号解析）
2. (O) "The inference of information from observation of traffic flows (presence, absence, amount, direction, and frequency)." [I7498-2]
2. （O） "交通流の観測からの情報の推論（存在、不在、量、方向、周波数）。」[I7498-2]
$ traffic-flow analysis (I) Synonym for "traffic analysis".
$ トラフィックフロー分析（i）「トラフィック分析」の同義語。
$ traffic-flow confidentiality (TFC) 1. (I) A data confidentiality service to protect against traffic analysis. (See: communications cover.)
$ トラフィックフロー機密性（TFC）1.（i）交通分析から保護するためのデータ機密性サービス。（参照：通信カバー。）
2. (O) "A confidentiality service to protect against traffic analysis." [I7498-2]
2. （O）「交通分析から保護するための機密性サービス」[I7498-2]
Tutorial: Confidentiality concerns involve both direct and indirect disclosure of data, and the latter includes traffic analysis. However, operational considerations can make TFC difficult to achieve. For example, if Alice sends a product idea to Bob in an email message, she wants data confidentiality for the message's content, and she might also want to conceal the destination of the message to hide Bob's identity from her competitors. However, the identity of the intended recipient, or at least a network address for that recipient, needs to be made available to the mail system. Thus, complex forwarding schemes may be needed to conceal the ultimate destination as the message travels through the open Internet (see: onion routing).
チュートリアル：機密性の懸念は、直接的および間接的なデータの開示の両方を含み、後者はトラフィック分析を含みます。しかしながら、運用上の考慮事項はTFCを達成するのが難しくなる可能性がある。たとえば、Aliceが電子メールメッセージ内のBobに製品のアイデアを送信する場合、彼女はメッセージの内容のためのデータの機密性を望んでいます、そして、彼女は彼女の競合他社からボブのアイデンティティを隠すためにメッセージの宛先を隠したいと思うかもしれません。しかしながら、意図された受信者のアイデンティティ、またはその受信者のためのネットワークアドレスは、メールシステムに利用可能にする必要がある。したがって、メッセージがオープンインターネットを通過するときに究極の宛先を隠すために複雑な転送方式が必要とされるかもしれない（玉石ルーティング参照）。
Later, if Alice uses an ATM during a clandestine visit to negotiate with Bob, she might prefer that her bank conceal the origin of her transaction, because knowledge of the ATM's location might allow a competitor to infer Bob's identity. The bank, on the other hand, might prefer to protect only Alice's PIN (see: selective-field confidentiality).
後で、AliceがBobと交渉することを訪問している間にATMを使用すると、彼女の銀行が彼女の取引の起源を隠すことを好むかもしれません。一方、銀行は、Aliceのピンのみを保護することを好むかもしれません（選択フィールドの機密性を参照）。
A TFC service can be either full or partial: - "Full TFC": This type of service conceals all traffic characteristics. - "Partial TFC": This type of service either (a) conceals some but not all of the characteristics or (b) does not completely conceal some characteristic.
TFCサービスは完全または部分的なものにすることができます。 - "full tfc"：このタイプのサービスはすべてのトラフィック特性を隠します。 - 「部分TFC」：このタイプのサービス（A）のいずれかを隠していますが、すべての特性や（b）が完全に隠されないものをすべて隠します。
On point-to-point data links, full TFC can be provided by enciphering all PDUs and also generating a continuous, random data stream to seamlessly fill all gaps between PDUs. To a wiretapper, the link then appears to be carrying an unbroken stream of enciphered data. In other cases -- including on a shared or broadcast medium, or end-to-end in a network -- only partial TFC is possible, and that may require a combination of techniques. For example, a LAN that uses "carrier sense multiple access with collision detection" (CSMA/CD; a.k.a. "listen while talk") to control access to the medium, relies on detecting intervals of silence, which prevents using full TFC. Partial TFC can be provided on that LAN by measures such as adding spurious PDUs, padding PDUs to a constant size, or enciphering addresses just above the Physical Layer; but these measures reduce the efficiency with which the LAN can carry traffic. At higher protocol layers, SDUs can be protected, but addresses and other items of PCI must be visible at the layers below.
ポイントツーポイントデータリンクでは、すべてのPDUを暗断したり、PDU間のすべてのギャップをシームレスに埋めるための連続的なランダムなデータ・ストリームを生成することで、フルTFCを提供できます。ワイヤポーパーに、リンクは暗号化されていないデータの解明されていないストリームを持ち運ぶようです。他の場合には、共有媒体または放送媒体を含め、ネットワーク内のエンドツーエンドの部分TFCが可能であり、それは技術の組み合わせを必要とするかもしれない。例えば、媒体へのアクセスを制御するために、媒体へのアクセスを制御するために、完全なTFCの使用を検出することに依存して、沈黙の間隔を検出することに依存する。部分TFCは、スプリアスPDU、パディングPDUを一定サイズに追加するなどの測定値、または物理層の真上の暗号化アドレスなど、そのLANに提供することができる。しかし、これらの対策は、LANがトラフィックを携帯できる効率を低下させます。より高いプロトコルレイヤでは、SDUを保護することができますが、アドレスやその他のPCIは下のレイヤーに表示されなければなりません。
$ traffic key (I) A cryptographic key used by a device for protecting information that is being transmitted between devices, as opposed to protecting information that being is maintained in the device. (Compare: storage key.)
$ トラフィックキー（i）デバイス間で送信されている情報を保護している情報を保護するための装置によって使用される暗号鍵。（比較：ストレージキー。）
$ traffic padding (I) "The generation of spurious instances of communication, spurious data units, and/or spurious data within data units." [I7498-2]
$ トラフィックパディング（I）「通信のスプリアスインスタンス、スプリアスデータユニット、および/またはデータユニット内のスプリアスデータの生成」[I7498-2]
$ tranquility property (N) /formal model/ Property of a system whereby the security level of an object cannot change while the object is being processed by the system. (See: Bell-LaPadula model.)
$ 静止性プロパティ（n）/正式なモデル/オブジェクトのセキュリティレベルがシステムによって処理されている間に変更できません。（鐘ラップラドゥラモデルを参照）
$ transaction 1. (I) A unit of interaction between an external entity and a system, or between components within a system, that involves a series of system actions or events.
$ トランザクション1.（i）外部エンティティとシステムとの間の相互作用単位、またはシステム内のコンポーネント間の相互作用単位、一連のシステムの行動またはイベントを含む。
2. (O) "A discrete event between user and systems that supports a business or programmatic purpose." [M0404]
2. （O）「ビジネスまたはプログラムの目的をサポートするユーザーとシステム間の離散的なイベント」[M0404]
Tutorial: To maintain secure state, transactions need to be processed coherently and reliably. Usually, they need to be designed to be atomic, consistent, isolated, and durable [Gray]: - "Atomic": All actions and events that comprise the transaction are guaranteed to be completed successfully, or else the result is as if none at all were executed.
チュートリアル：安全な状態を維持するために、トランザクションはコヒーレントにかつ確実に処理される必要があります。通常、それらはアトミック、一貫性、分離された、そして耐久性のある[灰色]になるように設計される必要があります。 - 「アトミック」：トランザクションを構成するすべてのアクションとイベントは正常に完了することが保証されています。すべて実行されました。
- "Consistent": The transaction satisfies correctness constraints defined for the data that is being processed. - "Isolated": If two transactions are performed concurrently, they do not interfere with each other, and it appears as though the system performs one at a time. - "Durable": System state and transaction semantics survive system failures.
- 「一貫した」：トランザクションは、処理中のデータに対して定義された正当性制約を満たします。 - 「分離」：2つのトランザクションが同時に実行されている場合、それらは互いに干渉しないように、システムが一度に1つずつ実行されます。 - 「耐久性」：システム状態と取引セマンティクスはシステムの失敗を介して生き残ります。
$ TRANSEC (I) See: transmission security.
$ Transec（i）送信セキュリティを参照してください。
$ Transmission Control Code field (TCC field) (I) A data field that provides a means to segregate traffic and define controlled communities of interest in the security option (option type = 130) of IPv4's datagram header format. The TCC values are alphanumeric trigraphs assigned by the U.S. Government as specified in RFC 791.
$ 送信制御コードフィールド（TCCフィールド）（i）トラフィックを分離するための手段を提供し、IPv4のデータグラムヘッダフォーマットのセキュリティオプション（オプションタイプ= 130）に関心のある制御コミュニティ（オプションタイプ= 130）を定義するための手段を提供するデータフィールド。TCC値は、RFC 791で指定されているように、米国政府によって割り当てられた英数字の三角形です。
$ Transmission Control Protocol (TCP) (I) An Internet Standard, Transport-Layer protocol (RFC 793) that reliably delivers a sequence of datagrams from one computer to another in a computer network. (See: TCP/IP.)
$ 伝送制御プロトコル（TCP）（i）コンピュータネットワーク内の1つのコンピュータから別のコンピュータ間で一連のデータグラムを確実に配信するインターネット規格のトランスポート層プロトコル（RFC 793）。（：TCP / IPを参照）
Tutorial: TCP is designed to fit into a layered suite of protocols that support internetwork applications. TCP assumes it can obtain a simple but potentially unreliable end-to-end datagram service (such as IP) from the lower-layer protocols.
チュートリアル：TCPは、インターネットワークアプリケーションをサポートする階層化されたプロトコルのスイートに収まるように設計されています。TCPは、より低層レイヤプロトコルからの単純だが信頼性が低いエンドツーエンドのデータグラムサービス（IPなど）を取得できると想定しています。
$ transmission security (TRANSEC) (I) COMSEC measures that protect communications from interception and exploitation by means other than cryptanalysis. Example: frequency hopping. (Compare: anti-jam, traffic flow confidentiality.)
$ 伝送セキュリティ（Transmec）（i）暗号化以外の手段による傍受と搾取からの通信を保護するCOMSECメジャー。例：周波数ホッピング。（比較：アンチジャム、トラフィックフロー機密性。）
$ Transport Layer See: Internet Protocol Suite, OSIRM.
$ トランスポートレイヤーはインターネットプロトコルスイート、OSIRMを参照してください。
$ Transport Layer Security (TLS) (I) TLS is an Internet protocol [R4346] that is based on, and very similar to, SSL Version 3.0. (Compare: TLSP.)
$ トランスポートレイヤセキュリティ（TLS）（I）TLSは、SSLバージョン3.0に基づく、そして非常に似たInternet Protocol [R4346]です。（比較：TLSP）
Tutorial: The TLS protocol is misnamed. The name misleadingly suggests that TLS is situated in the IPS Transport Layer, but TLS is always layered above a reliable Transport-Layer protocol (usually TCP) and either layered immediately below or integrated with an Application-Layer protocol (often HTTP).
チュートリアル：TLSプロトコルは誤解されています。TLSがIPSトランスポート層にあることを誤解して示唆しているが、TLSは常に信頼性のあるトランスポート層プロトコル（通常はTCP）の上に階層化され、階層化され、すぐ下のレイヤードまたはアプリケーション層プロトコル（頻繁にHTTP）と統合されている。
$ Transport Layer Security Protocol (TLSP) (N) An end-to-end encryption protocol (ISO 10736) that provides security services at the bottom of OSIRM Layer 4, i.e., directly above Layer 3. (Compare: TLS.)
$ トランスポートレイヤセキュリティプロトコル（TLSP）（N）osirmレイヤ4の下部、すなわちレイヤ3の直下でセキュリティサービスを提供するエンドツーエンド暗号化プロトコル（ISO10736）。
Tutorial: TLSP evolved directly from SP4.
チュートリアル：TLSPはSP4から直接進化しました。
$ transport mode (I) One of two ways to apply AH or ESP to protect data packets; in this mode, the IPsec protocol encapsulates (i.e., the protection applies to) the packets of an IPS Transport-Layer protocol (e.g., TCP, UDP), which normally is carried directly above IP in an IPS protocol stack. (Compare: tunnel mode.)
$ トランスポートモード（i）データパケットを保護するためにAHまたはESPを適用するための2つの方法のうちの1つ。このモードでは、IPSecプロトコルは、IPSトランスポート層プロトコル（例えば、TCP、UDP）のパケットをカプセル化する（すなわち、保護が適用される）、通常はIPSプロトコルスタックでIPの直上で伝送される。（比較：トンネルモード。）
Tutorial: An IPsec transport-mode security association is always between two hosts; neither end has the role of a security gateway. Whenever either end of an IPsec security association is a security gateway, the association is required to be in tunnel mode.
チュートリアル：IPsecトランスポートモードセキュリティアソシエーションは常に2つのホスト間です。どちらの端もセキュリティゲートウェイの役割を持っていません。IPsecセキュリティアソシエーションのどちらか終了がセキュリティゲートウェイである場合は、関連付けがトンネルモードにあることが必要です。
$ transposition (I) /cryptography/ A method of encryption in which elements of the plain text retain their original form but undergo some change in their sequential position. (Compare: substitution.)
$ 転置（I）/暗号化/プレーンテキストの要素が元の形式を保持するが、それらの連続位置にいくらかの変化を受ける暗号化の方法。（比較：代替品）
$ trap door (I) Synonym for "back door".
$ 罠ドア（i）「バックドア」の同義語。
$ trespass (I) /threat action/ See: secondary definition under "intrusion".
$ TRESPASS（I）/脅威対応/参照：「侵入」の下の二次定義。
$ Triple Data Encryption Algorithm (I) A block cipher that transforms each 64-bit plaintext block by applying the DEA three successive times, using either two or three different keys for an effective key length of 112 or 168 bits. [A9052, SP67]
$ トリプルデータ暗号化アルゴリズム（i）112または168ビットの有効キー長の2つまたは3つの異なるキーのいずれかを使用して、DEA 3の連続した回数を適用することによって、各64ビット平文ブロックを変換するブロック暗号です。[A9052、SP67]
Example: A variation proposed for IPsec's ESP uses a 168-bit key, consisting of three independent 56-bit values used by the DEA, and a 64-bit initialization vector. Each datagram contains an IV to ensure that each received datagram can be decrypted even when other datagrams are dropped or a sequence of datagrams is reordered in transit. [R1851]
例：IPsecのESPのために提案されている変動は、DEAによって使用される3つの独立した56ビット値、および64ビットの初期化ベクトルからなる168ビットキーを使用します。各データグラムには、他のデータグラムがドロップされている場合でも各受信データグラムを復号化できるようにするためのIVを含みます。[R1851]
$ triple-wrapped (I) /S-MIME/ Data that has been signed with a digital signature, then encrypted, and then signed again. [R2634]
$ デジタル署名で署名されたトリプルラップ（i）/ S-MIME /データは、暗号化されてから再度署名されます。[R2634]
$ Trojan horse (I) A computer program that appears to have a useful function, but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes the program. (See: malware, spyware. Compare: logic bomb, virus, worm.)
$ Trojan Horse（i）役立つ機能を持つように見えるコンピュータプログラムでも、プログラムを呼び出すシステムエンティティの正当な権限を悪用することによって、セキュリティメカニズムを回避する隠された潜在的に悪意のある機能もあります。（：マルウェア、スパイウェア。比較：ロジック爆弾、ウイルス、ワーム。）
$ trust 1. (I) /information system/ A feeling of certainty (sometimes based on inconclusive evidence) either (a) that the system will not fail or (b) that the system meets its specifications (i.e., the system does what it claims to do and does not perform unwanted functions). (See: trust level, trusted system, trustworthy system. Compare: assurance.)
$ 信頼1.（i）/情報システム/確実性感（決定していない証拠に基づくことがあります）システムが失敗しないか（b）システムがその仕様を満たしていない（すなわち、システムはそれが主張するものです。やるべきこと、そして不要な機能を実行しません）。（「信託レベル、信頼できるシステム、信頼できるシステム。比較：保証。）
Tutorial: Components of a system can be grouped into three classes of trust [Gass]: - "Trusted": The component is responsible for enforcing security policy on other components; the system's security depends on flawless operation of the component. (See: trusted process.) - "Benign": The component is not responsible for enforcing security policy, but it has sensitive authorizations. It must be trusted not to intentionally violate security policy, but security violations are assumed to be accidental and not likely to affect overall system security. - "Untrusted": The component is of unknown or suspicious provenance and must be treated as deliberately malicious. (See: malicious logic.)
チュートリアル：システムのコンポーネントは3つのクラスの信頼[GASS]にグループ化できます。 - "Trusted"：コンポーネントは他のコンポーネントでセキュリティポリシーを強制する責任があります。システムのセキュリティは、コンポーネントの完璧な動作によって異なります。（信頼されたプロセス。） - "Benign"：コンポーネントはセキュリティポリシーを強制する責任を負いませんが、それは敏感な承認を持っています。意図的にセキュリティポリシーに違反しないように信頼されている必要がありますが、セキュリティ違反は偶発的であり、システム全体のセキュリティに影響を与える可能性が低いと見なされます。 - 「信頼されていない」：コンポーネントは不明または疑わしい起源のものであり、故意に悪意のあるものとして扱われなければなりません。（悪意のある論理を参照してください。）
2. (I) /PKI/ A relationship between a certificate user and a CA in which the user acts according to the assumption that the CA creates only valid digital certificates.
2. （i）/ PKI / PKI / A CAが有効なデジタル証明書のみを作成するという仮定に従って、ユーザが機能するCAの関係。
Tutorial: "Generally, an entity is said to 'trust' a second entity when the first entity makes the assumption that the second entity will behave exactly as the first entity expects. This trust may apply only for some specific function. The key role of trust in [X.509] is to describe the relationship between an entity [i.e., a certificate user] and a [CA]; an entity shall be certain that it can trust the CA to create only valid and reliable certificates." [X509]
チュートリアル： "一般的に、最初のエンティティが最初のエンティティが最初のエンティティが予想されると正確に動作するという仮定を想定したときに、「信頼」と言われています。この信頼は、特定の機能に対してのみ適用される可能性があります。の主な役割[X.509]での信頼は、エンティティ[すなわち証明書ユーザー]と[CA]との関係を説明することです。エンティティは、有効で信頼できる証明書のみを作成するためにCAを信頼できるようにすることを確認するものとします。」[X509]
$ trust anchor (I) /PKI/ An established point of trust (usually based on the authority of some person, office, or organization) from which a certificate user begins the validation of a certification path. (See: apex trust anchor, path validation, trust anchor CA, trust anchor certificate, trust anchor key.) Usage: IDOCs that use this term SHOULD state a definition for it because it is used in various ways in existing IDOCs and other PKI literature. The literature almost always uses this term in a sense that is equivalent to this definition, but usage often differs with regard to what constitutes the point of trust.
$信託アンカー（I）/ PKI /確立された信頼のポイント（通常は、通常、証明書ユーザーが認証パスの検証を開始する一部の人、オフィス、または組織に基づきます）。（参照：Apex Trust Anchor、パス検証、トラストアンカーCA、信頼アンカー証明書、信頼アンカーキー。）使用法：この用語を使用するIDocは、既存のIDOCやその他のPKI文学でさまざまな方法で使用されているため、定義を記載する必要があります。。この文献は、この定義と同等の意味でこの用語をほとんど使用していますが、信頼のポイントを構成するものに関しては使用が異なります。
Tutorial: A trust anchor may be defined as being based on a public key, a CA, a public-key certificate, or some combination or variation of those:
チュートリアル：信頼アンカーは、公開鍵、CA、公開鍵証明書、またはそれらのいくつかの組み合わせまたはバリエーションに基づくものとして定義されることがあります。
- 1. A public key as a point of trust: Although a certification path is defined as beginning with a "sequence of public-key certificates", an implementation of a path validation process might not explicitly handle a root certificate as part of the path, but instead begin the process by using a trusted root key to verify the signature on a certificate that was issued by the root.
- 1.信頼のポイントとしての公開鍵：認証パスは、「公開鍵証明書のシーケンス」で始まると定義されていますが、パス検証プロセスの実装はパスの一部としてルート証明書を明示的に処理しない可能性があります。しかし、代わりに信頼できるルートキーを使用してプロセスを始めて、ルートによって発行された証明書の署名を確認します。
Therefore, "trust anchor" is sometimes defined as just a public key. (See: root key, trust anchor key, trusted key.)
したがって、「信頼アンカー」は単なる公開鍵として定義されることがあります。（参照：ルートキー、トラストアンカーキー、信頼済みキー。）
- 2. A CA as a point of trust: A trusted public key is just one of the data elements needed for path validation; the IPS path validation algorithm [R3280] also needs the name of the CA to which that key belongs, i.e., the DN of the issuer of the first X.509 certificate to be validated on the path. (See: issue.)
- 2.信頼のポイントとしてのCA：信頼できる公開鍵は、パス検証に必要なデータ要素の1つだけです。IPSパス検証アルゴリズム[R3280]はまた、そのキーが属するCAの名前、すなわちパス上で検証される最初のX.509証明書の発行者のDNを必要とする。（発行を参照してください。）
Therefore, "trust anchor" is sometimes defined as either just a CA (where some public key is implied) or as a CA together with a specified public key belonging to that CA. (See: root, trust anchor CA, trusted CA.)
したがって、「信頼アンカー」は、そのCAに属する指定された公開鍵とともに、単なるCA（いくつかの公開鍵が暗示されている場合）またはCAとして定義されることがあります。（参照：root、信頼Anchor CA、信頼されたCA.）
Example: "A public key and the name of a [CA] that is used to validate the first certificate in a sequence of certificates. The trust anchor public key is used to verify the signature on a certificate issued by a trust anchor [CA]." [SP57]
例：1列の証明書の最初の証明書を検証するために使用される公開鍵と[CA]の名前。信託アンカー公開鍵は、信託アンカー[CA]で発行された証明書の署名を検証するために使用されます。。」[SP57]
- 3. A public-key certificate as a point of trust: Besides the trusted CA's public key and name, the path validation algorithm needs to know the digital signature algorithm and any associated parameters with which the public key is used, and also any constraints that have been placed on the set of paths that may be validated using the key. All of this information is available from a CA's public-key certificate.
- 3.信頼のポイントとしての公開鍵証明書：信頼できるCAの公開鍵と名前の他に、パス検証アルゴリズムはデジタル署名アルゴリズムと公開鍵が使用されている関連パラメータ、およびその制約も知られています。キーを使用して検証され得るパスのセットに配置されています。この情報はすべて、CAの公開鍵証明書から入手できます。
Therefore, "trust anchor" is sometimes defined as a public-key certificate of a CA. (See: root certificate, trust anchor certificate, trusted certificate.)
したがって、「信頼アンカー」は、CAの公開鍵証明書として定義されることがあります。（ルート証明書、トラストアンカー証明書、信頼できる証明書を参照してください。）
- 4. Combinations: Combinations and variations of the first three definitions are also used in the PKI literature.
- 4.組み合わせ：最初の3つの定義の組み合わせと変動もPKI文献で使用されています。
Example: "trust anchor information". The IPS standard for path validation [R3280] specifies the information that describes "a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (a) the trusted issuer name, (b) the trusted public key algorithm, (c) the trusted public key, and (d) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. If the trusted public key algorithm requires parameters, then the parameters are provided along with the trusted public key."
例：「トラストアンカー情報」。PATH検証のIPS標準[R3280]は、「認証パスの信頼アンカーとして機能するCAを説明している情報を指定します。信託アンカー情報は次のとおりです。（a）信頼できる公開鍵アルゴリズム。、（c）信頼できる公開鍵、および（d）は、公開鍵に関連した信頼できる公開鍵パラメータを任意選択している。信頼アンカー情報は、自己署名証明書の形で経路処理手順に提供されてもよい。信頼されたAnchor情報は、信頼できる帯域外の手順によってパス処理手順に配信されているため、信頼されています。信頼できる公開鍵アルゴリズムにパラメータが必要な場合は、信頼できる公開鍵とともにパラメータが提供されます。」
$ trust anchor CA (I) A CA that is the subject of a trust anchor certificate or otherwise establishes a trust anchor key. (See: root, trusted CA.)
$ 信頼Anchor CA（i）信頼アンカー証明書の件名であるか、またはその他の方法で信頼アンカーキーを確立したCA。（参照：Root、Trusted Ca.）
Tutorial: The selection of a CA to be a trust anchor is a matter of policy. Some of the possible choices include (a) the top CA in a hierarchical PKI, (b) the CA that issued the verifier's own certificate, or (c) any other CA in a network PKI. Different applications may rely on different trust anchors, or may accept paths that begin with any of a set of trust anchors. The IPS path validation algorithm is the same, regardless of the choice.
チュートリアル：信託アンカーになるCAの選択は、ポリシーの問題です。いくつかの可能な選択肢には、（a）階層PKIの上部CA、（B）検証者自身の証明書を発行したCA、または（C）ネットワークPKI内の他のCAが含まれます。さまざまなアプリケーションは、さまざまな信頼のアンカーに依存しているか、または一連の信頼アンカーのいずれかで始まるパスを受け入れることがあります。選択に関係なく、IPSパス検証アルゴリズムは同じです。
$ trust anchor certificate (I) A public-key certificate that is used to provide the first public key in a certification path. (See: root certificate, trust anchor, trusted certificate.)
$ 信頼Anchor Certificate（i）最初の公開鍵を認証パスに提供するために使用される公開鍵証明書。（ルート証明書、トラストアンカー、信頼できる証明書を参照してください。）
$ trust anchor key (I) A public key that is used as the first public key in a certification path. (See: root key, trust anchor, trusted public key.)
$ Anchorキー（i）認証パスの最初の公開鍵として使用される公開鍵。（参照：ルートキー、トラストアンカー、信頼できる公開鍵）
$ trust anchor information (I) See: secondary definition under "trust anchor".
$ 信頼アンカー情報（i）「信頼アンカー」の下の2次定義を参照してください。
$ trust chain (D) Synonym for "certification path". (See: trust anchor, trusted certificate.) Deprecated Term: IDOCs SHOULD NOT use this term, because it unnecessarily duplicates the meaning of the internationally standardized term.
$ TRUST CHAIN（D）「認証パス」の同義語。廃止予定の用語：IDocは、国際的に標準化された用語の意味を不必要に重複するため、IDOCはこの用語を使用しないでください。
Also, the term mixes concepts in a potentially misleading way. Having "trust" involves factors unrelated to simply verifying signatures and performing other tests as specified by a standard algorithm for path validation (e.g., RFC 3280). Thus, even if a user is able to validate a certification path algorithmically, the user still might distrust one of the CAs that issued certificates in that path or distrust some other aspects of the PKI.
また、この用語は潜在的に誤解を招くような方法でミックスされます。「信頼」を持つことは、パス検証のための標準的なアルゴリズム（例えば、RFC 3280）によって指定されたように、シグネチャを検証し、他のテストを実行することとは無関係の要因を含む。したがって、ユーザが認証パスをアルゴリズム的に検証することができる場合でも、ユーザは、そのパス内に証明書を発行したCASのうちの1つまたはPKIの他のいくつかの側面を依然として不信に不信に不信に不信に不信を示唆している可能性がある。
$ trust-file PKI (I) A non-hierarchical PKI in which each certificate user has its own local file (which is used by application software) of trust anchors, i.e., either public keys or public-key certificates that the user trusts as starting points for certification paths. (See: trust anchor, web of trust. Compare: hierarchical PKI, mesh PKI.)
$ 信頼ファイルPKI（i）各証明書ユーザーが自らのローカルファイル（アプリケーションソフトウェアによって使用されている）、すなわち、ユーザが起動として信頼する公開鍵または公開鍵証明書のいずれかである非階層型PKI認証パスのポイント。（「信託アンカー、信頼のWeb」を参照してください。比較：階層PKI、メッシュPKI）
Example: Popular browsers are distributed with an initial file of trust anchor certificates, which often are self-signed certificates. Users can add certificates to the file or delete from it. The file may be directly managed by the user, or the user's organization may manage it from a centralized server.
例：一般的なブラウザは、信頼アンカー証明書の初期ファイルで配布されているため、自己署名証明書があります。ユーザーはファイルに証明書を追加するか、そこから削除できます。ファイルはユーザによって直接管理されていてもよいし、ユーザの組織はそれを集中サーバから管理することができる。
$ trust hierarchy (D) Synonym for "certification hierarchy".
$ 信頼階層（D）「認定階層」の同義語。
Deprecated Usage: IDOCs SHOULD NOT use this term because it mixes concepts in a potentially misleading way, and because a trust hierarchy could be implemented in other ways. (See: trust, trust chain, web of trust.)
廃止予定の使用法：IDOCは、潜在的に誤解を招く方法で概念を混在させるので、信頼階層を他の方法で実装できるため、この用語を使用しないでください。（信頼、信頼チェーン、信頼のWeb。）
$ trust level (N) A characterization of a standard of security protection to be met by an information system. (See: Common Criteria, TCSEC.)
$ 信頼レベル（n）情報システムによって満たされるべきセキュリティ保護の規格の特性。（以下を参照してください。一般的な基準、TCSEC。）
Tutorial: A trust level is based not only on (a) the presence of security mechanisms, but also on the use of (b) systems engineering discipline to properly structure the system and (c) implementation analysis to ensure that the system provides an appropriate degree of trust.
チュートリアル：信頼レベルは、（a）セキュリティメカニズムの存在だけでなく、システムが適切に提供するようにシステムと（C）実装分析を適切に構成するための（B）システムエンジニアリングの分野の使用にも基づいています。信頼度
$ trusted (I) See: secondary definition under "trust".
$ 信頼された（i）「信頼」の下の2次定義を参照してください。
$ trusted CA (I) A CA upon which a certificate user relies as issuing valid certificates; especially a CA that is used as a trust anchor CA. (See: certification path, root, trust anchor CA, validation.)
$ 信頼できるCA（i）証明書ユーザーが有効な証明書を発行しているように依存するCA。特に信託アンカーCAとして使用されるCA。（認証パス、ルート、信頼Anchor CA、検証。）
Tutorial. This trust is transitive to the extent that the X.509 certificate extensions permit; that is, if a trusted CA issues a certificate to another CA, a user that trusts the first CA also trusts the second CA if the user succeeds in validating the certificate path (see: path validation).
チュートリアル。この信頼は、X.509証明書拡張機能が許可されている範囲で推移的です。つまり、信頼できるCAが他のCAに証明書を発行した場合、最初のCAを信頼するユーザーは、ユーザーが証明書パスの検証に成功した場合も2番目のCAを信頼します（PATH検証を参照）。
$ trusted certificate (I) A digital certificate that a certificate user accepts as being valid "a priori", i.e., without testing the certificate to validate it as the final certificate on a certification path; especially a certificate that is used as a trust anchor certificate. (See: certification path, root certificate, trust anchor certificate, trust-file PKI, validation.)
$ 信頼できる証明書（i）認証パス上の最終証明書として検証するために証明書を検証するための証明書をテストすることなく、証明書ユーザーが有効な「PRISIN」、すなわち証明書をテストすることなく受け入れるデジタル証明書。特に信頼アンカー証明書として使用される証明書。（認証パス、ルート証明書、トラストアンカー証明書、信頼ファイルPKI、検証。）
Tutorial: The acceptance of a certificate as trusted is a matter of policy and choice. Usually, a certificate is accepted as trusted because the user obtained it by reliable, out-of-band means that cause the user to believe the certificate accurately binds its subject's name to the subject's public key or other attribute values. Many choices are possible; e.g., a trusted public-key certificate might be (a) the root certificate in a hierarchical PKI, (b) the certificate of the CA that issued the user's own certificate in a mesh PKI, or (c) a certificate provided with an application that uses a trust-file PKI.
チュートリアル：信頼できる証明書の受け入れは、ポリシーと選択の問題です。通常、証明書は信頼できるものとして受け入れられ、ユーザーは信頼性の高い、帯域外の手段によってそれを取得し、証明書がそのサブジェクトの名前または他の属性値にそのサブジェクトの名前を正確にバインドすると信じることを意味します。多くの選択が可能です。たとえば、信頼できる公開鍵証明書は、（a）階層PKIのルート証明書、（B）メッシュPKIでユーザー自身の証明書を発行したCAの証明書、または（c）アプリケーションに提供された証明書信頼ファイルPKIを使用しています。
$ Trusted Computer System Evaluation Criteria (TCSEC) (N) A standard for evaluating the security provided by operating systems [CSC1, DoD1]. Known as the "Orange Book" because of the color of its cover; first document in the Rainbow Series. (See: Common Criteria, Deprecated Usage under "Green Book", Orange Book, trust level, trusted system. Compare: TSEC.)
$ 信頼できるコンピュータシステム評価基準（TCSEC）（N）オペレーティングシステムによって提供されるセキュリティを評価するための標準[CSC1、DOD1]。その表紙の色のために「オレンジブック」として知られています。レインボーシリーズの最初の文書。（一般的な基準、「グリーンブック」、オレンジブック、信頼レベル、信頼できるシステムの「一般的な使用法」。比較：TSEC。）
Tutorial: The TCSEC defines classes of hierarchically ordered assurance levels for rating computer systems. From highest to lowest, the classes are as follows: - Division A: Verified protection. Beyond A1 Beyond current technology. (See: beyond A1.) Class A1 Verified design. (See: SCOMP.) - Division B: Mandatory protection. Class B3 Security domains. Class B2 Structured protection. (See: Multics.) Class B1 Labeled security protection.
チュートリアル：TCSECは、評価コンピュータシステムのための階層的に順序付けられた保証レベルのクラスを定義します。最高から最も低い、クラスは次のとおりです。 - 分割A：検証済み保護。現在の技術を超えてA1を超えて。（A1を超えて参照）クラスA1検証済みデザイン。（参照：SCOMP） - 部門B：必須保護。クラスB3セキュリティドメイン。クラスB2構造化保護。（マルチス。）クラスB1セキュリティ保護
- Division C: Discretionary protection. Class C2 Controlled access protection. Class C1 Discretionary security protection. - Division D: Minimal protection, i.e., has been evaluated but does not meet the requirements for a higher evaluation class.
- 部門C：任意保護。クラスC2制御アクセス保護クラスC1裁量セキュリティ保護 - 分割D：最小限の保護、すなわち評価されているが、より高い評価クラスの要件を満たしていない。
$ trusted computing base (TCB) (N) "The totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination of which is responsible for enforcing a security policy." [NCS04] (See: "trusted" under "trust". Compare: TPM.)
$ 信頼されたコンピューティングベース（TCB）（TCB）（N） "ハードウェア、ファームウェア、ソフトウェア、ソフトウェアを含むコンピュータシステム内の保護メカニズムの全体性、その組み合わせはセキュリティポリシーを強制する責任があります。」[NCS04]（「信頼」の「信頼できる」。比較：TPM。）
$ Trusted Computing Group (TCG) (N) A not-for-profit, industry standards organization formed to develop, define, and promote open standards for hardware-enabled trusted computing and security technologies, including hardware building blocks and software interfaces, across multiple platforms, peripherals, and devices. (See: TPM, trusted system. Compare: TSIG.)
$ Trusted Computing Group（TCG）（N）ハードウェアビルディングブロックやソフトウェアインタフェースを含むハードウェア対応の信頼できるコンピューティングおよびセキュリティ技術の開発、定義、および宣伝のために形成されていない業界標準の組織は、複数のプラットフォームにまたがっています。、周辺機器、およびデバイス。（TPM、信頼できるシステムを参照してください。比較：Tsig。）
$ trusted distribution (I) /COMPUSEC/ "A trusted method for distributing the TCB hardware, software, and firmware components, both originals and updates, that provides methods for protecting the TCB from modification during distribution and for detection of any changes to the TCB that may occur." [NCS04] (See: code signing, configuration control.)
$ TCBハードウェア、ソフトウェア、およびファームウェアコンポーネントの信頼済み配布（I）/ CompUsec / "TCBハードウェア、ソフトウェア、およびファームウェアコンポーネントを配布するための信頼された方法は、配布中の変更およびTCBへの変更を検出するための方法を提供する方法を提供します。起こるかもしれません。」[NCS04]（コード署名、構成制御を参照）
$ trusted key (D) Abbreviation for "trusted public key" and also for other types of keys. (See: root key, trust anchor key.)
$ 信頼済みキー（D）「信頼できる公開鍵」の略語、およびその他の種類のキーにも省略しています。（参照：Root Key、Trust Anchorキーを参照してください。）
Deprecated Usage: IDOCs SHOULD either (a) state a definition for this term or (b) use a different, less ambiguous term. This term is ambiguous when it stands alone; e.g., it could refer to a trusted public key or to a private key or symmetric key that is believed to be secure (i.e., not compromised).
廃止予定の使用法：IDOCは、（a）この用語の定義を述べていて（b）異なる、あいまいい期間を使用してください。この用語は一人で立っているときにあいまいです。例えば、信頼できる公開鍵または安全性があると考えられる秘密鍵または対称鍵を指すことができる（すなわち、侵害されない）。
$ trusted path 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can communicate directly and reliably with the TCB and that can only be activated by the user or the TCB and cannot be imitated by untrusted software within the computer. [NCS04]
$ 信頼されたパス1a。（i）/ compusec /コンピュータシステムのユーザがTCBと直接的かつ確実に通信できるメカニズムであり、ユーザまたはTCBによってのみ有効にすることができ、コンピュータ内の信頼できないソフトウェアによって模倣することができない。[NCS04]
1b. (I) /COMSEC/ A mechanism by which a person or process can communicate directly with a cryptographic module and that can only be activated by the person, process, or module, and cannot be imitated by untrusted software within the module. [FP140]
1b。（i）/ comsec /人またはプロセスが暗号化モジュールと直接通信できるメカニズム、それは人物、プロセス、またはモジュールによってのみ有効にすることができ、モジュール内の信頼できないソフトウェアによって模倣することができない。[FP140]
$ Trusted Platform Module (TPM) (N) The name of a specification, published by the TCG, for a microcontroller that can store secured information; and also the general name of implementations of that specification. (Compare: TCB.)
$ 信頼できるプラットフォームモジュール（TPM）（n）保護された情報を保存できるマイクロコントローラのためのTCGによって公開された、TCGによって公開された仕様の名前。そしてその仕様の実装の一般名。（比較：TCB。）
$ trusted process (I) A system component that has privileges that enable it to affect the state of system security and that can, therefore, through incorrect or malicious execution, violate the system's security policy. (See: privileged process, trusted system.)
$ 信頼されたプロセス（i）システムセキュリティの状態に影響を与える特権を持つシステムコンポーネント、したがって、誤ったまたは悪意のある実行を通じて、システムのセキュリティポリシーに違反します。（：特権プロセス、信頼できるシステム。）
$ trusted public key (I) A public key upon which a user relies; especially a public key that is used as a trust anchor key. (See: certification path, root key, trust anchor key, validation.)
$ 信頼できる公開鍵（i）ユーザーが頼っている公開鍵。特に信頼アンカーキーとして使用される公開鍵。（認証パス、ルートキー、信頼のアンカーキー、検証。）
Tutorial: A trusted public key could be (a) the root key in a hierarchical PKI, (b) the key of the CA that issued the user's own certificate in a mesh PKI, or (c) any key accepted by the user in a trust-file PKI.
チュートリアル：信頼できる公開鍵は、（a）階層型PKIのルートキー、（b）メッシュPKIでユーザー自身の証明書を発行したCAのキー、または（C）ユーザーによって受け入れられた任意のキーの鍵です。信頼ファイルPKI。
$ trusted recovery (I) A process that, after a system has experienced a failure or an attack, restores the system to normal operation (or to a secure state) without causing a security compromise. (See: recovery.)
$ 信頼できる回復（i）システムが障害や攻撃を経験した後に、セキュリティの侵害を引き起こさずにシステムを通常の操作（または安全な状態）に復元するプロセス。（回復を参照してください。）
$ trusted subnetwork (I) A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. (There also is an assumption that the underlying communication channels, such as telephone lines or a LAN, are protected from attack.)
$ 信頼できるサブネットワーク（i）アクティブまたはパッシブ攻撃に従事しないように、お互いを信頼するホストとルーターを含むサブネットワーク。（電話回線やLANなどの基礎となる通信チャネルが攻撃から保護されているという仮定もあります。）
$ trusted system 1. (I) /information system/ A system that operates as expected, according to design and policy, doing what is required -- despite environmental disruption, human user and operator errors, and attacks by hostile parties -- and not doing other things [NRC98]. (See: trust level, trusted process. Compare: trustworthy.)
$ 信頼されたシステム1.（i）/情報システム/情報システム/予想通りに動作するシステム、デザインとポリシーによると、環境中断、人間のユーザーとオペレータのエラー、および敵対的なパーティーによる攻撃にもかかわらず - 他のもの[NRC98]。（信頼レベル、信頼できるプロセスを参照してください。比較：信頼できる。）
2. (N) /multilevel secure/ "A [trusted system is a] system that employs sufficient hardware and software assurance measures to allow its use for simultaneous processing of a range of sensitive or classified information." [NCS04] (See: multilevel security mode.)
2. （n）/マルチレベルセキュア/ "A [信頼できるシステムはA]システムで、範囲の敏感な情報または分類された情報を同時に処理するための使用を可能にするのに十分なハードウェアとソフトウェア保証措置を採用しています。」[NCS04]（マルチレベルセキュリティモードを参照してください。）
$ Trusted Systems Interoperability Group (TSIG) (N) A forum of computer vendors, system integrators, and users devoted to promoting interoperability of trusted computer systems. (See: trusted system. Compare: TCG.)
$ 信頼できるシステム相互運用性グループ（TSIG）（N）信頼できるコンピュータシステムの相互運用性を促進するために専用のコンピュータベンダ、システムインテグレータ、およびユーザーのフォーラム。（：信頼できるシステム。比較：TCG。）
$ trustworthy system 1. (I) A system that not only is trusted, but also warrants that trust because the system's behavior can be validated in some convincing way, such as through formal analysis or code review. (See: trust. Compare: trusted.)
$ 信頼できるシステム1.（i）正式な分析やコードレビューなど、システムの動作が何らかの説得力のある方法で検証できるため、信頼できるシステム。（：信頼を参照してください。比較：Trusted。）
2. (O) /Digital Signature Guidelines/ "Computer hardware, software, and procedures that: (a) are reasonably secure from intrusion and misuse; (b) provide a reasonably reliable level of availability, reliability, and correct operation; (c) are reasonably suited to performing their intended functions; and (d) adhere to generally accepted security principles." [DSG]
2. （O）/デジタル署名のガイドライン/「コンピュータのハードウェア、ソフトウェア、および手順は、（a）は侵入と誤用から合理的に安全です。（b）は、合理的に信頼できるレベルの可用性、信頼性、および正しい操作を提供します。（c）意図した機能を実行するのに合理的に適しています。（D）一般的に承認されたセキュリティ原則に従ってください。」[DSG]
$ TSEC (O) See: Telecommunications Security Nomenclature System. (Compare: TCSEC.)
$ TSEC（O）は、電気通信セキュリティ命名法システムを参照してください。（比較：TCSEC。）
$ TSIG 1. (N) See: Trusted System Interoperability Group.
$ TSIG 1.（N）信頼できるシステム相互運用性グループを参照してください。
2. (I) A mnemonic (presumed to be derived from "Transaction SIGnature") referring to an Internet protocol (RFC 2845) for data origin authentication and data integrity for certain DNS operations. (See: TKEY.)
2. （i）特定のDNS演算のためのデータ原点認証およびデータ整合性のためのインターネットプロトコル（RFC 2845）を参照してニーモニック（「取引署名」から導出されると推定される）。（：TKEYを参照してください。）
$ tunnel 1. (I) A communication channel created in a computer network by encapsulating (i.e., layering) a communication protocol's data packets in (i.e., above) a second protocol that normally would be carried above, or at the same layer as, the first one. (See: L2TP, tunnel mode, VPN. Compare: covert channel.)
$ トンネル1.（i）通常、通信プロトコルのデータパケットをカプセル化（すなわち、上記）にカプセル化することによってコンピュータネットワークで作成された通信チャネル。最初の1つ。（：L2TP、トンネルモード、VPN。比較：Covert Channel。）
Tutorial: Tunneling can involve almost any two IPS protocol layers. For example, a TCP connection between two hosts could conceivably be carried above SMTP (i.e., in SMTP messages) as a covert channel to evade access controls that a security gateway applies to the normal TCP layer that is below SMTP.
チュートリアル：トンネリングはほとんど2つのIPSプロトコル層を含めることができます。例えば、2つのホスト間のTCP接続は、SMTPがSMTPより下の通常のTCPレイヤに適用される、アクセス制御を回避するためのCovertチャネルとしてSMTP（すなわちSMTPメッセージで）上で実行されていると考えられる。
Usually, however, a tunnel is a logical point-to-point link -- i.e., an OSIRM Layer 2 connection -- created by encapsulating the Layer 2 protocol in one of the following three types of IPS protocols: (a) an IPS Transport-Layer protocol (such as TCP), (b) an IPS Network-Layer or Internet-Layer protocol (such as IP), or (c) another Layer 2 protocol. In many cases, the encapsulation is accomplished with an extra, intermediate protocol (i.e., a "tunneling protocol"; e.g., L2TP) that is layered below the tunneled Layer 2 protocol and above the encapsulating protocol.
ただし、通常、トンネルは論理的なポイントツーポイントリンクです。つまり、次の3種類のIPSプロトコルのいずれかでレイヤ2プロトコルをカプセル化することによって作成されたOSIRMレイヤ2接続です。（TCPなど）、（b）IPSネットワーク層またはインターネット層プロトコル（IPなど）、または（c）他のレイヤ2プロトコル。多くの場合、カプセル化は、追加の中間プロトコル（すなわち、「トンネリングプロトコル」;例えば、L2TP）を用いて、トンネル層2プロトコルの下およびカプセル化プロトコルの上に階層化する。
Tunneling can be used to move data between computers that use a protocol not supported by the network connecting them. Tunneling also can enable a computer network to use the services of a second network as though the second network were a set of point-to-point links between the first network's nodes. (See: VPN.)
トンネリングを使用して、接続するネットワークでサポートされていないプロトコルを使用するコンピュータ間でデータを移動させることができます。トンネリングはまた、第2のネットワークが第1のネットワークのノード間のポイントツーポイントリンクのセットであるかのように、コンピュータネットワークが第2のネットワークのサービスを使用することを可能にすることができる。（：VPNを参照してください。）
2. (O) /SET/ The name of a SET private extension that indicates whether the CA or the payment gateway supports passing encrypted messages to the cardholder through the merchant. If so, the extension lists OIDs of symmetric encryption algorithms that are supported.
2. （O）/ SET / CAまたは支払いゲートウェイがマーチャントを介して暗号化されたメッセージをカード保有者に渡すかどうかを示すセットプライベート拡張の名前。もしそうであれば、拡張子はサポートされている対称暗号化アルゴリズムのOIDをリストします。
$ tunnel mode (I) One of two ways to apply the IPsec protocols (AH and ESP) to protect data packets; in this mode, the IPsec protocol encapsulates (i.e., the protection applies to) IP packets, rather than the packets of higher-layer protocols. (See: tunnel. Compare: transport mode.)
$ トンネルモード（i）データパケットを保護するためにIPsecプロトコル（AHとESP）を適用する2つの方法のうちの1つ。このモードでは、IPsecプロトコルは、上位レイヤプロトコルのパケットではなく、IPパケットをカプセル化する（すなわち、保護が適用されます）。（以下を参照してください。比較：トランスポートモード。）
Tutorial: Each end of a tunnel-mode security association may be either a host or a security gateway. Whenever either end of an IPsec security association is a security gateway, the association is required to be in tunnel mode.
チュートリアル：トンネルモードセキュリティアソシエーションの各端末は、ホストまたはセキュリティゲートウェイのいずれかです。IPsecセキュリティアソシエーションのどちらか終了がセキュリティゲートウェイである場合は、関連付けがトンネルモードにあることが必要です。
$ two-person control (I) The close surveillance and control of a system, a process, or materials (especially with regard to cryptography) at all times by a minimum of two appropriately authorized persons, each capable of detecting incorrect and unauthorized procedures with respect to the tasks to be performed and each familiar with established security requirements. (See: dual control, no-lone zone.)
$ 2人用コントロール（i）システムの緊密な監視と管理（特に暗号化、特に暗号化に関する）の制御（特に暗号化に関する）は、誤って不正確な手順を尊重し、不正な手順を検出することができます。実行されるタスクとそれぞれが確立されたセキュリティ要件に精通しています。（「デュアルコントロール、ノーローンゾーン」を参照してください。
$ Twofish (O) A symmetric, 128-bit block cipher with variable key length (128, 192, or 256 bits), developed by Counterpane Labs as a candidate for the AES. (See: Blowfish.)
$ Twofish（O）AESの候補としての対応Labsによって開発された、可変キー長（128,192、または256ビット）を備えた対称的な128ビットブロック暗号。（参照：ブローズ。）
$ type 0 product (O) /cryptography, U.S. Government/ Classified cryptographic equipment endorsed by NSA for use (when appropriately keyed) in electronically distributing bulk keying material.
$ NSAによって承認されたタイプ0製品（O）/暗号化、米国政府/分類された暗号化装置（適切に鍵がかかると）電子的に分配されたバルクキーイング材料。
$ type 1 key (O) /cryptography, U.S. Government/ "Generated and distributed under the auspices of NSA for use in a cryptographic device for the protection of classified and sensitive national security information." [C4009]
$ タイプ1キー（O）/暗号化、米国政府/ "は、分類された敏感な国内のセキュリティ情報を保護するための暗号デバイスで使用するためのNSAの後援の下で生成され分配されます。」[C4009]
$ type 1 product (O) /cryptography, U.S. Government/ "Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA approved algorithms. Used to protect systems requiring the most stringent protection mechanisms." [C4009]
$ タイプ1製品（O）/暗号化、米国政府/ "Cryptographic機器、アセンブリ、またはコンポーネントが適切に入力されたときに分類され、敏感な国内のセキュリティ情報を暗号化し復号化するために、NSAが分類して復号化するためのNSAによって分類され、認証されたコンポーネント。確立されたNSAビジネスプロセスとNSA承認アルゴリズムを含む開発。最も厳しい保護メカニズムを必要とするシステムを保護するために使用されます。」[C4009]
Tutorial: The current definition of this term is less specific than an earlier version: "Classified or controlled cryptographic item endorsed by the NSA for securing classified and sensitive U.S. Government information, when appropriately keyed. The term refers only to products, and not to information, key, services, or controls. Type 1 products contain classified NSA algorithms. They are available to U.S. Government users, their contractors, and federally sponsored non-U.S. Government activities subject to export restrictions in accordance with International Traffic in Arms Regulation." [from an earlier version of C4009] (See: ITAR.)
チュートリアル：この用語の現在の定義は、以前のバージョンよりも具体的ではありません。、キー、サービス、またはコントロール。1タイプ1の製品には、分類されたNSAアルゴリズムが含まれています。彼らは米国政府のユーザー、彼らの請負業者、そして連邦政府の政府活動を統制しています。[以前のバージョンのC4009から]（参照：ITARを参照）
$ type 2 key (O) /cryptography, U.S. Government/ "Generated and distributed under the auspices of NSA for use in a cryptographic device for the protection of unclassified national security information." [C4009]
$ 2型キー（O）/暗号化、米国政府/ "は、未分類されていない国家セキュリティ情報を保護するための暗号装置で使用するためにNSAの後援の下で生成され分配されます。」[C4009]
$ type 2 product (O) /cryptography, U.S. Government/ "Cryptographic equipment, assembly, or component certified by NSA for encrypting or decrypting sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA approved algorithms. Used to protect systems requiring protection mechanisms exceeding best commercial practices including systems used for the protection of unclassified national security information." [C4009]
$ タイプ2製品（O）/暗号化、米国政府/「身分証明書を適切に鍵としたときに、敏感な国家セキュリティ情報を暗号化または復号化するためのNSAによって認定された暗号化装置、アセンブリ、またはコンポーネント。確立されたNSAビジネスプロセスを使用し、NSA承認アルゴリズムを含む開発。保護に使用された未分類の国家セキュリティ情報の保護に使用されるシステムを含む最良の商業慣行を超える保護メカニズムを必要とするシステム。」[C4009]
Tutorial: The current definition of this term is less specific than an earlier version: "Unclassified cryptographic equipment, assembly, or component, endorsed by the NSA, for use in national security systems as defined in Title 40 U.S.C. Section 1452." [from an earlier version of C4009] (See: national security system. Compare: EUCI.)
チュートリアル：この用語の現在の定義は、タイトル40 u.s.c。[以前のバージョンのC4009から]（国家セキュリティシステムを参照してください。比較：Euci。）
$ type 3 key (O) /cryptography, U.S. Government/ "Used in a cryptographic device for the protection of unclassified sensitive information, even if used in a Type 1 or Type 2 product." [C4009]
$ タイプ1または2型製品で使用されていなくても、未分類の機密情報を保護するための暗号デバイスで使用されるタイプ3キー（O）/暗号化、米国政府/ "。[C4009]
$ type 3 product (O) /cryptography, U.S. Government/ "Unclassified cryptographic equipment, assembly, or component used, when appropriately keyed, for encrypting or decrypting unclassified sensitive U.S. Government or commercial information, and to protect systems requiring protection mechanisms consistent with standard commercial practices. Developed using established commercial standards and containing NIST approved cryptographic algorithms/modules or successfully evaluated by the National Information Assurance Partnership (NIAP)." [C4009]
$ タイプ3製品（O）/暗号化、米国政府/「未分類の暗号化装置、組み立て、またはコンポーネントは、未分類の敏感な米国政府または商業情報を暗号化または復号化するために、および標準的なコマーシャルと一致する保護メカニズムを必要とするシステムを保護する。慣行。確立された商業基準を使用し、NIST承認された暗号化アルゴリズム/モジュールを含む、または国家情報保証パートナーシップ（NIAP）によって正常に評価されました。[C4009]
$ type 4 key (O) /cryptography, U.S. Government/ "Used by a cryptographic device in support of its Type 4 functionality; i.e., any provision of key that lacks U.S. Government endorsement or oversight." [C4009]
$ タイプ4の機能をサポートしている暗号デバイスによって使用されている4キー（O）/暗号化、米国政府/ "。すなわち、米国政府の承認または監督を欠いている鍵の任意の提供。[C4009]
$ type 4 product (O) /cryptography, U.S. Government/ "Unevaluated commercial cryptographic equipment, assemblies, or components that neither NSA nor NIST certify for any Government usage. These products are typically delivered as part of commercial offerings and are commensurate with the vendor's commercial practices. These products may contain either vendor proprietary algorithms, algorithms registered by NIST, or algorithms registered by NIST and published in a FIPS." [C4009]
$ Type 4製品（O）/暗号化、米国政府/「未評価の市販の暗号化装置、アセンブリ、またはNSAもNSAも政府の使用を証明していないコンポーネント。これらの製品は通常、商業用品の一部として納品されており、ベンダーのコマーシャルに対応しています。慣行。これらの製品は、ベンダー独自のアルゴリズム、NISTによって登録されたアルゴリズム、またはNISTによって登録されてFIPSで公開されたアルゴリズムのいずれかを含みます。」[C4009]
$ UDP (I) See: User Datagram Protocol.
$ UDP（i）ユーザーデータグラムプロトコルを参照してください。
$ UDP flood (I) A denial-of-service attack that takes advantage of (a) one system's UDP test function that generates a series of characters for each packet it receives and (b) another system's UPD test function that echoes any character it receives; the attack connects (a) to (b) to cause a nonstop flow of data between the two systems. (See: flooding.)
$ UDP Flood（i）受信したパケットごとに一連の文字を生成する1つのシステムのUDPテスト機能を利用するサービス拒否攻撃、および（B）受信した文字をエコーする別のシステムのUPDテスト機能;攻撃は（a）〜（b）に接続して、2つのシステム間でデータのノンストップフローを引き起こします。（洪水を参照してください。）
$ unauthorized disclosure (I) A circumstance or event whereby an entity gains access to information for which the entity is not authorized.
$ 不正な開示（i）エンティティが企業が許可されていない情報へのアクセスを獲得する状況またはイベント。
Tutorial: This type of threat consequence can be caused by the following types of threat actions: exposure, interception, inference, and intrusion. Some methods of protecting against this consequence include access control, flow control, and inference control. (See: data confidentiality.)
チュートリアル：この種の脅威の結果は、露出、傍受、推論、侵入の種類によって引き起こされる可能性があります。この結果から保護する方法のいくつかの方法は、アクセス制御、フロー制御、および推論制御を含む。（データ機密性を参照してください。）
$ unauthorized user (I) /access control/ A system entity that accesses a system resource for which the entity has not received an authorization. (See: user. Compare: authorized user, insider, outsider.)
$ 許可されていないユーザー（I）/アクセス制御/エンティティが許可を受け取っていないシステムリソースにアクセスするシステムエンティティ。（ユーザーを参照してください。比較ユーザー、Insider、Outsider。）
Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.
使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されており、簡単に誤解される可能性があるため、定義を記載する必要があります。
$ uncertainty (N) An information-theoretic measure (usually stated as a number of bits) of the minimum amount of plaintext information that needs to be recovered from cipher text to learn the entire plain text that was encrypted. [SP63] (See: entropy.)
$ 不確実性（n）暗号化されたプレーンテキスト全体を学習するために暗号テキストから回復する必要がある最小限の平文情報の最小量の情報理論的尺度（通常、ビット数として述べた）。[SP63]（エントロピーを参照）
$ unclassified (I) Not classified. (Compare: FOUO.)
$ 未分類（i）分類されていない。（比較：fouo。）
$ unencrypted (I) Not encrypted.
$ 暗号化されていない（i）暗号化されていません。
$ unforgeable (I) /cryptography/ The property of a cryptographic data structure (i.e., a data structure that is defined using one or more cryptographic functions, e.g., "digital certificate") that makes it computationally infeasible to construct (i.e., compute) an unauthorized but correct value of the structure without having knowledge of one of more keys.
$ 忘れられない（i）/暗号化/暗号データ構造のプロパティ（すなわち、1つまたは複数の暗号機能を使用して定義されたデータ構造、例えば「デジタル証明書」）を計算することができ（すなわち、計算する）。より多くのキーの知識を持たずに、構造の不正だが構造の正しい値。
Tutorial: This definition is narrower than general English usage, where "unforgeable" means unable to be fraudulently created or duplicated. In that broader sense, anyone can forge a digital certificate containing any set of data items whatsoever by generating the to-be-signed certificate and signing it with any private key whatsoever. But for PKI purposes, the forged data structure is invalid if it is not signed with the true private key of the claimed issuer; thus, the forgery will be detected when a certificate user uses the true public key of the claimed issuer to verify the signature.
チュートリアル：この定義は一般的な英語の使用量よりも狭いです。ここで、「忘れられない」とは、不正に作成または重複することができないことを意味します。そのより幅広い意味で、誰でも署名された証明書を生成し、任意の秘密鍵と署名することによって、一連のデータ項目を含むデジタル証明書を鍛造できます。しかしPKIの目的のために、請求された発行者の真の秘密鍵と一緒に署名されていない場合、偽造データ構造は無効です。したがって、証明書ユーザーがクレームされた発行者の真の公開鍵を使用して署名を検証するときに偽造が検出されます。
$ uniform resource identifier (URI) (I) A type of formatted identifier (RFC 3986) that encapsulates the name of an Internet object, and labels it with an identification of the name space, thus producing a member of the universal set of names in registered name spaces and of addresses referring to registered protocols or name spaces.
$ ユニフォームリソース識別子（i）インターネットオブジェクトの名前をカプセル化し、名前空間の識別でラベル付けするフォーマット付き識別子（RFC 3986）のタイプで、登録内のユニバーサルセットのメンバーが作成されます。登録されたプロトコルまたはネームスペースを参照している名前のスペースとアドレス。
Example: HTML uses URIs to identify the target of hyperlinks.
例：HTMLはURIを使用してハイパーリンクのターゲットを識別します。
Usage: "A URI can be classified as a locator (see: URL), a name (see: URN), or both. ... Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme." IDOCs SHOULD "use the general term 'URI' rather than the more restrictive terms 'URL' and 'URN'." (RFC 3986)
使用法：「URIは、ロケータとして分類することができます（URLを参照）、名前（URN参照）、またはその両方。スキームの品質ではなく、命名権限による識別子の割り当てにおける持続性と注意に応じて。」IDOCは、より制限的な用語「URL」と「URN」ではなく、一般的な用語「URI」を使用する必要があります。（RFC 3986）
$ uniform resource locator (URL) (I) A URI that describes the access method and location of an information resource object on the Internet. (See: Usage under "URI". Compare: URN.)
$ ユニフォームリソースロケータ（URL）（i）インターネット上の情報リソースオブジェクトのアクセス方法と場所を説明するURI。（「URI」の下の使用法を参照してください。比較：URN。）
Tutorial: The term URL "refers to the subset of URIs that, besides identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network 'location')." (RFC 3986)
チュートリアル：URLという用語は、リソースを識別するのに加えて、そのプライマリアクセスメカニズム（例えば、ネットワークの位置 '）を記述することによってリソースを見つける手段を提供するURIのサブセットを指す。（RFC 3986）
A URL provides explicit instructions on how to access the named object. For example, "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. The part before the colon specifies the access scheme or protocol, and the part after the colon is interpreted according to that access method. Usually, two slashes after the colon indicate the host name of a server (written as a domain name). In an FTP or HTTP URL, the host name is followed by the path name of a file on the server. The last (optional) part of a URL may be either a fragment identifier that indicates a position in the file, or a query string.
URLは、名前付きオブジェクトにアクセスする方法に関する明示的な説明を提供します。たとえば、 "ftp://bbnarchive.bbn.com/foo/bar/picture / cambridge.zip"はURLです。コロンがアクセス方式またはプロトコルを指定する前の部分と、コロンがそのアクセス方法に従って解釈された後の部分が解釈されます。通常、コロンの後に2つのスラッシュが表示され、サーバーのホスト名（ドメイン名として書かれています）が表示されます。FTPまたはHTTP URLでは、ホスト名の後にサーバー上のファイルのパス名が続きます。URLの最後の（任意）部分は、ファイル内の位置を示すフラグメント識別子、またはクエリ文字列のいずれかであり得る。
$ uniform resource name (URN) (I) A URI with the properties of a name. (See: Usage under "URI". Compare: URL.)
$ ユニフォームリソース名（URN）（i）名前のプロパティを持つURI。（「URI」の「使用」を参照してください。比較：URL。）
Tutorial: The term URN "has been used historically to refer to both URIs under the "urn" scheme (RFC 2141), which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name." (RFC 3986)
チュートリアル：urnという用語は、歴史的に「URN」スキーム（RFC 2141）の下でのURIを参照して、リソースが存在しなくなった場合、または他のどのようなものになっても、グローバルにユニークで持続的に維持する必要がある。名前のプロパティを持つURI。」（RFC 3986）
$ untrusted (I) See: secondary definition under "trust".
$ 信頼されていない（i）「信頼」の下の二次定義を参照してください。
$ untrusted process 1. (I) A system component that is not able to affect the state of system security through incorrect or malicious operation. Example: A component that has its operations confined by a security kernel. (See: trusted process.)
$ 信頼できないプロセス1.（i）誤ったまたは悪意のある操作を通じてシステムセキュリティの状態に影響を与えることができないシステムコンポーネント。例：セキュリティカーネルによって動作しているコンポーネント。（：信頼されたプロセスを参照してください。）
2. (I) A system component that (a) has not been evaluated or examined for adherence to a specified security policy and, therefore, (b) must be assumed to contain logic that might attempt to circumvent system security.
2. （i）指定されたセキュリティポリシーを順守するために（a）が評価または検査されていないシステムコンポーネント、したがって、（b）、システムセキュリティを回避することを試みる可能性があるロジックを含むと仮定する必要があります。
$ UORA (O) See: user-PIN ORA.
$ UORA（O）は、ユーザーピンORAを参照してください。
$ update See: "certificate update" and "key update".
$ 更新：「証明書の更新」と「キーの更新」。
$ upgrade (I) /data security/ Increase the classification level of data without changing the information content of the data. (See: classify, downgrade, regrade.)
$ アップグレード（i）/データセキュリティ/データの情報内容を変更せずにデータの分類レベルを増やします。（参照：分類、ダウングレード、根拠を参照してください。）
$ URI (I) See: uniform resource identifier.
$ URI（i）：Uniform Resource Identifierを参照してください。
$ URL (I) See: uniform resource locator.
$ URL（i）：Uniform Resource Locatorを参照してください。
$ URN (I) See: uniform resource name.
$ URN（i）：ユニフォームリソース名を参照してください。
$ user See: system user.
$ ユーザーはシステムユーザーを参照してください。
Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.
使用法：この用語を使用するIDocは、用語がさまざまな方法で使用されており、簡単に誤解される可能性があるため、定義を記載する必要があります。
$ user authentication service (I) A security service that verifies the identity claimed by an entity that attempts to access the system. (See: authentication, user.)
$ ユーザー認証サービス（i）システムにアクセスしようとするエンティティによって主張されたIDを検証するセキュリティサービス。（認証、ユーザー。）
$ User Datagram Protocol (UDP) (I) An Internet Standard, Transport-Layer protocol (RFC 768) that delivers a sequence of datagrams from one computer to another in a computer network. (See: UPD flood.)
$ ユーザデータグラムプロトコル（UDP）（i）コンピュータネットワーク内の1つのコンピュータから別のコンピュータへのデータグラムのシーケンスを配信するインターネット規格のトランスポート層プロトコル（RFC 768）。（洪水の洪水を参照してください。）
Tutorial: UDP assumes that IP is the underlying protocol. UDP enables application programs to send transaction-oriented data to other programs with minimal protocol mechanism. UDP does not provide reliable delivery, flow control, sequencing, or other end-to-end service guarantees that TCP does.
チュートリアル：UDPはIPが基礎となるプロトコルであると想定しています。UDPでは、アプリケーションプログラムは最小限のプロトコルメカニズムを使用して他のプログラムにトランザクション指向データを送信できます。UDPは信頼できる配信、フロー制御、シーケンス、または他のエンドツーエンドのサービスを提供していません。
$ user identifier (I) See: identifier.
$ ユーザー識別子（i）識別子を参照してください。
$ user identity (I) See: identity.
$ ユーザーID（i）識別情報を参照してください。
$ user PIN (O) /MISSI/ One of two PINs that control access to the functions and stored data of a FORTEZZA PC card. Knowledge of the user PIN enables a card user to perform the FORTEZZA functions that are intended for use by an end user. (See: PIN. Compare: SSO PIN.)
$ ユーザーPIN（O）/ MISSI / Fortezza PCカードの機能へのアクセスを制御する2つのピンのうちの1つ。ユーザピンの知識は、カードユーザがエンドユーザによる使用を目的としたFortezza機能を実行することを可能にする。（以下を参照してください。比較：SSO端子を比較してください。）
$ user-PIN ORA (UORA) (O) /MISSI/ A MISSI organizational RA that operates in a mode in which the ORA performs only the subset of card management functions that are possible with knowledge of the user PIN for a FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.)
$ Fortezza PCカード用のユーザーピンの知識で可能なカード管理機能のサブセットのみを実行するモードで動作するユーザーピンORA（UORA）/ MISSI組織RA。（参照：ノーピンORA、SSOピンORA。）
$ usurpation (I) A circumstance or event that results in control of system services or functions by an unauthorized entity. This type of threat consequence can be caused by the following types of threat actions: misappropriation, misuse. (See: access control.)
$ USURPATION（i）不正なエンティティによるシステムサービスまたは機能の制御をもたらす状況またはイベント。このタイプの脅威の結果は、以下の種類の脅威の行動によって引き起こされる可能性があります。不正確さ、誤用。（（アクセス制御を参照してください。）
$ UTCTime (N) The ASN.1 data type "UTCTime" contains a calendar date (YYMMDD) and a time to a precision of either one minute (HHMM) or one second (HHMMSS), where the time is either (a) Coordinated Universal Time or (b) the local time followed by an offset that enables Coordinated Universal Time to be calculated. (See: Coordinated Universal Time. Compare: GeneralizedTime.)
$ utctime（n）ASN.1データ型 "utctime"には、カレンダー日付（yymmdd）と1分（hhmm）または1秒（hhmms）の精度までの時間が含まれています。時間または（b）現地時間とそれに続くオフセットが続くオフセットが算出されます。（協定ユニバーサルタイムを参照してください。比較：一般化時間を比較してください。）
Usage: If you care about centuries or millennia, you probably need to use the GeneralizedTime data type instead of UTCTime.
使用法：何世紀世紀やミレニアを気にかけているならば、あなたはおそらくutctimeの代わりに一般化時間データ型を使う必要があります。
$ v1 certificate (N) An abbreviation that ambiguously refers to either an "X.509 public-key certificate in version 1 format" or an "X.509 attribute certificate in version 1 format".
$ v1証明書（n）「バージョン1フォーマットの公開鍵証明書」または「X.509属性証明書」のいずれかを曖昧に指す略語。
Deprecated Usage: IDOCs MAY use this term as an abbreviation of "version 1 X.509 public-key certificate", but only after using the full term at the first instance. Otherwise, the term is ambiguous, because X.509 specifies both v1 public-key certificates and v1 attribute certificates. (See: X.509 attribute certificate, X.509 public-key certificate.)
廃止予定の使用法：IDOCは、この用語を「バージョン1 x.509公開鍵証明書」の略語として使用することができますが、最初のインスタンスで全期間を使用した後にのみ使用できます。それ以外の場合、X.509はV1公開鍵証明書とv1属性証明書の両方を指定しているため、この用語はあいまいです。（X.509属性証明書、X.509公開鍵証明書を参照）
$ v1 CRL (N) Abbreviation of "X.509 CRL in version 1 format".
$ V1 CRL（N）「バージョン1フォーマットのCRL」の略語。
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full term at its first occurrence and define the abbreviation there.
使用法：IDocはこの略語を使用することができますが、最初の出現時に全文を使用し、そこで略語を定義する必要があります。
$ v2 certificate (N) Abbreviation of "X.509 public-key certificate in version 2 format".
$ V2証明書（N）「バージョン2形式の公開鍵証明書」の略語。
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full term at its first occurrence and define the abbreviation there.
使用法：IDocはこの略語を使用することができますが、最初の出現時に全文を使用し、そこで略語を定義する必要があります。
$ v2 CRL (N) Abbreviation of "X.509 CRL in version 2 format".
$ V2 CRL（n）「バージョン2フォーマットのX.509 CRL」の略語。
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full term at its first occurrence and define the abbreviation there.
使用法：IDocはこの略語を使用することができますが、最初の出現時に全文を使用し、そこで略語を定義する必要があります。
$ v3 certificate (N) Abbreviation of "X.509 public-key certificate in version 3 format".
$ v3証明書（N）「バージョン3フォーマットの公開鍵証明書」の略語。
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full term at its first occurrence and define the abbreviation there.
使用法：IDocはこの略語を使用することができますが、最初の出現時に全文を使用し、そこで略語を定義する必要があります。
$ valid certificate 1. (I) A digital certificate that can be validated successfully. (See: validate, verify.)
$ 有効な証明書1.（i）正常に検証できるデジタル証明書。（検証、検証を参照）
2. (I) A digital certificate for which the binding of the data items can be trusted.
2. （i）データ項目のバインディングを信頼できるデジタル証明書。
$ valid signature (D) Synonym for "verified signature".
$ 有効な署名（D）「検証署名」の同義語。
Deprecated Term: IDOCs SHOULD NOT use this synonym. This Glossary recommends saying "validate the certificate" and "verify the signature"; therefore, it would be inconsistent to say that a signature is "valid". (See: validate, verify.)
廃止予定語：IDocsはこの同義語を使用しないでください。この用語集は「証明書の検証」と「署名を確認する」と勧告することをお勧めします。したがって、署名が「有効」であると言うことは矛盾するでしょう。（検証、検証を参照）
$ validate 1. (I) Establish the soundness or correctness of a construct. Example: certificate validation. (See: validate vs. verify.)
$ （i）構築物の健全性または正確さを確立する。例：証明書検証（VS. Veriveを検証してください。）
2. (I) To officially approve something, sometimes in relation to a standard. Example: NIST validates cryptographic modules for conformance with [FP140].
2. （i）時々標準に関連して何かを正式に承認する。例：NIST [FP140]に準拠するための暗号モジュールを検証します。
$ validate vs. verify Usage: To ensure consistency and align with ordinary English usage, IDOCs SHOULD comply with the following two rules: - Rule 1: Use "validate" when referring to a process intended to establish the soundness or correctness of a construct (e.g., "certificate validation"). (See: validate.) - Rule 2: Use "verify" when referring to a process intended to test or prove the truth or accuracy of a fact or value (e.g., "authenticate"). (See: verify.)
$ VS.検証使用方法：通常の英語の使用状況と一貫性を確保し、IDocは次の2つの規則に準拠する必要があります。「証明書検証」）。（検証。） - 規則2：事実または値の真実または正確性をテストまたは証明することを目的としたプロセスを参照すると、「検証」を使用してください（例えば、「認証」）。（確認してください。）
Tutorial: The Internet security community sometimes uses these two terms inconsistently, especially in a PKI context. Most often, however, we say "verify the signature" but say "validate the certificate". That is, we "verify" atomic truths but "validate" data structures, relationships, and systems that are composed of or depend on verified items. This usage has a basis in Latin:
チュートリアル：インターネットセキュリティコミュニティは、特にPKIコンテキストで、これら2つの用語を不整合的に使用することがあります。しかし、ほとんどの場合、「署名の確認」と言うが、「証明書の検証」と言う。つまり、アトミックの真理値が「検証」するが、データ構造、関係、および検証されたアイテムに依存するシステムを検証する。この使用法はラテン語に基づいています。
The word "valid" derives from a Latin word that means "strong". Thus, to validate means to check that a construct is sound. For example, a certificate user validates a public-key certificate to establish trust in the binding that the certificate asserts between an identity and a key. This can include checking various aspects of the certificate's construction, such as verifying the digital signature on the certificate by performing calculations, verifying that the current time is within the certificate's validity period, and validating a certification path involving additional certificates.
「有効」という言葉は、「強い」という意味のラテン語から派生します。したがって、構築物が音があることを確認するための手段を検証する。たとえば、証明書ユーザーは公開鍵証明書を検証して、証明書がIDと鍵との間でアサートするバインディングに信頼を確立します。これには、計算を実行して、証明書のデジタル署名の検証など、証明書のデジタル署名の検証などのさまざまな側面をチェックし、現在の時刻が証明書の有効期間内にあることを確認し、追加の証明書を含む認証パスを検証することを含みます。
The word "verify" derives from a Latin word that means "true". Thus, to verify means to check the truth of an assertion by examining evidence or performing tests. For example, to verify an identity, an authentication process examines identification information that is presented or generated. To validate a certificate, a certificate user verifies the digital signature on the certificate by performing calculations, verifies that the current time is within the certificate's validity period, and may need to validate a certification path involving additional certificates.
「Verify」という単語はラテン語の単語から「真」を意味します。したがって、証拠を調べるかテストを実行することによってアサーションの真実をチェックすることを検証するために。例えば、識別情報を検証するために、認証プロセスは、提示または生成された識別情報を調べる。証明書を検証するために、証明書ユーザーは計算を実行することによって証明書のデジタル署名を検証し、現在の時刻が証明書の有効期間内にあることを確認し、追加の証明書を含む認証パスを検証する必要があるかもしれません。
$ validation (I) See: validate vs. verify.
$ 検証（I）検証対VERSEを参照してください。
$ validity period (I) /PKI/ A data item in a digital certificate that specifies the time period for which the binding between data items (especially between the subject name and the public key value in a public-key certificate) is valid, except if the certificate appears on a CRL or the key appears on a CKL. (See: cryptoperiod, key lifetime.)
$ データ項目間のバインディング（特に公開鍵証明書の公開鍵の値）間のバインディングが有効であるデジタル証明書内の有効期間（I）/ PKI / Aデータ項目証明書がCRL上に表示されているか、キーがCKLに表示されます。（参照：暗号化、鍵の有効期間。）
$ value-added network (VAN) (I) A computer network or subnetwork (usually a commercial enterprise) that transmits, receives, and stores EDI transactions on behalf of its users.
$ 付加価値ネットワーク（I）ユーザーに代わってEDIトランザクションを送信、受信し、および保存するコンピュータネットワークまたはサブネットワーク（通常は商業企業）。
Tutorial: A VAN may also provide additional services, ranging from EDI format translation, to EDI-to-FAX conversion, to integrated business systems.
チュートリアル：VANはまた、EDIフォーマット翻訳からEDI-TO-FAXへの統合されたビジネスシステムへの範囲の追加のサービスを提供することがあります。
$ VAN (I) See: value-added network.
$ （i）付加価値ネットワークを参照できます。
$ verification 1. (I) /authentication/ The process of examining information to establish the truth of a claimed fact or value. (See: validate vs. verify, verify. Compare: authentication.)
$ 検証1.（i）/認証/特許請求された事実または価値の真理を確立するための情報を調べるプロセス。（検証対VS. Verive、Verify。Compare：認証を参照してください。）
2. (N) /COMPUSEC/ The process of comparing two levels of system specification for proper correspondence, such as comparing a security model with a top-level specification, a top-level specification with source code, or source code with object code. [NCS04]
2. （n）/ compusec /セキュリティモデルと最上位の仕様、ソースコードを含む最上位仕様、またはオブジェクトコードを含むソースコードなどの適切な対応のための2つのレベルのシステム仕様を比較するプロセス。[NCS04]
$ verified design (O) See: TCSEC Class A1.
$ 検証済みデザイン（O）TCSECクラスA1を参照してください。
$ verify (I) To test or prove the truth or accuracy of a fact or value. (See: validate vs. verify, verification. Compare: authenticate.)
$ （i）事実や価値の真実や正確さをテストまたは証明することを確認してください。（VS. Verive、Verecificationを検証します。比較：認証。）
$ vet (I) /verb/ To examine or evaluate thoroughly. (Compare: authenticate, identity proofing, validate, verify.)
$ 獣医（i）/動詞/徹底的に検討または評価する。（比較：認証、ID校正、検証、検証。）
$ violation See: security violation.
$ 違反：セキュリティ違反
$ virtual private network (VPN) (I) A restricted-use, logical (i.e., artificial or simulated) computer network that is constructed from the system resources of a relatively public, physical (i.e., real) network (e.g., the Internet), often by using encryption (located at hosts or gateways), and often by tunneling links of the virtual network across the real network. (See: tunnel.)
$ 仮想プライベートネットワーク（VPN）（i）比較的一般的な、物理的（IE、REAL）ネットワーク（例えば、インターネット）のシステムリソースから構築された制限された論理（すなわち、人工的またはシミュレーション）コンピュータネットワーク。多くの場合、暗号化（ホストまたはゲートウェイにある）、そして実際のネットワーク全体の仮想ネットワークのリンクをトンネリングすることによってよくあります。（以下を参照してください。）
Tutorial: A VPN is generally less expensive to build and operate than a dedicated real network, because the virtual network shares the cost of system resources with other users of the underlying real network. For example, if a corporation has LANs at several different sites, each connected to the Internet by a firewall, the corporation could create a VPN by using encrypted tunnels to connect from firewall to firewall across the Internet.
チュートリアル：VPNは一般的に専用の実際のネットワークよりも構築して動作するのが一般的に高価ではありません。これは、仮想ネットワークは基盤となる実際のネットワークの他のユーザーとのシステムリソースのコストを共有しています。たとえば、企業がファイアウォールによってインターネットに接続されているいくつかの異なるサイトでLANがある場合、当社はインターネットを介してファイアウォールからファイアウォールに接続するために暗号化されたトンネルを使用することによってVPNを作成できます。
$ virus (I) A self-replicating (and usually hidden) section of computer software (usually malicious logic) that propagates by infecting -- i.e., inserting a copy of itself into and becoming part of -- another program. A virus cannot run by itself; it requires that its host program be run to make the virus active.
$ ウイルス（i）コンピュータソフトウェア（通常は悪意のあるロジック）の自己複製（通常は悪意のあるロジック）のセクションである - すなわち、それ自体のコピーを挿入し、別のプログラムの一部になる。ウイルスはそれ自体で実行できません。そのホストプログラムを実行してウイルスをアクティブにする必要があります。
$ Visa Cash (O) A smartcard-based electronic money system that incorporates cryptography and can be used to make payments via the Internet. (See: IOTP.)
$ VISA現金（O）暗号化を組み込んで、インターネットを介して支払いをするために使用することができるスマートカードベースの電子マネーシステム。（参照：iotp。）
$ volatile media (I) Storage media that require an external power supply to maintain stored information. (Compare: non-volatile media, permanent storage.)
$ 揮発性媒体（i）保存された情報を維持するために外部電源装置を必要とする記憶媒体。（比較：不揮発性媒体、永久収納。）
$ VPN (I) See: virtual private network.
$ VPN（i）：仮想プライベートネットワークを参照してください。
$ vulnerability (I) A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (See: harden.)
$ 脆弱性（i）システムのセキュリティポリシーに違反するために悪用される可能性のあるシステムの設計、実装、または操作および管理の欠陥または弱点。（硬化を参照してください。）
Tutorial: A system can have three types of vulnerabilities: (a) vulnerabilities in design or specification; (b) vulnerabilities in implementation; and (c) vulnerabilities in operation and management. Most systems have one or more vulnerabilities, but this does not mean that the systems are too flawed to use. Not every threat results in an attack, and not every attack succeeds. Success depends on the degree of vulnerability, the strength of attacks, and the effectiveness of any countermeasures in use. If the attacks needed to exploit a vulnerability are very difficult to carry out, then the vulnerability may be tolerable. If the perceived benefit to an attacker is small, then even an easily exploited vulnerability may be tolerable. However, if the attacks are well understood and easily made, and if the vulnerable system is employed by a wide range of users, then it is likely that there will be enough motivation for someone to launch an attack.
チュートリアル：システムには3種類の脆弱性があります。（a）設計または仕様の脆弱性。（b）実装における脆弱性。（c）運用管理における脆弱性。ほとんどのシステムには1つ以上の脆弱性がありますが、これはシステムが使用するには欠陥があるという意味ではありません。あらゆる脅威が攻撃をもたらすわけではなく、すべての攻撃が成功するわけではありません。成功は、脆弱性、攻撃の強さ、および使用中の対策の有効性によって異なります。脆弱性を悪用するのに必要な攻撃が実行するのが非常に難しい場合は、この脆弱性は許容できる可能性があります。攻撃者への知覚された利益が小さい場合は、簡単に活用された脆弱性でさえ許容できる可能性さえあります。ただし、攻撃がよく理解されやすい場合、そして脆弱なシステムが幅広いユーザーによって採用されている場合、誰かが攻撃を開始するのに十分な動機がある可能性があります。
$ W3 (D) Synonym for WWW.
$ W3（D）WWWの同義語。
Deprecated Abbreviation: This abbreviation could be confused with W3C; use "WWW" instead.
廃止予定の省略形：この略語はW3Cと混同することができます。代わりに "www"を使用してください。
$ W3C (N) See: World Wide Web Consortium.
$ W3C（N）は、ワールドワイドウェブコンソーシアムを参照してください。
$ war dialer (I) /slang/ A computer program that automatically dials a series of telephone numbers to find lines connected to computer systems, and catalogs those numbers so that a cracker can try to break the systems.
$ War Dialer（i）/ Slang /コンピュータシステムに接続された一連の電話番号を自動的にダイヤルするコンピュータプログラム、およびクラッカーがシステムを破るようにすることができるようにそれらの数をカタログ化するコンピュータプログラム。
Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term could confuse international readers.
廃止予定の使用法：この用語を使用するIDocは、その用語が国際読者を混乱させる可能性があるため、定義を述べるべきです。
$ Wassenaar Arrangement (N) The Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies is a global, multilateral agreement approved by 33 countries in July 1996 to contribute to regional and international security and stability, by promoting information exchange concerning, and greater responsibility in, transfers of arms and dual-use items, thus preventing destabilizing accumulations. (See: International Traffic in Arms Regulations.)
$ Wassenaarの配置（n）従来の武器および二重用品および技術の輸出管理に関するWassenaarの配置は、1996年7月に33カ国が承認したグローバル、多国間協定であり、情報交換を促進することにより、そして、腕と二重の使用項目の移動、したがって不安定化を防ぐことができます。（武器規制の国際交通。）
Tutorial: The Arrangement began operations in September 1996 with headquarters in Vienna. The participating countries were Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom, and United States.
チュートリアル：この取り決めは1996年9月にウィーンの本部で事業を開始しました。参加国は、アルゼンチン、オーストラリア、オーストリア、ベルギー、ブルガリア、カナダ、チェコ共和国、デンマーク、フィンランド、フランス、ドイツ、ギリシャ、ハンガリー、アイルランド、イタリア、日本、ルクセンブルク、オランダ、ノルウェー、ポルトガル、韓国、ルーマニア、ロシア連邦、スロバキア共和国、スペイン、スウェーデン、スイス、トルコ、ウクライナ、イギリス、アメリカ合衆国。
Participating countries seek through their national policies to ensure that transfers do not contribute to the development or enhancement of military capabilities that undermine the goals of the arrangement, and are not diverted to support such capabilities. The countries maintain effective export controls for items on the agreed lists, which are reviewed periodically to account for technological developments and experience gained. Through transparency and exchange of views and information, suppliers of arms and dual-use items can develop common understandings of the risks associated with their transfer and assess the scope for coordinating national control policies to combat these risks. Members provide semi-annual notification of arms transfers, covering seven categories derived from the UN Register of Conventional Arms. Members also report transfers or denials of transfers of certain controlled dual-use items. However, the decision to transfer or deny transfer of any item is the sole responsibility of each participating country. All measures undertaken with respect to the arrangement are in accordance with national legislation and policies and are implemented on the basis of national discretion.
参加国は、転送がこの課題の目標を損なう軍事能力の発展や強化に貢献していないことを確実にし、そのような能力を支援するために迂回されていないことを確実にするために、彼らの国家政策を模索しています。国は合意されたリストの項目の効果的な輸出管理を維持しており、これは技術的発展と得られた経験を説明するために定期的にレビューされます。透明性と意見の交換と情報の交換、武器や二重の使用項目の供給者は、彼らの譲渡に関連するリスクの一般的な理解を開発し、これらのリスクと戦うために国家管理政策を調整するための範囲を評価することができます。メンバーは、従来の武器の国連登録から導き出された7つのカテゴリを網羅した、武器転送の半年返信を提供します。メンバーはまた、特定の制御された二重使用項目の転送または拒否を報告する。ただし、どの項目の転送または拒否の決定は、各参加国の唯一の責任です。この取り決めに関して行われたすべての対策は、国内法と方針に従って、国内の裁量に基づいて実施されています。
$ watermarking See: digital watermarking.
$ 透かし入れてください：デジタル透かし
$ weak key (I) In the context of a particular cryptographic algorithm, a key value that provides poor security. (See: strong.)
$ 弱キー（i）特定の暗号化アルゴリズムの文脈では、安全性が悪いキー値。（：強い）
Example: The DEA has four "weak keys" [Schn] for which encryption produces the same result as decryption. It also has ten pairs of "semi-weak keys" [Schn] (a.k.a. "dual keys" [FP074]) for which encryption with one key in the pair produces the same result as decryption with the other key.
例：DEAには、暗号化が復号化と同じ結果を生み出す4つの「弱キー」[SCHN]があります。ペア内の1つのキーを持つ暗号化が他のキーで復号化と同じ結果を生み出す、10組の「半弱キー」（A.K.A.Dual Keys "[FP074]）もあります。
$ web, Web 1. (I) /not capitalized/ IDOCs SHOULD NOT capitalize "web" when using the term (usually as an adjective) to refer generically to technology -- such as web browsers, web servers, HTTP, and HTML -- that is used in the Web or similar networks.
$ Web、Web 1.（i）/ではない/ IDOCは、Webブラウザ、Webサーバー、HTTP、およびHTMLなどのテクノロジーに一般的に参照するために（通常は形容詞として）「Web」を大文字にするべきではありません。それはWebまたは類似のネットワークで使用されています。
2. (I) /capitalized/ IDOCs SHOULD capitalize "Web" when using the term (as either a noun or an adjective) to refer specifically to the World Wide Web. (Similarly, see: internet.) Usage: IDOCs SHOULD NOT use "web" or "Web" in a way that might confuse these definitions with the PGP "web of trust". When using Web as an abbreviation for "World Wide Web", IDOCs SHOULD fully spell out the term at the first instance of usage.
2.（i）/資本化された/ IDocは、（名詞または形容詞のいずれかとして）世界ワイドウェブを指すために（名詞または形容詞のいずれかとして）「Web」を大文字にする必要があります。（同様に：インターネットを参照してください。）使用法：IDocは、これらの定義をPGP "Web信頼"で混同する可能性がある方法で「Web」または「Web」を使用しないでください。Webを「World Wide Web」の略語として使用する場合、IDocは最初の使用例の用語を完全に綴ってください。
$ web of trust (D) /PGP/ A PKI architecture in which each certificate user defines their own trust anchor(s) by depending on personal relationships. (See: trust anchor. Compare: hierarchical PKI, mesh PKI.)
$ 各証明書ユーザーが個人的な関係に応じて独自の信頼のアンカーを定義するPKIアーキテクチャーのWeb / PGP / A PKIアーキテクチャ。（：信託アンカー。比較：階層PKI、メッシュPKI。）
Deprecated Usage: IDOCs SHOULD NOT use this term except with reference to PGP. This term mixes concepts in potentially misleading ways; e.g., this architecture does not depend on World Wide Web technology. Instead of this term, IDOCs MAY use "trust-file PKI". (See: web, Web).
廃止予定の使用法：IDocは、PGPを参照してこの用語を使用しないでください。この用語は潜在的に誤解を招く方法で概念を混在させます。例えば、このアーキテクチャは世界的なWeb技術には依存しません。この用語の代わりに、IDocは「信頼ファイルPKI」を使用することがあります。（参照：Web、Web）。
Tutorial: This type of architecture does not usually include public repositories of certificates. Instead, each certificate user builds their own, private repository of trusted public keys by making personal judgments about being able to trust certain people to be holding properly certified keys of other people. It is this set of person-to-person relationships from which the architecture gets its name.
チュートリアル：このタイプのアーキテクチャには、通常、証明書のパブリックリポジトリが含まれていません。代わりに、各証明書ユーザーは、他の人々の正しく認証された鍵を保持することを信頼することができることを個人的な判断をすることによって、信頼できる公開鍵の独自のプライベートリポジトリを構築します。アーキテクチャがその名前を取得するのは、このセットの人間関係です。
$ web server (I) A software process that runs on a host computer connected to a network and responds to HTTP requests made by client web browsers.
$ Webサーバー（i）ネットワークに接続されているホストコンピュータ上で実行され、クライアントWebブラウザによって作成されたHTTP要求に応答するソフトウェアプロセス。
$ WEP (N) See: Wired Equivalency Protocol.
$ WEP（N）は、有線相当プロトコルを参照してください。
$ Wired Equivalent Privacy (WEP) (N) A cryptographic protocol that is defined in the IEEE 802.11 standard and encapsulates the packets on wireless LANs. Usage: a.k.a. "Wired Equivalency Protocol".
$ 有線同等のプライバシー（WEP）（n）IEEE 802.11規格で定義され、無線LAN上のパケットをカプセル化する暗号プロトコル。使用法：a.k.a. "有線相当プロトコル"。
Tutorial: The WEP design, which uses RC4 to encrypt both the plain text and a CRC, has been shown to be flawed in multiple ways; and it also has often suffered from flawed implementation and management.
チュートリアル：RC4を使用してプレーンテキストとCRCの両方を暗号化するためにRC4を使用するWEPデザインは、複数の方法で欠陥があることが示されています。そしてそれはまたしばしば欠陥のある実装と管理を受けています。
$ wiretapping (I) An attack that intercepts and accesses information contained in a data flow in a communication system. (See: active wiretapping, end-to-end encryption, passive wiretapping, secondary definition under "interception".) Usage: Although the term originally referred to making a mechanical connection to an electrical conductor that links two nodes, it is now used to refer to accessing information from any sort of medium used for a link or even from a node, such as a gateway or subnetwork switch.
$盗聴（i）通信システム内のデータフローに含まれる情報を傍受してアクセスする攻撃。（参照：アクティブな盗聴、エンドツーエンド暗号化、パッシブワイニャッピング、「傍受」の下の2次定義。）使用法：2つのノードをリンクする電気伝導体への機械的接続を行うという用語は現在に使用されています。リンクに使用されている媒体から、あるいはゲートウェイやサブネットワークスイッチなどのノードからさえも情報へのアクセスを参照してください。
Tutorial: Wiretapping can be characterized according to intent: - "Active wiretapping" attempts to alter the data or otherwise affect the flow. - "Passive wiretapping" only attempts to observe the data flow and gain knowledge of information contained in it.
チュートリアル：盗聴は、意図に従って特徴付けることができます。 - 「アクティブな盗聴」データを変更したり、その他のフローに影響を与えようとします。 - 「パッシブ盗聴」は、データの流れを観察し、それに含まれる情報の知識を得ることを試みます。
$ work factor 1a. (I) /COMPUSEC/ The estimated amount of effort or time that can be expected to be expended by a potential intruder to penetrate a system, or defeat a particular countermeasure, when using specified amounts of expertise and resources. (See: brute force, impossible, strength.)
$ 仕事係数1a。（i）/ compusec /指定された量の専門知識とリソースを使用するときに、システムを貫通する潜在的な侵入者によって費やされると予想される努力の推定された労力または時間。（参照：ブルートフォース、不可能、強さ。）
1b. (I) /cryptography/ The estimated amount of computing power and time needed to break a cryptographic system. (See: brute force, impossible, strength.)
1b。（i）/暗号化/暗号化システムを破るのに必要な計算能力の推定量。（参照：ブルートフォース、不可能、強さ。）
$ World Wide Web ("the Web", WWW) (N) The global, hypermedia-based collection of information and services that is available on Internet servers and is accessed by browsers using Hypertext Transfer Protocol and other information retrieval mechanisms. (See: web vs. Web, [R2084].)
$ World Wide Web（ "Web"、WWW）（n）インターネットサーバーで利用可能で、ハイパーテキスト転送プロトコルやその他の情報検索メカニズムを使用してブラウザによってアクセスされる、グローバルなハイパーメディアベースの情報とサービスのコレクション。（：Web対Web、[R2084]を参照）
$ World Wide Web Consortium (W3C) (N) Created in October 1994 to develop and standardize protocols to promote the evolution and interoperability of the Web, and now consisting of hundreds of member organizations (commercial firms, governmental agencies, schools, and others).
$ World Wide Webコンソーシアム（W3C）（N）1994年10月に作成されたWebの進化と相互運用性を促進し、現在は何百もの会員組織（商業企業、政府機関、学校など）からなる。
Tutorial: W3C Recommendations are developed through a process similar to that of the standards published by other organizations, such as the IETF. The W3 Recommendation Track (i.e., standards track) has four levels of increasing maturity: Working, Candidate Recommendation, Proposed Recommendation, and W3C Recommendation. W3C Recommendations are similar to the standards published by other organizations. (Compare: Internet Standard, ISO.)
チュートリアル：W3Cの推奨事項は、IETFなどの他の組織によって公開された規格と同様のプロセスを通じて開発されています。W3推奨事項トラック（すなわち、標準トラック）には、成熟度の4つのレベルが増加しています。W3Cの推奨事項は、他の組織によって公開されている基準と似ています。（比較：インターネット規格、ISO）
$ worm (I) A computer program that can run independently, can propagate a complete working version of itself onto other hosts on a network, and may consume system resources destructively. (See: mobile code, Morris Worm, virus.)
$ ワーム（i）独立して実行できるコンピュータプログラムは、ネットワーク上の他のホストに自分の完全な作業バージョンを伝播し、システムリソースを破壊的に消費する可能性があります。（監視コード、モリスワーム、ウイルス。）
$ wrap 1. (N) To use cryptography to provide data confidentiality service for keying material. (See: encrypt, wrapping algorithm, wrapping key. Compare: seal, shroud.)
$ 折り返し1.（n）暗号化を使用して、キーイング材料用のデータ機密保持サービスを提供する。（暗号化、折り返しアルゴリズム、包装キー。比較：シール、シュラウド。）
2. (D) To use cryptography to provide data confidentiality service for data in general.
2. （d）一般的なデータのためのデータ機密性サービスを提供するために暗号化を使用する。
Deprecated Usage: IDOCs SHOULD NOT use this term with definition 2 because that duplicates the meaning of the more widely understood "encrypt".
廃止予定の使用法：IDOCは、この用語を定義2で使用しないでください。これは、より広く理解されている「暗号化」の意味を複製します。
$ wrapping algorithm (N) An encryption algorithm that is specifically intended for use in encrypting keys. (See: KEK, wrap.)
$ ラッピングアルゴリズム（n）暗号化キーでの使用を特に意図した暗号化アルゴリズム。（参照：kek、wrap。）
$ wrapping key (N) Synonym for "KEK". (See: encrypt. Compare: seal, shroud.)
$ キー（n） "KEK"の包括的なシノニム。（「暗号化」を参照してください。比較：シール、シュラウド。）
$ write (I) /security model/ A system operation that causes a flow of information from a subject to an object. (See: access mode. Compare: read.)
$ （i）/セキュリティモデル/オブジェクトからオブジェクトへの情報の流れを引き起こすシステム操作。（：アクセスモードを参照してください。比較してください。）
$ WWW (I) See: World Wide Web.
$ www（i）世界ワイドウェブ。
$ X.400 (N) An ITU-T Recommendation [X400] that is one part of a joint ITU-T/ISO multi-part standard (X.400-X.421) that defines the Message Handling Systems. (The ISO equivalent is IS 10021, parts 1-7.) (See: Message Handling Systems.)
$ X.400（n）メッセージ処理システムを定義する共同ITU-T / ISOマルチパート標準（X.400-X.421）の一部であるITU-T勧告[X400]。（ISO等価物は10021、部1~7です）（メッセージ処理システムを参照）
$ X.500 (N) An ITU-T Recommendation [X500] that is one part of a joint ITU-T/ISO multi-part standard (X.500-X.525) that defines the X.500 Directory, a conceptual collection of systems that provide distributed directory capabilities for OSI entities, processes, applications, and services. (The ISO equivalent is IS 9594-1 and related standards, IS 9594-x.) (See: directory vs. Directory, X.509.)
$ X.500（n）X.500ディレクトリを定義する共同ITU-T / ISOマルチパート標準（X.500-X.525）の一部であるITU-T勧告[X500]OSIエンティティ、プロセス、アプリケーション、およびサービスの分散ディレクトリ機能を提供するシステム。（ISOと同等のものは9594-1では9594-Xです。）（ディレクトリ対ディレクトリ、X.509を参照）
Tutorial: The X.500 Directory is structured as a tree (the Directory Information Tree), and information is stored in directory entries. Each entry is a collection of information about one object, and each object has a DN. A directory entry is composed of attributes, each with a type and one or more values. For example, if a PKI uses the Directory to distribute certificates, then the X.509 public-key certificate of an end user is normally stored as a value of an attribute of type "userCertificate" in the Directory entry that has the DN that is the subject of the certificate.
チュートリアル：X.500ディレクトリはツリー（ディレクトリ情報ツリー）として構成されており、情報はディレクトリエントリに格納されています。各エントリは1つのオブジェクトに関する情報の集まりであり、各オブジェクトはDNを持ちます。ディレクトリエントリは、それぞれタイプと1つ以上の値を持つ属性で構成されています。たとえば、PKIがディレクトリを使用して証明書を配布する場合、エンドユーザーのX.509公開鍵証明書は通常、DNがあるディレクトリエントリのタイプ "userCertificate"の属性の値として格納されます。証明書の件名。
$ X.509 (N) An ITU-T Recommendation [X509] that defines a framework to provide and support data origin authentication and peer entity authentication, including formats for X.509 public-key certificates, X.509 attribute certificates, and X.509 CRLs. (The ISO equivalent is IS 9498-4.) (See: X.500.)
$ X.509（n）X.509公開鍵証明書、X.509属性証明書、X.509のフォーマットなど、データオリジナル認証およびピアエンティティ認証を提供およびサポートするためのフレームワークを定義するITU-T勧告[X509]。509 CRL（ISO等価物は9498-4です）（X.500を参照）
Tutorial: X.509 describes two "levels" of authentication: "simple authentication" and "strong authentication". It recommends, "While simple authentication offers some limited protection against unauthorized access, only strong authentication should be used as the basis for providing secure services."
チュートリアル：X.509では、「単純認証」と「強力な認証」という2つの「レベル」が記載されています。「簡単な認証は不正アクセスに対していくつかの限られた保護を提供している間は、強力なサービスを提供するための基礎として強い認証のみを使用する必要があります。」
$ X.509 attribute certificate (N) An attribute certificate in the version 1 (v1) format defined by X.509. (The v1 designation for an X.509 attribute certificate is disjoint from the v1 designation for an X.509 public-key certificate, and from the v1 designation for an X.509 CRL.)
$ X.509属性証明書（n）X.509で定義されたバージョン1（v1）形式の属性証明書。（X.509属性証明書のV1指定は、X.509公開鍵証明書のV1指定から、X.509 CRLのV1指定から除染しています。）
Tutorial: An X.509 attribute certificate has a "subject" field, but the attribute certificate is a separate data structure from that subject's public-key certificate. A subject may have multiple attribute certificates associated with each of its public-key certificates, and an attribute certificate may be issued by a different CA than the one that issued the associated public-key certificate.
チュートリアル：X.509属性証明書には「件名」フィールドがありますが、属性証明書はそのテーマの公開鍵証明書からの個別のデータ構造です。対象は、その公開鍵証明書の各々に関連する複数の属性証明書を有することができ、属性証明書は、関連する公開鍵証明書を発行したものとは異なるCAによって発行されてもよい。
An X.509 attribute certificate contains a sequence of data items and has a digital signature that is computed from that sequence. Besides the signature, an attribute certificate contains items 1 through 9 listed below:
X.509属性証明書には一連のデータ項目が含まれており、そのシーケンスから計算されるデジタル署名があります。署名の他に、属性証明書には以下の項目1から9が含まれています。
1. version Identifies v1. 2. subject Is one of the following: 2a. baseCertificateID Issuer and serial number of an X.509 public-key certificate. 2b. subjectName DN of the subject. 3. issuer DN of the issuer (the CA who signed). 4. signature OID of algorithm that signed the cert. 5. serialNumber Certificate serial number; an integer assigned by the issuer. 6. attCertValidityPeriod Validity period; a pair of UTCTime values: "not before" and "not after".
1. バージョンv1を識別します。2.被験者は次のいずれかです。BaseCertificateID ISSUERおよびX.509公開鍵証明書のシリアル番号。2b。件名のDN。発行者の発行者DN（署名したCA）。4.証明書に署名したアルゴリズムの署名OID。5. SerialNumber証明書のシリアル番号。発行者によって割り当てられた整数。6. AttCertValidityPeriodの有効期間。UTCTIME値のペア： "NOT BEFORE"と "AFTER"。
7. attributes Sequence of attributes describing the subject. 8. issuerUniqueId Optional, when a DN is not sufficient. 9. extensions Optional.
7. 属性件名を記述する属性の順序。8. DNが十分でない場合は、ISSUERUNIQUIEDオプションです。9.拡張機能はオプションです。
$ X.509 certificate (N) Synonym for "X.509 public-key certificate".
$ X.509証明書（N）「X.509公開鍵証明書」の同義語。
Usage: IDOCs MAY use this term as an abbreviation of "X.509 public-key certificate", but only after using the full term at the first instance. Otherwise, the term is ambiguous, because X.509 specifies both public-key certificates and attribute certificates. (See: X.509 attribute certificate, X.509 public-key certificate.)
使用法：IDOCは、この用語を「X.509公開鍵証明書」の略語として使用することができますが、最初のインスタンスで全期間を使用した後にのみ使用できます。それ以外の場合、X.509は公開鍵証明書と属性証明書の両方を指定しているため、この用語はあいまいです。（X.509属性証明書、X.509公開鍵証明書を参照）
Deprecated Usage: IDOCs SHOULD NOT use this term as an abbreviation of "X.509 attribute certificate", because the term is much more commonly used to mean "X.509 public-key certificate" and, therefore, is likely to be misunderstood.
廃止予定の使用法：IDOCは、この用語を「X.509属性証明書」の省略形として使用しないでください。
$ X.509 certificate revocation list (CRL) (N) A CRL in one of the formats defined by X.509 -- version 1 (v1) or version 2 (v2). (The v1 and v2 designations for an X.509 CRL are disjoint from the v1 and v2 designations for an X.509 public-key certificate, and from the v1 designation for an X.509 attribute certificate.) (See: certificate revocation.)
$ X.509証明書失効リスト（CRL）（n）X.509 - バージョン1（v1）またはバージョン2（v2）で定義されている形式の1つのCRL。（X.509 CRLのv1およびv2の指定は、X.509公開鍵証明書のV1およびV2の指定、およびX.509属性証明書のV1指定から除染しています。）（証明書の失効を参照してください。）
Usage: IDOCs SHOULD NOT refer to an X.509 CRL as a digital certificate; however, note that an X.509 CRL does meet this Glossary's definition of "digital certificate". That is, like a digital certificate, an X.509 CRL makes an assertion and is signed by a CA. But instead of binding a key or other attributes to a subject, an X.509 CRL asserts that certain previously issued, X.509 certificates have been revoked.
使用法：IDOCはデジタル証明書としてX.509 CRLを参照してはいけません。ただし、X.509 CRLはこの用語集の「デジタル証明書」の定義を満たしていることに注意してください。つまり、デジタル証明書のように、X.509 CRLはアサーションを行い、CAによって署名されています。しかし、キーまたは他の属性を件名にバインドする代わりに、以前に発行された特定のX.509証明書が取り消されたことをアサートします。
Tutorial: An X.509 CRL contains a sequence of data items and has a digital signature computed on that sequence. Besides the signature, both v1 and v2 contain items 2 through 6b listed below. Version 2 contains item 1 and may optionally contain 6c and 7.
チュートリアル：X.509 CRLには一連のデータ項目が含まれており、そのシーケンスでデジタル署名が計算されています。署名の他に、V1とV2の両方に、以下に示す項目2から6Bが含まれています。バージョン2は項目1を含み、任意選択で6Cと7を含み得る。
1. version Optional. If present, identifies v2. 2. signature OID of the algorithm that signed CRL. 3. issuer DN of the issuer (the CA who signed). 4. thisUpdate A UTCTime value. 5. nextUpdate A UTCTime value. 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: 6a. userCertificate A certificate's serial number. 6b. revocationDate UTCTime value for the revocation date. 6c. crlEntryExtensions Optional.
1. バージョンオプションです。存在する場合は、V2を識別します。2. CRLに署名したアルゴリズムの署名OID。発行者の発行者DN（署名したCA）。4. UTCTIME値を更新します。5. UTCTIME値をnextDate。6. 6A、6B、および（オプション）6C：6Aの3タプルを取り消した。userCertificate Certificateのシリアル番号。6b。失効日のrevocationDate utctime値。6c。CrleNtryExtensionsオプションです。
7. crlExtensions Optional.
7. Crlextensionsオプションです。
$ X.509 public-key certificate (N) A public-key certificate in one of the formats defined by X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The v1 and v2 designations for an X.509 public-key certificate are disjoint from the v1 and v2 designations for an X.509 CRL, and from the v1 designation for an X.509 attribute certificate.)
$ X.509公開鍵証明書（n）X.509 - バージョン1（v1）、バージョン2（v2）、またはバージョン3（v3）で定義された形式の1つの公開鍵証明書。（X.509公開鍵証明書のV1とV2の指定は、X.509 CRLのV1およびV2の指定、およびX.509属性証明書のV1指定からの除用されます。）
Tutorial: An X.509 public-key certificate contains a sequence of data items and has a digital signature computed on that sequence. Besides the signature, all three versions contain items 1 through 7 listed below. Only v2 and v3 certificates may also contain items 8 and 9, and only v3 may contain item 10.
チュートリアル：X.509公開鍵証明書には一連のデータ項目が含まれており、そのシーケンスにデジタル署名が計算されています。署名の他に、3つのバージョンすべてには以下の項目1から7が含まれています。v2とv3証明書のみを含めることができ、v3のみが項目10を含み得る。
1. version Identifies v1, v2, or v3. 2. serialNumber Certificate serial number; an integer assigned by the issuer. 3. signature OID of algorithm that was used to sign the certificate. 4. issuer DN of the issuer (the CA who signed). 5. validity Validity period; a pair of UTCTime values: "not before" and "not after". 6. subject DN of entity who owns the public key. 7. subjectPublicKeyInfo Public key value and algorithm OID. 8. issuerUniqueIdentifier Defined for v2, v3; optional. 9. subjectUniqueIdentifier Defined for v2, v2; optional. 10. extensions Defined only for v3; optional.
1. バージョンv1、v2、またはv3を識別します。2.シリアル番号証明書のシリアル番号。発行者によって割り当てられた整数。3.証明書に署名するために使用されたアルゴリズムの署名OID。4.発行者の発行者DN（署名したCA）。有効性の妥当性期間。UTCTIME値のペア： "NOT BEFORE"と "AFTER"。6.公開鍵を所有するエンティティのサブジェクトDN。7. SubjectPublicKeyInfo公開鍵の値とアルゴリズムOID。8. V2、V3に定義されているISSUERUNIQUIQUIXIDERIFIER。オプションです。9. V2、V2用に定義されたMapteryUniquiqueIdentifier。オプションです。10.拡張機能はV3に対してのみ定義されます。オプションです。
$ X9 (N) See: "Accredited Standards Committee X9" under "ANSI".
$ X9（N）「ANSI」の「認定標準委員会X9」を参照してください。
$ XML (N) See: Extensible Markup Language.
$ XML（N）参照：拡張マークアップ言語。
$ XML-Signature. (N) A W3C Recommendation (i.e., approved standard) that specifies XML syntax and processing rules for creating and representing digital signatures (based on asymmetric cryptography) that can be applied to any digital content (i.e., any data object) including other XML material.
$ XMLシグネチャ（n）他のXML素材を含む任意のデジタルコンテンツ（すなわち、任意のデータオブジェクト）に適用できるデジタルシグネチャを作成および表現するためのXML構文および処理規則を指定するXML構文および処理規則を指定するW3C勧告（すなわち承認済み標準）。
$ Yellow Book (D) /slang/ Synonym for "Computer Security Requirements: Guidance for Applying the [U.S.] Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments" [CSC3] (See: "first law" under "Courtney's laws".) Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for that or any other document. Instead, use the full proper name of the document or, in subsequent references, a conventional abbreviation. (See: Deprecated Usage under "Green Book", Rainbow Series.)
$黄色い本（D）/ Slang / Sylant / Synon 'の「コンピュータセキュリティ要件：具体的な環境での国防総省信頼できるコンピュータシステム評価基準」[CSC3]（「Courtney's Laws」の下にある「最初の法律」を参照してください。。）廃止予定語：IDocは、この用語をその同義語として使用しないでください。代わりに、文書の完全な正しい名前、または後続の参照では、従来の略語を使用してください。（「グリーンブック」、レインボーシリーズの下での使用済みの使用法を参照）
$ zero-knowledge proof (I) /cryptography/ A proof-of-possession protocol whereby a system entity can prove possession of some information to another entity, without revealing any of that information. (See: proof-of-possession protocol.)
$ ゼロナレッジプルーフ（I）/暗号化/保有証明プロトコルによって、システムエンティティはその情報のいずれかを明らかにすることなく、ある情報を別のエンティティに所有することを証明することができます。（PROSSCENDプロトコルを参照）
$ zeroize 1. (I) Synonym for "erase". (See: sanitize.) Usage: Particularly with regard to erasing keys that are stored in a cryptographic module.
$ ゼロ化1.（i）「消去」の同義語。（参照：サニタイズ。）使用法：特に暗号化モジュールに保存されているキーの消去に関して。
2. (O) Erase electronically stored data by altering the contents of the data storage so as to prevent the recovery of the data. [FP140]
2. （O）データの回復を防ぐために、データ記憶装置の内容を変更することで電子的に記憶されたデータを消去する。[FP140]
3. (O) "To remove or eliminate the key from a cryptoequipment or fill device." [C4009]
3. （O）「暗号不足または塗りつぶし装置からキーを取り外すか排除する」。[C4009]
Usage: The phrase "zeroize the device" normally is used to mean erasing all keys stored in the device, but sometimes means erasing all keying material in the device, or all cryptographic information in the device, or even all sensitive information in the device.
使用法：「デバイスをゼロ化する」というフレーズは通常、デバイスに格納されているすべてのキーを消去するために使用されますが、デバイス内のすべてのキーイングマテリアル、またはデバイス内のすべての暗号化情報、またはデバイス内のすべての機密情報でさえ、すべてのキーワードの資料、またはすべての暗号化情報を消去することを意味します。
$ zombie (I) /slang/ An Internet host computer that has been surreptitiously penetrated by an intruder that installed malicious daemon software to cause the host to operate as an accomplice in attacking other hosts, particularly in distributed attacks that attempt denial of service through flooding.
$ ゾンビ（I）/スラング/スラング/インターネットホストコンピュータは、特に洪水を通じてサービス拒否を試みる分散型攻撃で、悪意のあるデーモンソフトウェアをインストールした侵入者によって侵入しています。
Deprecated Usage: Other cultures likely use different metaphorical terms (such as "robot") for this concept, and some use this term for different concepts. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. Instead, use "compromised, coopted computer" or other explicitly descriptive terminology. (See: Deprecated Usage under "Green Book".)
廃止予定の使用法：その他の文化は、この概念のためのさまざまな比喩的な用語（「ロボット」など）を使用している可能性があり、異なる概念についてはこの用語を使用しています。したがって、国際誤解を避けるために、IDocはこの用語を使用しないでください。代わりに、「侵害された、協力的なコンピュータ」またはその他の明示的に説明的な用語を使用してください。（「グリーンブック」の「廃止予定の使用」。）
$ zone of control (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: TEMPEST.)
$ 「検査可能なスペース」の制御範囲（O）/ EMSEC /同義語。[C4009]（テンペストを参照）
This document mainly defines security terms and recommends how to use them. It also provides limited tutorial information about security aspects of Internet protocols, but it does not describe in detail the vulnerabilities of, or threats to, specific protocols and does not definitively describe mechanisms that protect specific protocols.
この文書は主にセキュリティ条件を定義し、それらの使用方法を推奨します。インターネットプロトコルのセキュリティ側面に関するチュートリアル情報も限られていますが、特定のプロトコルの脆弱性、または脅威の脆弱性、または特定のプロトコルを保護するメカニズムを明確に記述していないことを説明しません。
[R2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[R2119] Bradner、S。、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
This Glossary focuses on the Internet Standards Process. Therefore, this set of informative references emphasizes international, governmental, and industrial standards documents. Some RFCs that are especially relevant to Internet security are mentioned in Glossary entries in square brackets (e.g., "[R1457]" in the entry for "security label") and are listed here; some other RFCs are mentioned in parentheses (e.g., "(RFC 959)" in the entry for "File Transport Protocol") but are not listed here.
この用語集はインターネット標準プロセスに焦点を当てています。したがって、この一連の有益な参考文献は、国際、政府、および産業標準書類を強調しています。インターネットセキュリティに特に関連するいくつかのRFCは、「セキュリティラベル」のエントリ内の角括弧内の用語集エントリ（例えば、「[R1457] "で述べられており、ここにリストされています。他のいくつかのRFCは、「ファイルトランスポートプロトコル」のエントリ内の括弧内（例えば、「（RFC 959）」で述べられているが、ここにはリストされていない。
[A1523] American National Standards Institute, "American National Standard Telecom Glossary", ANSI T1.523-2001.
[A1523]アメリカの国家規格研究所「アメリカナショナルスタンダードテレコム用語集」、ANSI T1.523-2001。
[A3092] ---, "American National Standard Data Encryption Algorithm",
ANSI X3.92-1981, 30 December 1980.
[A9009] ---, "Financial Institution Message Authentication
(Wholesale)", ANSI X9.9-1986, 15 August 1986.
[A9017] ---, "Financial Institution Key Management (Wholesale)",
X9.17, 4 April 1985. (Defines procedures for manual and
automated management of keying material and uses DES to
provide key management for a variety of operational
environments.)
[A9042] ---, "Public key Cryptography for the Financial Service
Industry: Agreement of Symmetric Keys Using Diffie-Hellman
and MQV Algorithms", X9.42, 29 January 1999. (See: Diffie-
Hellman-Merkle.)
[A9052] ---, "Triple Data Encryption Algorithm Modes of Operation",
X9.52-1998, ANSI approval 9 November 1998.
[A9062] ---, "Public Key Cryptography for the Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", X9.62-1998, ANSI approval 7 January 1999.
[A9063] ---, "Public Key Cryptography for the Financial Services
Industry: Key Agreement and Key Transport Using Elliptic
Curve Cryptography", X9.63-2001.
[ACM] Association for Computing Machinery, "Communications of the ACM", July 1998 issue with: M. Yeung, "Digital Watermarking"; N. Memom and P. Wong, "Protecting Digital Media Content"; and S. Craver, B.-L. Yeo, and M. Yeung, "Technical Trials and Legal Tribulations".
[ACM]計算機協会、「ACMの通信」、1998年7月の号：M. Yeung、 "Digital Watermarking";N. MemomおよびP.Wong、「デジタルメディアコンテンツの保護」。そしてS. Craver、B.L.ヨー、そしてM. Yeung、「技術試験と法的苦動物」。
[Ande] Anderson, J., "Computer Security Technology Planning Study", ESD-TR-73-51, Vols. I and II, USAF Electronics Systems Div., Bedford, MA, October 1972. (Available as AD-758206/772806, National Technical Information Service, Springfield, VA.)
[Ande] Anderson、J.、「コンピュータセキュリティ技術計画調査」、ESD-TR-73-51、VOL。IUSおよびII、ISAF電子システムDIV。1972年10月、Bedford、Bedford（AD-758206/772806、National Technical Information Service、Spring Field、VA）
[ANSI] American National Standards Institute, "Role Based Access Control", Secretariat, Information Technology Industry Council, BSR INCITS 359, DRAFT, 10 November 2003.
[ANSI]アメリカ国立規格研究所、「役割ベースのアクセス制御」、事務局、情報技術産業協議会、BSRは359、ドラフト、2003年11月10日。
[Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP) and Tempest Protection for Facilities", EP 1110-3-2, 31 December 1990.
[陸軍]エンジニアの米軍隊、「電磁パルス（EMP）および施設のための温度保護」、EP 1110-3-2、1990年12月31日。
[B1822] Bolt Baranek and Newman Inc., "Appendix H: Interfacing a Host to a Private Line Interface", in "Specifications for the Interconnection of a Host and an IMP", BBN Report No. 1822, revised, December 1983.
[B1822] Bolt Baranek and Newman Inc.、「付録H：専用回線インタフェースへのインタフェース」、「ホストとIMPの相互接続の仕様」、BBNレポート番号1822、1983年12月改訂。
[B4799] ---, "A History of the Arpanet: The First Decade", BBN
Report No. 4799, April 1981.
[Bell] Bell, D. and L. LaPadula, "Secure Computer Systems: Mathematical Foundations and Model", M74-244, The MITRE Corporation, Bedford, MA, May 1973. (Available as AD-771543, National Technical Information Service, Springfield, VA.)
[ベル]ベル、D.およびL. LAPADULA「安全なコンピュータシステム：数学基礎およびモデル」、M74-244、MATER CORPORATION、MA、MA、MA、MA、MA。スプリングフィールド、VA。）
[Biba] K. Biba, "Integrity Considerations for Secure Computer Systems", ESD-TR-76-372, USAF Electronic Systems Division, Bedford, MA, April 1977.
【双和】【双子】Biba、MA、MA、MA、Bedford、ESD-TR-76-372、USAF電子システム事業部の「完全性に関する考察」。
[BN89] Brewer, D. and M. Nash, "The Chinese wall security policy", in "Proceedings of IEEE Symposium on Security and Privacy", May 1989, pp. 205-214.
[BN89] Brewer、D.およびM. Nash、「中国の壁のセキュリティポリシー」、「セキュリティとプライバシーに関するIEEEシンポジウムの議事録」、1989年5月、PP。205-214。
[BS7799] British Standards Institution, "Information Security Management, Part 1: Code of Practice for Information Security Management", BS 7799-1:1999, 15 May 1999.
[BS7799]イギリス標準機関、「情報セキュリティ管理、パート1：情報セキュリティ管理のための実践規範」、BS 7799-1：1999,1999。
---, "Information Security Management, Part 2: Specification
for Information Security Management Systems", BS 7799-
2:1999, 15 May 1999.
[C4009] Committee on National Security Systems (U.S. Government), "National Information Assurance (IA) Glossary", CNSS Instruction No. 4009, revised June 2006.
[C4009]国家セキュリティシステム（米国政府）、「国家情報保証（IA）用語集」、CNSS指導番号4009、2006年6月改訂。
[CCIB] Common Criteria Implementation Board, "Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model", version 2.0, CCIB-98-026, May 1998.
[CCIB]一般的な基準実装委員会、「情報技術セキュリティ評価のための一般的な基準、第1部：紹介および一般モデル」、バージョン2.0、CCIB-98-026、1998年5月。
[Chau] D. Chaum, "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", in "Communications of the ACM", vol. 24, no. 2, February 1981, pp. 84-88.
[Chau] D. Chaum、「ACMの通信」、「ACMの通信」24、いいえ。1981年2月2日、PP。84-88。
[Cheh] Cheheyl, M., Gasser, M., Huff, G., and J. Millen, "Verifying Security", in "ACM Computing Surveys", vol. 13, no. 3, September 1981, pp. 279-339.
[Cheh] Cheheyl、M.、Gasser、M.、Huff、G.、およびJ. Millen、「セキュリティの検証」、「ACMコンピューティングSurveys」、Vol。13、いいえ。3、1981年9月、PP.279-339。
[Chris] Chrissis, M. et al, 1993. "SW-CMM [Capability Maturity Model for Software Version", Release 3.0, Software Engineering Institute, Carnegie Mellon University, August 1996.
[CHRIS] Chrissis、M。ら、1993. 1996年8月の「SW-CMM [ソフトウェア版のソフトウェア版の能力満期モデル）、ソフトウェアエンジニアリング研究所、Carnegie Mellon University。
[CIPSO] Trusted Systems Interoperability Working Group, "Common IP Security Option", version 2.3, 9 March 1993.
[CIPSO]信頼できるシステム相互運用性ワーキンググループ、「共通IPセキュリティオプション」、バージョン2.3,9993。
[Clark] Clark, D. and D. Wilson, "A Comparison of Commercial and Military computer Security Policies", in "Proceedings of the IEEE Symposium on Security and Privacy", April 1987, pp. 184-194.
[Clark] Clark、D.およびD.ウィルソン、「コマーシャルコンピュータセキュリティポリシーの比較」、「セキュリティとプライバシーに関するIEEEシンポジウムの議事録」、1987年4月、PP 184-194。
[Cons] NSA, "Consistency Instruction Manual for Development of U.S. Government Protection Profiles for Use in Basic Robustness Environments", Release 2.0, 1 March 2004
[CONS] NSA、「基本的なロバストネス環境での使用のための米国政府保護プロファイルの開発のための一貫性取扱説明書」、リリース2.0,2004
[CORBA] Object Management Group, Inc., "CORBAservices: Common Object Service Specification", December 1998.
[CORBA] Object Management Group、Inc。、「Corbaservices：Common Object Service Specification」、1998年12月。
[CSC1] U.S. DoD Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", CSC-STD-001- 83, 15 August 1983. (Superseded by [DoD1].)
[CSC1]米国のDODコンピュータセキュリティセンター、「国防信託コンピュータシステム評価基準部門」、CSC-STD-001- 83,15983、1983年8月15日。（DOD1）
[CSC2] ---, "Department of Defense Password Management Guideline",
CSC-STD-002-85, 12 April 1985.
[CSC3] ---, "Computer Security Requirements: Guidance for Applying
the Department of Defense Trusted Computer System Evaluation
Criteria in Specific Environments", CSC-STD-003-85, 25 June
1985.
[CSOR] U.S. Department of Commerce, "General Procedures for Registering Computer Security Objects", National Institute of Standards Interagency Report 5308, December 1993.
[CSOR]米国米国規格標準協会ターミーレポート5308、1993年12月の「コンピュータセキュリティオブジェクト登録のための一般的な手順」
[Daem] Daemen, J. and V. Rijmen, "Rijndael, the advanced encryption standard", in "Dr. Dobb's Journal", vol. 26, no. 3, March 2001, pp. 137-139.
[DAEM]デーメン、J.およびV.Rijmen、 "Rijndael、Advanced Encryption Standard"、 "Dr. Dobb's Journal"、Vol。26、いいえ。2001年3月3日、PP。137-139。
[DC6/9] Director of Central Intelligence, "Physical Security Standards for Sensitive Compartmented Information Facilities", DCI Directive 6/9, 18 November 2002.
[DC6 / 9]中央知性のディレクター「敏感なコンパートメント情報施設のための物理的なセキュリティ基準」、DCI指令6/9、2002年11月18日。
[Denn] Denning, D., "A Lattice Model of Secure Information Flow", in "Communications of the ACM", vol. 19, no. 5, May 1976, pp. 236-243.
[Den] Denning、D、「安全な情報フローの格子モデル」、「ACMの通信」、Vol。19、いいえ。1976年5月5日、PP。236-243。
[Denns] Denning, D. and P. Denning, "Data Security", in "ACM Computing Surveys", vol. 11, no. 3, September 1979, pp. 227- 249.
[Dens] Denning、D.およびP.「ACMコンピューティングSurveys」、「データセキュリティ」、Vol。11、いいえ。3、1979年9月、PP。227-249。
[DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", in "IEEE Transactions on Information Theory", vol. IT-22, no. 6, November 1976, pp. 644-654. (See: Diffie-Hellman-Merkle.)
[DH76] Diffie、W.およびM. Hellman、「暗号化における新しい方向」、「情報理論のIEEE取引」、vol。IT-22、いいえ。1976年11月6日、PP。644-654。（参照：Diffie-Hellman-Merkle。）
[DoD1] U.S. DoD, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, 26 December 1985. (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.)
[DOD1] DOD、「国防信託コンピュータシステム評価基準部」、DOD 5200.28-STD、1985年12月26日。（Superess【CSC1】）
[DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 June 1998.
[DoD5] ---, Directive 5200.1, "DoD Information Security Program",
13 December 1996.
[DoD6] ---, "Department of Defense Technical Architecture Framework
for Information Management, Volume 6: Department of Defense
(DoD) Goal Security Architecture", Defense Information
Systems Agency, Center for Standards, version 3.0, 15 April
1996.
[DoD7] ---, "X.509 Certificate Policy for the United States
Department of Defense", version 7, 18 December 2002.
(Superseded by [DoD9].)
[DoD9] ---, "X.509 Certificate Policy for the United States
Department of Defense", version 9, 9 February 2005.
[DoD10] ---, "DoD Architecture Framework, Version 1: Deskbook", 9
February 2004.
[DSG] American Bar Association, "Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce", Chicago, IL, 1 August 1996. (See: [PAG].)
[DSG]アメリカのバー協会「デジタルシグネチャガイドライン：認証当局および安全な電子商取引のための法基領」、1996年8月1日（【参照）
[ElGa] El Gamal, T., "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms", in "IEEE Transactions on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- 472.
[ELGA] EL Gamal、T.、「ディスクリート対数に基づく公開鍵暗号システムと署名方式」、「情報理論のIEEEトランザクション」IT-31、いいえ。4,1985、PP。469- 472。
[EMV1] Europay International S.A., MasterCard International Incorporated, and Visa International Service Association, "EMV '96 Integrated Circuit Card Specification for Payment Systems", version 3.1.1, 31 May 1998.
[EMV1] Europay International Incorporated、Visa International Service Association、「EMV '96支払いシステムのための総合回路カード仕様」、バージョン3.1.1,31、1998年5月31日。
[EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification
for Payment Systems", version 3.1.1, 31 May 1998.
[EMV3] ---, "EMV '96 Integrated Circuit Card Application
Specification for Payment Systems", version 3.1.1, 31 May
1998.
[F1037] U.S. General Services Administration, "Glossary of Telecommunications Terms", FED STD 1037C, 7 August 1996.
【F1037】米国概要サービス管理、「電気通信用語の用語集」、STD 1037C、1996年8月7日。
[For94] Ford, W., "Computer Communications Security: Principles, Standard Protocols and Techniques", ISBN 0-13-799453-2, 1994.
[for94]フォード、W。、「コンピュータ通信セキュリティ：原則、標準プロトコルおよびテクニック」、ISBN 0-13-799453-2,1994。
[For97] --- and M. Baum, "Secure Electronic Commerce: Building the
Infrastructure for Digital Signatures and Encryption", ISBN
0-13-476342-4, 1994.
[FP001] U.S. Department of Commerce, "Code for Information Interchange", Federal Information Processing Standards Publication (FIPS PUB) 1, 1 November 1968.
[FP001]米国コマース、「情報交換のコード」、連邦情報処理規格（FIPS PUB）1,111月1日。
[FP031] ---, "Guidelines for Automatic Data Processing Physical
Security and Risk Management", FIPS PUB 31, June 1974.
[FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39,
15 February 1976.
[FP041] ---, "Computer Security Guidelines for Implementing the
Privacy Act of 1974", FIPS PUB 41, 30 May 1975.
[FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25
October 1999.
[FP074] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25
October 1999.
[FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 December 1980.
[FP087] ---, "Guidelines for ADP Contingency Planning", FIPS PUB 87,
27 March 1981.
[FP102] ---, "Guideline for Computer Security Certification and
Accreditation", FIPS PUB 102, 27 September 1983.
[FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May
1985.
[FP140] ---, "Security Requirements for Cryptographic Modules", FIPS
PUB 140-2, 25 May 2001; with change notice 4, 3 December
2002.
[FP151] ---, "Portable Operating System Interface (POSIX) -- System
Application Program Interface [C Language]", FIPS PUB 151-2,
12 May 1993
[FP180] ---, "Secure Hash Standard", FIPS PUB 180-2, August 2000;
with change notice 1, 25 February 2004.
[FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9
February 1994.
[FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186-2, 27
June 2000; with change notice 1, 5 October 2001.
[FP188] ---, "Standard Security Label for Information Transfer",
FIPS PUB 188, 6 September 1994.
[FP191] ---, "Guideline for the Analysis of Local Area Network
Security", FIPS PUB 191, 9 November 1994.
[FP197] ---, "Advanced Encryption Standard", FIPS PUB 197, 26
November 2001.
[FP199] ---, "Standards for Security Categorization of Federal
Information and Information Systems ", FIPS PUB 199,
December 2003.
[FPKI] ---, "Public Key Infrastructure (PKI) Technical
Specifications: Part A -- Technical Concept of Operations",
NIST, 4 September 1998.
[Gass] Gasser, M., "Building a Secure Computer System", Van Nostrand Reinhold Company, New York, 1988, ISBN 0-442- 23022-2.
[GASS]ガッサー、M.、「安全なコンピュータシステムの構築」、ヴァンノストランドReinhold Company、ニューヨーク、1988年、ISBN 0-442-23022-2。
[Gray] Gray, J. and A. Reuter, "Transaction Processing: Concepts and Techniques", Morgan Kaufmann Publishers, Inc., 1993.
[グレー]グレイ、J.およびA.Reuter、「取引処理：概念とテクニック」、Morgan Kaufmann Publishers、Inc。
[Hafn] Hafner, K. and M. Lyon, "Where Wizards Stay Up Late: The Origins of the Internet", Simon & Schuster, New York, 1996.
[HAFN] Hafner、K.およびM.リヨン、「ウィザードは遅く遅くに滞在する：インターネットの起源」、Simon＆Schuster、ニューヨーク、1996年。
[Huff] Huff, G., "Trusted Computer Systems -- Glossary", MTR 8201, The MITRE Corporation, March 1981.
[HUFF]ハフ、G.、「信頼できるコンピュータシステム - グロッサリ」、MTR 8201、Miter Corporation 1981年3月。
[I3166] International Standards Organization, "Codes for the Representation of Names of Countries and Their Subdivisions, Part 1: Country Codes", ISO 3166-1:1997.
[I3166]国際規格機関、「国の名前とその区別の表現のコード、第1章国コード」、ISO 3166-1：1997。
---, "Codes for the Representation of Names of Countries and
Their Subdivisions, Part 2: Country Subdivision Codes",
ISO/DIS 3166-2.
---, "Codes for the Representation of Names of Countries and
Their Subdivisions, Part 3: Codes for Formerly Used Names of
Countries", ISO/DIS 3166-3.
[I7498-1] ---, "Information Processing Systems -- Open Systems
Interconnection Reference Model, [Part 1:] Basic Reference
Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation
X.200.)
[I7498-2] ---, "Information Processing Systems -- Open Systems
Interconnection Reference Model, Part 2: Security
Architecture", ISO/IEC 7499-2.
[I7498-4] ---, "Information Processing Systems -- Open Systems
Interconnection Reference Model, Part 4: Management
Framework", ISO/IEC 7498-4.
[I7812] ---, "Identification cards -- Identification of Issuers,
Part 1: Numbering System", ISO/IEC 7812-1:1993
---, "Identification cards -- Identification of Issuers,
Part 2: Application and Registration Procedures", ISO/IEC
7812-2:1993.
[I8073] ---, "Information Processing Systems -- Open Systems
Interconnection, Transport Protocol Specification", ISO IS
8073.
[I8327] ---, "Information Processing Systems -- Open Systems
Interconnection, Session Protocol Specification", ISO IS
8327.
[I8473] ---, "Information Processing Systems -- Open Systems
Interconnection, Protocol for Providing the Connectionless
Network Service", ISO IS 8473.
[I8802-2] ---, "Information Processing Systems -- Local Area
Networks, Part 2: Logical Link Control", ISO IS 8802-2.
(Equivalent to IEEE 802.2.)
[I8802-3] ---, "Information Processing Systems -- Local Area
Networks, Part 3: Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and Physical
Layer Specifications", ISO IS 8802-3. (Equivalent to IEEE
802.3.)
[I8823] ---, "Information Processing Systems -- Open Systems
Interconnection -- Connection-Oriented Presentation Protocol
Specification", ISO IS 8823.
[I9945] "Portable Operating System Interface for Computer Environments", ISO/IEC 9945-1: 1990.
[I9945]「コンピュータ環境用のポータブルオペレーティングシステムインタフェース」、ISO / IEC 9945-1：1990。
[IATF] NSA, "Information Assurance Technical Framework", Release 3, NSA, September 2000. (See: IATF.)
[IATF] NSA、「情報保証技術枠組み」、2000年9月、NSA、NSA、NSA。（IATFを参照）
[IDSAN] ---, "Intrusion Detection System Analyzer Protection
Profile", version 1.1, NSA, 10 December 2001.
[IDSSC] ---, "Intrusion Detection System Scanner Protection
Profile", version 1.1, NSA, 10 December 2001.
[IDSSE] ---, "Intrusion Detection System Sensor Protection Profile",
version 1.1, NSA, 10 December 2001.
[IDSSY] ---, "Intrusion Detection System", version 1.4, NSA, 4
February 2002.
[Ioan] Ioannidis, J. and M. Blaze, "The Architecture and Implementation of Network Layer Security in UNIX", in "UNIX Security IV Symposium", October 1993, pp. 29-39.
[IOAN] Ioannidis、J.およびM. Blaze、1993年10月、1993年10月、PP。29-39。
[ITSEC] "Information Technology Security Evaluation Criteria (ITSEC): Harmonised Criteria of France, Germany, the Netherlands, and the United Kingdom", version 1.2, U.K. Department of Trade and Industry, June 1991.
[ITSEC]「ITSEC」「情報技術セキュリティ評価基準（ITSEC）：フランス、ドイツ、オランダ、イギリスの調和基準、バージョン1.2、米国貿易産業省、1991年6月。
[JP1] U.S. DoD, "Department of Defense Dictionary of Military and Associated Terms", Joint Publication 1-02, as amended through 13 June 2007.
[JP1]米国のDOD、「軍事と関連条件の防衛辞典」、2007年6月13日までに修正されたジョイント出版物1-02。
[John] Johnson, N. and S. Jajodia, "Exploring Steganography; Seeing the Unseen", in "IEEE Computer", February 1998, pp. 26-34.
[John] Johnson、N.およびS.Jajodia、「ステガノグラフィの探索」、1998年2月、1998年2月、PP.26-34。
[Kahn] Kahn, D., "The Codebreakers: The Story of Secret Writing", The Macmillan Company, New York, 1967.
[Kahn] Kahn、D.、「コードブレーカー：秘密の執筆の物語」、Macmillan Company、ニューヨーク、1967年。
[Knut] Knuth, D., Chapter 3 ("Random Numbers") of Volume 2 ("Seminumerical Algorithms") of "The Art of Computer Programming", Addison-Wesley, Reading, MA, 1969.
[Knut]ノード2（「コンピュータプログラミングの芸術」、Addison-Wesley、Reading、MA、1969年の「常時アルゴリズム」の第3章（「乱数」）。
[Kuhn] Kuhn, M. and R. Anderson, "Soft Tempest: Hidden Data Transmission Using Electromagnetic Emanations", in David Aucsmith, ed., "Information Hiding, Second International Workshop, IH'98", Portland, Oregon, USA, 15-17 April 1998, LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142.
[Kuhn] Kuhn、M.およびR. Anderson、「ソフトテンペスト：電磁放散を使用した隠しデータ伝送」、「情報隠し、第2回国際ワークショップ、IH'98」、ポートランド、オレゴン州、アメリカ、15-17 1998年4月、LNCS 1525、Springer-Verlag、ISBN 3-540-65386-4、PP。124-142。
[Land] Landwehr, C., "Formal Models for Computer Security", in "ACM Computing Surveys", vol. 13, no. 3, September 1981, pp. 247- 278.
[Land] Landwehr、C.、「コンピュータセキュリティのための形式モデル」、「ACMコンピューティングSurveys」、Vol。13、いいえ。3、1981年9月、PP。247-278。
[Larm] Larmouth, J., "ASN.1 Complete", Open System Solutions, 1999 (a freeware book).
[LARM]ラーマス、J.、「ASN.1完全」、オープンシステムソリューション、1999年（フリーウェアブック）。
[M0404] U.S. Office of Management and Budget, "E-Authentication Guidance for Federal Agencies", Memorandum M-04-04, 16 December 2003.
[M0404]米国マネジメントおよび予算の局、「連邦機関のe認証ガイダンス」、覚書M-04-04、2003年12月16日。
[Mene] Menezes, A. et al, "Some Key Agreement Protocols Providing Implicit Authentication", in "The 2nd Workshop on Selected Areas in Cryptography", 1995.
[Mene] Menezes、A. et al、「暗黙認証を提供するいくつかの主な合意プロトコル」、1995年の「選択された地域の第2ワークショップ」。
[Moor] Moore, A. et al, "Attack Modeling for Information Security and Survivability", Carnegie Mellon University / Software Engineering Institute, CMU/SEI-2001-TN-001, March 2001.
[ムーア]ムーア、A. et al、「情報セキュリティおよび生存率のための攻撃モデリング」、CARNEGIE Mellon University / Software Engineering Institute、CMU / SEI-2001-TN-001、2001年3月。
[Murr] Murray, W., "Courtney's Laws of Security", in "Infosecurity News", March/April 1993, p. 65.
[MURR]マレー、W。、「Courtney's Securitys」、「InfoSecurity News」、1993年3月、P。65。
[N4001] National Security Telecommunications and Information System Security Committee, "Controlled Cryptographic Items", NSTISSI No. 4001, 25 March 1985.
[N4001]国家安全保障電気通信および情報システムセキュリティ委員会、「制御暗号アイテム」、Nstissi No.4001,2985。
[N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2
December 1991.
[N7003] ---, "Protective Distribution Systems", NSTISSI No. 7003, 13
December 1996.
[NCS01] National Computer Security Center, "A Guide to Understanding Audit in Trusted Systems", NCSC-TG-001, 1 June 1988. (See: Rainbow Series.)
[NCS01] National Computer Security Center、「信頼できるシステムにおける監査を理解するためのガイド」、NCSC-TG-001、1988年6月1日（レインボーシリーズ参照）。
[NCS03] ---, "Information System Security Policy Guideline", I942-
TR-003, version 1, July 1994. (See: Rainbow Series.)
[NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004,
version 1, 21 October 1988. (See: Rainbow Series.)
[NCS05] ---, "Trusted Network Interpretation of the Trusted Computer
System Evaluation Criteria", NCSC-TG-005, version 1, 31 July
1987. (See: Rainbow Series.)
[NCS25] ---, "A Guide to Understanding Data Remanence in Automated
Information Systems", NCSC-TG-025, version 2, September
1991. (See: Rainbow Series.)
[NCSSG] National Computer Security Center, "COMPUSECese: Computer Security Glossary", NCSC-WA-001-85, Edition 1, 1 October 1985. (See: Rainbow Series.)
[NCSSG] National Computer Security Center、「Compusecese：Computer Security Glossary」、NCSC-WA-001-85、第1版1985年10月1日（レインボーシリーズ参照）
[NRC91] National Research Council, "Computers At Risk: Safe Computing in the Information Age", National Academy Press, 1991.
[NRC91]国立研究評議会、「リスクのコンピュータ：情報時代の安全なコンピューティング」、国立アカデミープレス、1991年。
[NRC98] Schneider, F., ed., "Trust in Cyberspace", National Research Council, National Academy of Sciences, 1998.
[NRC98] Schneider、F.、Ed。、国立科学アカデミー、1998年の国立研究評議会、「サイバースペースの信頼」。
[Padl] Padlipsky, M., "The Elements of Networking Style", 1985, ISBN 0-13-268111-0.
[PADL] Padlipsky、M.、1985年、1985年、ISBN 0-13-268111-0。
[PAG] American Bar Association, "PKI Assessment Guidelines", version 1.0, 10 May 2002. (See: [DSG].)
[PAG]アメリカンバー協会「PKIアセスメントガイドライン」、バージョン1.0,2002年5月10日。（参照：[DSG]参照）
[Park] Parker, D., "Computer Security Management", ISBN 0-8359- 0905-0, 1981
[公園]パーカー、D.、「コンピュータセキュリティ管理」、ISBN 0-8359-0905-0,1981
[Perr] Perrine, T. et al, "An Overview of the Kernelized Secure Operating System (KSOS)", in "Proceedings of the 7th DoD/NBS Computer Security Conference", 24-26 September 1984.
[Perr] Perrine、T。ら、「カーネル化された安全なオペレーティングシステム（KSOS）の概要」、「第7回DOD / NBSコンピュータセキュリティ会議」、1984年9月24日から26日。
[PGP] Garfinkel, S.. "PGP: Pretty Good Privacy", O'Reilly & Associates, Inc., Sebastopol, CA, 1995.
[PGP] Garfinkel、S ..「PGP：かなり良いプライバシー」、O'Reilly＆Associates、Inc。、Sebastopol、CA、1995。
[PKCS] Kaliski Jr., B., "An Overview of the PKCS Standards", RSA Data Security, Inc., 3 June 1991.
[PKCS] Kaliski Jr.、B.、「PKCS規格の概要」、RSA Data Security、Inc。、1991年6月3日。
[PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption Standard ", version 1.5, 1 November 1993. (See: RFC 2898.)
[PKC05] RSAラボラトリーズ、「PKCS＃5：パスワードベースの暗号化規格」、バージョン1.5、1993年11月1日。（RFC 2898を参照）
[PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard",
version 1.5, 1 November 1993. (See: RFC 2315.)
[PKC10] ---, "PKCS #10: Certification Request Syntax Standard",
version 1.0, 1 November 1993.
[PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard",
version 1.0, 28 April 1995.
[PKC12] ---, "PKCS #12: Personal Information Exchange Syntax",
version 1.0, 24 June 1995.
[R1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[R1108]ケント、S。、「インターネットプロトコルのための国防総省のセキュリティオプション」、RFC 1108、1991年11月。
[R1135] Reynolds, J., "The Helminthiasis of the Internet", RFC 1135, December 1989
[R1135]レイノルズ、J.、「インターネットの蠕虫症」、RFC 1135、1989年12月
[R1208] Jacobsen, O. and D. Lynch, "A Glossary of Networking Terms", RFC 1208, March 1991.
[R1208] Jacobsen、O.およびD. Lynch、「ネットワーキング用語の用語集」、RFC 1208、1991年3月。
[R1281] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for Secure Operation of the Internet", RFC 1281, November 1991.
[R1281] Pethia、R.、Crocker、S.、B.Fraser、「インターネットの安全な運営のためのガイドライン」、RFC 1281、1991年11月。
[R1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
[R1319] Kaliski、B.、「MD2メッセージ - ダイジェストアルゴリズム」、RFC 1319、1992年4月。
[R1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992.
[R1320] Rivest、R。、「MD4メッセージ - ダイジェストアルゴリズム」、RFC 1320、1992年4月。
[R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[R1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[R1334] Lloyd、B.およびW.Simpson、「PPP認証プロトコル」、RFC 1334、1992年10月。
[R1413] St. Johns, M., "Identification Protocol", RFC 1413, February 1993.
[R1413] St. Johns、M。、「識別プロトコル」、RFC 1413、1993年2月。
[R1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[R1421] LINN、J.、「インターネット電子メールのプライバシー強化、第1部：メッセージ暗号化および認証手順」、RFC 1421、1993年2月。
[R1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail, Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[R1422]ケント、S。、「インターネット電子メールのプライバシー強化、第2部：証明書ベースの鍵管理」、RFC 1422、1993年2月。
[R1455] Eastlake 3rd, D., "Physical Link Security Type of Service", RFC 1455, May 1993.
[R1455]イーストレイク3RD、D.、「物理リンクセキュリティタイプサービス」、RFC 1455、1993年5月。
[R1457] Housley, R., "Security Label Framework for the Internet", RFC 1457, May 1993.
【R1457】ホームリー、R.、「インターネットのためのセキュリティラベルフレームワーク」、RFC 1457、1993年5月。
[R1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[R1492] Finseth、C、「TACACSとも呼ばれるアクセス制御プロトコル」、RFC 1492、1993年7月。
[R1507] Kaufman, C., "DASS: Distributed Authentication Security Service", RFC 1507, September 1993.
[R1507] Kaufman、C.、「Dass：Distributed Authentication Service」、RFC 1507、1993年9月。
[R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, December 1994.
[R1731]マイヤーズ、J.、「IMAP4認証メカニズム」、RFC 1731、1994年12月。
[R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994.
[R1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[R1760] Haller、N.、「S / Keyワンタイムパスワードシステム」、RFC 1760、1995年2月。
[R1824] Danisch, H., "The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, August 1995.
[R1824] Danisch、H。、「指数関数的セキュリティシステムTess：認証鍵交換のための識別ベースの暗号化プロトコル（E.I.S.S.Report 1995/4）」、RFC 1824、1995年8月。
[R1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[R1828] Metzger、P.およびW.Simpson、1995年8月、RFC 1828、RFC 1828。
[R1829] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC Transform", RFC 1829, August 1995.
[R1829] Karn、P.、Metzger、P.、W.Simpson、「ESP Des-CBC変換」、RFC 1829、1995年8月。
[R1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME Object Security Services", RFC 1848, October 1995.
[R1848] Crocker、S.、Freed、N.、Galvin、J.、およびS. Murphy、「MIMEオブジェクトセキュリティサービス」、RFC 1848、1995年10月。
[R1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995.
[R1851] Karn、P.、Metzger、P.、W.Simpson、「ESPトリプルデトランス」、RFC 1851、1995年9月。
[R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[R1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D.、およびL. Jones、「Socks Protocol Version 5」、RFC 1928、1996年3月。
[R1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[R1958] Carpenter、B.、「インターネットの建築原則」、RFC 1958、1996年6月。
[R1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[R1983] Malkin、G.、「インターネットユーザーの用語集」、FYI 18、RFC 1983、1983年8月。
[R1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[R1994] Simpson、W.、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、1994年8月、1994年8月。
[R2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. (Superseded by RFC 2743.)
[R2078] LINN、J.、「Generic Security Service Application Program Interface、Version 2」、1997年1月（RFC 2743に置き換えた）
[R2084] Bossert, G., Cooper, S., and W. Drummond, "Considerations for Web Transaction Security", RFC 2084, January 1997.
[R2084] Bossert、G.、Cooper、S.、およびW. Drummond、「Webトランザクションセキュリティに関する考察」、RFC 2084、1997年1月。
[R2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[R2104] Krawczyk、H.、Bellare、M.、R. Canetti、「HMAC：メッセージ認証用鍵付きハッシング」、RFC 2104、1997年2月。
[R2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[R2144] ADAMS、C、「CAST-128暗号化アルゴリズム」、RFC 2144、1997年5月。
[R2179] Gwinn, A., "Network Security For Trade Shows", RFC 2179, July 1997.
[R2179] Gwinn、A。、「展覧会のネットワークセキュリティ」、RFC 2179、1997年7月。
[R2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[R2195] Klensin、J.、Catoe、R.、およびP.Krumviede、「IMAP / POP認証は、1997年9月、RFC 2195。
[R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[R2196]フレイザー、B、「サイトセキュリティハンドブック」、FYI 8、RFC 2196、1997年9月。
[R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, Sep. 1997.
[R2202] Cheng、P.およびR.Glenn、「HMAC-MD5およびHMAC-SHA-1のテストケース」、RFC 2202、1997年9月。
[R2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[R2222]マイヤーズ、J.、「単純認証とセキュリティ層（SASL）」、RFC 2222、1997年10月。
[R2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[R2289] Haller、N.、Metz、C、Nesser、P.、およびM.ストロー、「ワンタイムパスワードシステム」、STD 61、RFC 2289、1998年2月。
[R2323] Ramos, A., "IETF Identification and Security Guidelines", RFC 2323, 1 April 1998. (Intended for humorous entertainment -- "please laugh loud and hard" -- and does not contain serious security information.)
[R2323] RAMOS、A。、「IETF識別およびセキュリティガイドライン」、RFC 2323,1998,1998,1998,1998,1998年4月1日（「ユーモラスなエンターテイメントを目的としています。
[R2350] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998.
[R2350] Brownlee、N.およびE. Guttman、「コンピュータセキュリティインシデント対応の予想」、BCP 21、RFC 2350、1998年6月。
[R2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[R2356] Montenegro、G.およびV.Gupta、「Sun's Mobile IP用ファイアウォールトラバーサル」、RFC 2356、1998年6月。
[R2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[R2401] Kent、S.およびR.Atkinson、1998年11月、RFC 2401、RFC 2401。
[R2402] ---, "IP Authentication Header", RFC 2402, November 1998.
[R2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[R2403] Madson、C.およびR.Glenn、「ESPおよびああ内のHMAC-MD5-96の使用」、RFC 2403、1998年11月。
[R2404] ---, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404,
November 1998.
[R2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[R2405] Madson、C.およびN.Doraswamy、「明示的なIVを備えたESP DES-CBC暗号アルゴリズム」、RFC 2405、1998年11月。
[R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[R2406] Kent、S.およびR.Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[R2407] Piper, D. "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[R2407]パイパー、D。「ISAKMPのインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[R2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[R2408] Maughan、D.、Schertler、M.、Schneider、M.、およびJ. Turner、「インターネットセキュリティ協会および鍵管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[R2410] Glenn、R.およびS. Kent、「NULL暗号化アルゴリズムとIPsecとの使用」、RFC 2410、1998年11月。
[R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[R2412] Orman、H.、「Oakley Key Decection Protocol」、RFC 2412、1998年11月。
[R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[R2451] Pereira、R.およびR.ADAMS、「ESP CBCモード暗号アルゴリズム」、RFC 2451、1998年11月。
[R2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security Handbook", RFC 2504, February 1999.
[R2504] Guttman、E.、Leong、L.、G. Malkin、「ユーザーのセキュリティハンドブック」、RFC 2504、1999年2月。
[R2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[R2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、C. ADAMS、「インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC 2560、6月1999年6月。
[R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption Algorithm", RFC 2612, June 1999.
[R2612] ADAMS、CおよびJ.Gilchrist、「CAST-256暗号化アルゴリズム」、RFC 2612、1999年6月。
[R2628] Smyslov, V., "Simple Cryptographic Program Interface (Crypto API)", RFC 2628, June 1999.
[R2628] SmySlov、V.、「Simple Cryptographic Program Interface（Crypto API）」、RFC 2628、1999年6月。
[R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. (See: Diffie-Hellman-Merkle.)
[R2631] RESCORLA、E。、RFC 2631、1999年6月、RFC 2631、「Diffie-Hellman Key契約方法」。
[R2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[R2634] Hoffman、P.、「S / MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[R2635] Hambridge, S. and A. Lunde, "DON'T SPEW: A Set of Guidelines for Mass Unsolicited Mailings and Postings", RFC 2635, June 1999.
[R2635] Hambridge、S.およびA. Lunde、「スピングしないでください。
[R2660] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[R2660] Rescorla、E.およびA.Schiffman、「Secure Hypertext Transfer Protocol」、RFC 2660、1999年8月。
[R2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[R2743] Linn、J.、「Generic Security Service Application Program Interface Version 2、Update 1」、RFC 2743、2000年1月。
[R2773] Housley, R., Yee, P., and W. Nace, "Encryption using KEA and SKIPJACK", RFC 2773, February 2000.
【R2773】【R2773】ハウス、R.、Yee、P.、およびW。NACE、「KEAとSkipjackを使用した暗号化」、2000年2月2773日。
[R2801] Burdett, D., "Internet Open Trading Protocol - IOTP, Version 1.0", RFC 2801, April 2000.
[R2801] Burdett、D.、「インターネットオープントレーディングプロトコル - IOTP、バージョン1.0」、RFC 2801、2000年4月。
[R2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[R2827] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用したサービス拒否の破損」、BCP 38、RFC 2827、2000年5月。
[R2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[R2865] Rigney、C、Willens、S.、Rubens、A.、およびW.SimpSon、「ユーザーサービス（RADIUS）のリモート認証ダイヤル（RADIUS）」、RFC 2865、2000年6月。
[R3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[R3060]ムーア、B.、Ellesson、E.、Strassner、J.、A. Westerinen、「Policy Core Information Model - バージョン1仕様」、RFC 3060、2001年2月。
[R3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[R3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、M.、Shinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J.、およびS。WaldBusser、「政策ベース管理のための用語」、2001年11月、RFC 3198。
[R3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
【R3280】ホームリー、R.、Polk、W。、Ford、W.、およびD. Solo、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[R3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "Group Domain of Interpretation", RFC 3547, July 2003.
[R3547] Baugher、M.、Weis、B.、Hardjono、T.、H. Harney、「解釈のグループドメイン」、RFC 3547、2003年7月。
[R3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003.
[R3552] Rescorla、E.およびB.コルバー、2003年7月、RFC 3552、「セキュリティ上の検討中のRFCテキストを書くためのガイドライン」。
[R3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[R3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C.、およびS. WU、「インターネットX.509公開鍵インフラストラクチャ証明書ポリシーおよび認定慣行フレームワーク」、2003年11月。
[R3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", RFC 3739, March 2004.
[R3739] Santesson、S.、Nystrom、M.、T.Polk、「インターネットX.509公開鍵インフラストラクチャ：認定証明書プロファイル」、RFC 3739、2004年3月。
[R3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[R3740] Hardjono、T.およびB.Weis、「マルチキャストグループセキュリティアーキテクチャ」、RFC 3740、2004年3月。
[R3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[R3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH.Lvkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[R3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[R3766] Orman、H.およびP. Hoffman、「対称鍵の交換に使用される公開鍵の強みの決定」、BCP 86、RFC 3766、2004年4月。
[R3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. Thompson, "Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile", RFC 3820, June 2004.
[R3820] Tuecke、S.、Welch、V.、Engert、D.、Pearlman、L.、M.Thompson、「インターネットX.509公開鍵インフラストラクチャ（PKI）プロキシ証明書プロファイル」、RFC 3820、2004年6月。
[R3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[R3851] Ramsdell、B.、「Secure / Multipurpose Internet Mail Extensions（S / MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[R3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[R3871] Jones、G.、「大規模インターネットサービスプロバイダ（ISP）IPネットワークインフラストラクチャ（ISP）IPネットワークインフラストラクチャ（ISP）IPネットワークインフラストラクチャの運用セキュリティ要件）。
[R4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[R4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、2005年3月。
[R4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[R4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のリソースレコード」、RFC 4034、2005年3月。
[R4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[R4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのプロトコル変更」、RFC 4035、2005年3月。
[R4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[R4086]イーストレイク、D.、第3、Schiller、J.、およびS. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[R4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[R4120] Neuman、C、Yu、T.、Hartman、S.、およびK. Raeburn、「Kerberosネットワーク認証サービス（V5）」、RFC 4120、2005年7月。
[R4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
[R4158] Cooper、M.、Dzambasow、Y.、Hesse、P.、Joseph、S.、R.Nicholas、「インターネットX.509公開鍵インフラ：認証パスビル」、RFC 4158、2005年9月。
[R4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[R4210] ADAMS、C、Farrell、S.、Kause、T.、およびT. Mononen、 "Internet X.509公開鍵インフラストラクチャ証明書管理プロトコル（CMP）"、2005年9月のRFC 4210。
[R4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[R4301] Kent、S.およびK.SEO、2005年12月、RFC 4301、RFC 4301の「セキュリティアーキテクチャ」。
[R4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[R4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[R4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[R4303]ケント、S.、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[R4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[R4306] Kaufman、C、「インターネット鍵交換（IKEV2）プロトコル」、RFC 4306、2005年12月。
[R4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[R4346] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[R4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[R4422]メルニコフ、A.およびK。Zeilenga、「単純認証およびセキュリティ層（SASL）」、RFC 4422、2006年6月。
[Raym] Raymond, E., ed., "The On-Line Hacker Jargon File", version 4.0.0, 24 July 1996. (See: http://www.catb.org/~esr/jargon for the latest version. Also, "The New Hacker's Dictionary", 3rd edition, MIT Press, September 1996, ISBN 0-262-68092-0.)
[raym] Raymond、E.、ED。、「オンラインハッカーJargon File」、バージョン4.0.0,296,24,206,20,24,796。（http：//www.catb.org/~esr/jargonバージョン。また、「新しいハッカーの辞書」、第3版、MITプレス、1996年9月、ISBN 0-262-68092-0。
[Roge] Rogers, H., "An Overview of the CANEWARE Program", in "Proceedings of the 10th National Computer Security Conference", NIST and NCSC, September 1987.
[ROGE]ロジャース、H。、「CANEWAREプログラムの概要」、「第10回国立コンピュータセキュリティ会議の議事録」、NISTおよびNCSC、1987年9月。
[RSA78] Rivest, R., A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", in "Communications of the ACM", vol. 21, no. 2, February 1978, pp. 120-126.
[RSA78] Rivest、R.、A. Shamir、L. Adleman、「ACMの通信」、「ACMの通信」、「デジタル署名や公開鍵暗号システム」21、いいえ。1978年2月2日、PP。120-126。
[RSCG] NSA, "Router Security Configuration Guide: Principles and Guidance for Secure Configuration of IP Routers, with Detailed Instructions for Cisco Systems Routers", version 1.1c, C4-040R-02, 15 December 2005, available at http://www.nsa.gov/snac/routers/C4-040R-02.pdf.
[RSCG] NSA、「Router Security Configuration Guide：Cisco Systems Routersの詳細な説明書」、2005年12月15日、2005年12月15日、C4-040R-02,25,15,15,15,15,15,15、「RSAセキュリティ構成ガイド」、2005年12月15日、http：//www.nsa.gov/snac/routers/c4-040r-02.pdf。
[Russ] Russell, D. et al, Chapter 10 ("TEMPEST") of "Computer Security Basics", ISBN 0-937175-71-4, 1991.
[RUSS] Russell、D. et al、「コンピュータセキュリティ基本」（「Tempest」）、ISBN 0-937175-71-4,1991。
[SAML] Organization for the Advancement of Structured Information Standards (OASIS), "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", version 1.1, 2 September 2003.
[SAML]構造化情報標準（OASIS）の進歩（OASIS）、「OASIS Security Assertion Markup Language（SAML）」、バージョン1.1,29903。
[Sand] Sandhu, R. et al, "Role-Based Access Control Models", in "IEEE Computer", vol. 29, no. 2, February 1996, pp. 38-47.
[Sand] Sandhu、R. et al、 "IEEE Computer"、Vol。29、いいえ。1996年2月2日、PP。38-47。
[Schn] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, Inc., New York, 1996.
[シュン]シュナリエ、B.、「適用された暗号化第2版」、John Wiley＆Sons、Inc。、New York、1996年。
[SDNS3] U.S. DoD, NSA, "Secure Data Network Systems, Security Protocol 3 (SP3)", document SDN.301, Revision 1.5, 15 May 1989.
[SDNS3]米国のDOD、NSA、「セキュアデータネットワークシステム、セキュリティプロトコル3（SP3）」、文書SDN.301、Revision 1.5,15 5月1989年5月。
[SDNS4] ---, "Secure Data Network Systems, Security Protocol 4
(SP4)", document SDN.401, Revision 1.2, 12 July 1988.
[SDNS7] ---, "Secure Data Network Systems, Message Security Protocol
(MSP)", SDN.701, Revision 4.0, 7 June 1996, with
"Corrections to Message Security Protocol, SDN.701, Rev 4.0,
96-06-07", 30 Aug, 1996.
[SET1] MasterCard and Visa, "SET Secure Electronic Transaction Specification, Book 1: Business Description", version 1.0, 31 May 1997.
[SET1]マスターカードとビザ、「セキュア電子取引仕様、書籍1：ビジネス説明」、バージョン1.0,31、1997年5月31日。
[SET2] ---, "SET Secure Electronic Transaction Specification, Book
2: Programmer's Guide", version 1.0, 31 May 1997.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", in "Proceedings of the 1996 Symposium on Network and Distributed Systems Security".
[Skeme] Krawczyk、H.、「ネットワークのネットワークと分散システムのセキュリティに関する1996年シンポジウムの議事録」の「スケーム：インターネットのための多用途の安全な鍵交換機構」。
[SKIP] "SKIPJACK and KEA Algorithm Specifications", version 2.0, 22 May 1998, and "Clarification to the SKIPJACK Algorithm Specification", 9 May 2002 (available from NIST Computer Security Resource Center).
[スキップ]「SkipjackとKea Algorithmの仕様」、バージョン2.0,22、1998年5月22日、および2002年5月9日（NISTコンピュータセキュリティリソースセンターから入手可能）。
[SP12] NIST, "An Introduction to Computer Security: The NIST Handbook", Special Publication 800-12.
[SP12] NIST、「コンピュータセキュリティの紹介：NISTハンドブック」、特別発表800-12。
[SP14] Swanson, M. et al (NIST), "Generally Accepted Principles and Practices for Security Information Technology Systems", Special Publication 800-14, September 1996.
[SP14] Swanson、M. et al（NIST）、「一般的に認められている原則と慣行・慣行」、特別出版物800-14、1996年9月。
[SP15] Burr, W. et al (NIST), "Minimum Interoperability Specification for PKI Components (MISPC), Version 1", Special Publication 800-15, September 1997.
[SP15] Burr、W. et al（NIST）、「PKIコンポーネント（MISPC）、バージョン1の最小相互運用仕様、特別出版物800-15、1997年9月。
[SP22] Rukhin, A. et al (NIST), "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", Special Publication 800-15, 15 May 2001.
[SP22] Rukhin、A.ら（NIST）、「暗号アプリケーション用のランダムおよび擬似乱数発生器用統計的テストスイート」、特録800-15、2001年5月15日。
[SP27] Stoneburner, G. et al (NIST), "Engineering Principles for Information Technology Security (A Baseline for Achieving Security)", Special Publication 800-27 Rev A, June 2004.
[SP27] StoneBurner、G.ら（NIST）、「情報技術セキュリティのための工学的原則（セキュリティを達成するためのベースライン）」、特別出版物800-27 Rev A、2004年6月。
[SP28] Jansen, W. (NIST), "Guidelines on Active Content and Mobile Code", Special Publication 800-28, October 2001.
[SP28] JANSEN、W。（NIST）、「アクティブコンテンツとモバイルコードのガイドライン」、特別発表800-28、2001年10月。
[SP30] Stoneburner, G. et al (NIST), "Risk Management Guide for Information Technology Systems", Special Publication 800-30, October 2001.
[SP30] StoneBurner、G.ら（NIST）、「情報技術システムのリスク管理ガイド」、特別発表800-30、2001年10月。
[SP31] Bace, R. et al (NIST), "Intrusion Detection Systems", Special Publication 800-31.
[SP31] BACE、R.ら（NIST）、「侵入検知システム」、特録800-31。
[SP32] Kuhn, D. (NIST), "Introduction to Public Key Technology and the Federal PKI Infrastructure ", Special Publication 800-32, 26 February 2001.
[SP32] Kuhn、D.（NIST）、「公開鍵技術の紹介と連邦PKIインフラストラクチャーの紹介」、特別出版物800-32,22,26。
[SP33] Stoneburner, G. (NIST), "Underlying Technical Models for Information Technology Security", Special Publication 800-33, December 2001.
[SP33] StoneBurner、G.（NIST）、「情報技術セキュリティの基礎となる技術的モデル」、特別発表800-33、2001年12月。
[SP37] Ross, R. et al (NIST), "Guide for the Security Certification and Accreditation of Federal Information Systems", Special Publication 800-37, May 2004.
[SP37] Ross、R. et al（NIST）、「連邦情報システムのセキュリティ認証および認定ガイド」、特別発表800-37、2004年5月。
[SP38A] Dworkin, M. (NIST), "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", Special Publication 800-38A, 2001 Edition, December 2001.
[SP38A] Dworkin、M.（NIST）、「ブロック暗号の操作モードの推奨事項：方法およびテクニック」、特別出版物800-38A、2001年12月2001年12月。
[SP38B] ---, "Recommendation for Block Cipher Modes of Operation:
The CMAC Mode for Authentication", Special Publication
800-38B, May 2005.
[SP38C] ---, "Recommendation for Block Cipher Modes of Operation:
The CCM Mode for Authentication and Confidentiality",
Special Publication 800-38C, May 2004.
[SP41] Wack, J. et al (NIST), "Guidelines on Firewalls and Firewall Policy", Special Publication 800-41, January 2002.
[SP41] WACK、J.ら（NIST）、「ファイアウォールとファイアウォールポリシーのガイドライン」、特別発表800-41、2002年1月。
[SP42] ---, "Guideline on Network Security Testing", Special
Publication 800-42, October 2003.
[SP56] NIST, "Recommendations on Key Establishment Schemes", Draft 2.0, Special Publication 800-63, January 2003.
[SP56] NIST、「主要設立制度に関する推奨事項」、ドラフト2.0、特録800-63、2003年1月。
[SP57] ---, "Recommendation for Key Management", Part 1 "General
Guideline" and Part 2 "Best Practices for Key Management
Organization", Special Publication 800-57, DRAFT, January
2003.
[SP61] Grance, T. et al (NIST), "Computer Security Incident Handling Guide", Special Publication 800-57, January 2003.
[SP61] Grance、T. et al（NIST）、「コンピュータセキュリティインシデントハンドリングガイド」、特録800-57、2003年1月。
[SP63] Burr, W. et al (NIST), "Electronic Authentication Guideline", Special Publication 800-63, June 2004
[SP63] Burr、W. et al（NIST）、「電子認証ガイドライン」、特録800-63、2004年6月
[SP67] Barker, W. (NIST), "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", Special Publication 800-67, May 2004
[SP67] Barker、W.（NIST）、「トリプルデータ暗号化アルゴリズム（TDEA）ブロック暗号の推奨事項、特録800-67、2004年5月
[Stal] Stallings, W., "Local Networks", 1987, ISBN 0-02-415520-9.
[STAL]スーツ、W、「ローカルネットワーク」、1987、ISBN 0-02-415520-9。
[Stei] Steiner, J. et al, "Kerberos: An Authentication Service for Open Network Systems", in "Usenix Conference Proceedings", February 1988.
[Stei] Steiner、J. et al、 "Kerberos：Open Network Systems for Open Network Systemsの認証サービス"、1988年2月。
[Weis] Weissman, C., "Blacker: Security for the DDN: Examples of A1 Security Engineering Trades", in "Symposium on Security and Privacy", IEEE Computer Society Press, May 1992, pp. 286- 292.
[Weis] Weissman、C.、「Blocker：DDNのセキュリティ：A1セキュリティエンジニアリング取引の例」、「セキュリティとプライバシーのシンポジウム」、IEEEコンピュータ社会プレス、1992年5月、PP。286-292。
[X400] International Telecommunications Union -- Telecommunication Standardization Sector (formerly "CCITT"), Recommendation X.400, "Message Handling Services: Message Handling System and Service Overview".
[X400]国際電気通信連合 - 電気通信標準化セクター（以前「CCITT」）、推奨X.400、「メッセージ処理サービス：メッセージ処理システムおよびサービスの概要」。
[X419] ---, "Message Handling Systems: Protocol Specifications",
ITU-T Recommendation X.419. (Equivalent to ISO 10021-6).
[X420] ---, "Message Handling Systems: Interpersonal Messaging
System", ITU-T Recommendation X.420. (Equivalent to ISO
10021-7.).
[X500] ---, Recommendation X.500, "Information Technology -- Open
Systems Interconnection -- The Directory: Overview of
Concepts, Models, and Services". (Equivalent to ISO 9594-1.)
[X501] ---, Recommendation X.501, "Information Technology -- Open
Systems Interconnection -- The Directory: Models".
[X509] ---, Recommendation X.509, "Information Technology -- Open
Systems Interconnection -- The Directory: Authentication
Framework", COM 7-250-E Revision 1, 23 February 2001.
(Equivalent to ISO 9594-8.)
[X519] ---, Recommendation X.519, "Information Technology -- Open
Systems Interconnection -- The Directory: Protocol
Specifications".
[X520] ---, Recommendation X.520, "Information Technology -- Open
Systems Interconnection -- The Directory: Selected Attribute
Types".
[X680] ---, Recommendation X.680, "Information Technology --
Abstract Syntax Notation One (ASN.1) -- Specification of
Basic Notation", 15 November 1994. (Equivalent to ISO/IEC
8824-1.)
[X690] ---, Recommendation X.690, "Information Technology -- ASN.1
Encoding Rules -- Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", 15 November 1994. (Equivalent to
ISO/IEC 8825-1.)
George Huff had a good idea! [Huff]
ジョージハフは良い考えを持っていました！[ハフ]
Author's Address
著者の住所
Dr. Robert W. Shirey 3516 N. Kensington St. Arlington, Virginia 22207-1328 USA
Robert W. Shirey 3516 N. Kensington St. Arlington、Virginia 22207-1328 USA
EMail: rwshirey4949@verizon.net
Full Copyright Statement
完全著作権宣言
Copyright (C) The IETF Trust (2007).
著作権（c）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78とwww.rfc-editor.org/copyright.htmlに含まれている権利、ライセンス、制限の対象となり、そこに記載されている場合を除き、著者らはすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書および本明細書に含まれる情報は、「現状の」基準であり、寄与者、統治、または後援されている、または（いずれも）、インターネット社会、IETF信託およびインターネットエンジニアリングのタスク力を否定する。本明細書における情報の使用が特定の目的のための権利または黙示的な保証を侵害しないことを保証するが、定義または暗示されていない保証、または暗示されていない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
この文書に記載されているテクノロジの実装または使用に関連すると主張される可能性がある、またはそのような権利の下でのライセンスの使用に関連すると主張される可能性がある、またはその他の権利の下にある範囲内である可能性がある、またはその他の権利の使用に関連すると主張する可能性がある、IETFは、IETFを取りません。利用可能です。そのような権利を特定するためにそれが独立した努力をしたことを表していません。RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリからhttp://www.ietf.org/ipr。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、著作権、特許または特許出願、またはこの規格を実装することが要求される可能性がある技術をカバーする可能性のある他の独自の権利を注意を及ぼすように興味のある当事者を勧めます。ietf-ipr@ietf.orgのIETFに情報を宛先に宛ててください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。