B<- 3 ->D

C English

$ CA
certification authority 参照。
　
$ CA certificate （CA 証明書）
(I) 「CA のために他の CA によって発行された（デジタル）証明書。」 [X509]

(C) その所有者が、デジタル証明書を発行できるデジタル証明書。v3 X.509 公開鍵証明書は、公開鍵を使用して証明書の署名を検証するかどうかを示す「cA」値を含む「basicConstraints」拡張を持つことがある。
　
$ call back （コールバック）
(I) 電話回線を介してコンピュータにリモートからアクセスする端末の認証テクニック。ホストシステムは、呼び出し側からの接続を切断し、その端末用としてすでに認定されている電話番号を使用してコールバックを行う。
$ capability
(I) トークン。通常は偽造不可のデータ値で (チケットと呼ばれることがある)、これを所持する人にシステム資源へのアクセス権限が与えられる。トークンを所有することは、所有者がトークンによって指定された資源へのアクセス権を持つこと示す証拠としてシステムに受け入れられる。
（access control list, credential, digital certificate 参照。 ）

(C) この概念は、デジタル証明書 として実装することができる。
（attribute certificate 参照。）
　
$ CAPI
cryptographic application programming interface 参照。
　
$ CAPSTONE chip （CAPSTONE チップ）
(N) Type II 暗号技術プロセッサをともなう集積回路 (the Mykotronx, Inc. MYK-82) で、SKIPJACK、KEA、DSA、SHA、および非対称暗号方式をサポートする基本数学関数を実装し、CLIPPER チップの鍵エスクロー機能を持つ。
（FORTEZZA 参照。）
　
$ card （カード）
cryptographic card, FORTEZZA card, payment card, PC card, smart card, token 参照。
　
$ card backup
token backup 参照。
　
$ card copy
token copy 参照。
　
$ card restore
token restore 参照。

$ cardholder
(I) カードを発行された主体。
　
(O) SET における用法：
「正当な支払カードアカウントの保有者、および電子商取引をサポートするソフトウェアの使用者。」 [SET2]
カード保有者は、発行者から支払カードを発行される。SET は、カード保有者が商取引を行う間、支払カードのアカウント情報が機密に保たれることを保証する。 [SET1]
　
$ cardholder certificate
(O) SET における用法：
金融機関の承認に基づいてカード保有者にされた発行されたデジタル証明書で、購入要求と暗号化された支払情報と共に業者に転送される。これにより、発行元の金融機関によってアカウント番号が検証され、サードパーティによって改竄されていないことが証明される。[SET1]
　
$ cardholder certification authority (CCA)
(O) SET における用法： 
カード保有者にデジタル証明書を発行する責務を持つ CA で、支払カードブランド、発行者、ブランドルールに従うその他のパーティの代理としてこれを実行する。CCA はカード発行者との関係を維持し、カード保有者のアカウントの検証を可能にする。CCA は CRL を発行しないが、ルート CA、ブランド CA、地域 CA、および支払ゲートウェイ CA によって発行された CRL を配布する。[SET2]
　
$ CAST
(N) C.A. (Carlisle Adams) と S.T. (Stafford Tavares) によって開発された、対称暗号アルゴリズムの設計手法、およびその成果のアルゴリズム群。[R2144, R2612]
　
$ category
(I) 秘密情報要素の集まりであり、データの防御性を高めるために、非階層的な制限セキュリティが適用される。
（compartment 参照。）
　
$ CAW
certification authority workstation 参照。
　
$ CBC
cipher block chaining 参照。
　
$ CCA
cardholder certification authority 参照。
　
$ CCITT
(N) "International Telephone and Telegraph Consultative Committee" のフランス語翻訳についての略語。現在、ITU-T と改名されている。
　
$ CERT
computer emergency response team 参照。
　
$ certificate
(I) 一般的な英語における用法：
何らか、または何らかの所有が真実であることを証明する文書。

(C) セキュリティにおける用法：
capability, digital certificate 参照。

(C) PKI における用法：
attribute certificate, public-key certificate 参照。
　
$ certificate authority
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。それは、X.509 で標準化されている用語 "certification authority" の誤用だからである。
$ certificate chain
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。それは、標準化された用語の意味と重複するからである。代わりに、"certification path"を使う。
　
$ certificate chain validation
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。それは、標準化された用語の意味と重複し、概念の混同によって誤解を招く恐れがあるからである。代わりに、文意に応じて "certificate validation" もしくは "path validation" を使う。
（validate vs. verify 参照。）
　
$ certificate creation
(I) CA がデジタル証明書のデータがデータフィールドの値を設定し、それに署名する行為またはプロセス。
（issue 参照。）
　
$ certificate expiration
(I) 証明書に割り当てられた期限が過ぎ、その効力が失われること。
（certificate revocation, validity period 参照。）
　
$ certificate extension
extension 参照。
　
$ certificate holder
(D) インターネット標準文書は、 この用語をデジタル証明書のサブジェクトの同義語として使ってはいけない（SHOULD NOT）。この用語は、潜在的に曖昧であるからである。例えば、この用語は、証明書のコピーを単に所有するだけのリポジトリを指し示すこともできる。
（certificate owner 参照。）
　
$ certificate management （証明書管理）
(I) デジタル証明書のライフサイクルの間に、CA が実行する可能性のある機能。次のものが含まれる。：

（archive, certificate management, key management, security architecture, token management 参照。）

$ certificate owner
(D) インターネット標準文書は、この用語をデジタル証明書のサブジェクトの同義語として使ってはいけない（SHOULD NOT）。この用語は、潜在的に曖昧であるからである。例えば、この用語は、Web サーバーなどの他の主体を操作するために証明書を取得したシステム主体を指し示すこともできる。
（certificate holder 参照。）
　
$ certificate policy
(I) 「名前付きの規則のセットで、共通するセキュリティ要件を持つ特定のコミュニティまたはアプリケーションのクラスに対し、証明書の適用性を示す。」 [X509]
（certification practice statement 参照。）

(C) 証明書ポリシーは、証明書ユーザが、特定のアプリケーションで証明書を信頼できるかどうかを決めるのに役立つ。「例えば、ある特定の証明書ポリシーは、指定された価格範囲内での商取引の電子データ交換トランザクションの認証に対し、証明書のタイプの適用性を指摘できる。」 [R2527]

(C) v3 X.509 公開鍵証明書は、「certificatePolicies」拡張を持つことがある。この拡張には、発行元 CA によって認識され、証明書に適用することによってその使用方法を定義する証明書ポリシーが含まれる。
(C) SET における用法：
どの SET 証明書も、SET ルート CA の、少なくとも 1 つの証明書ポリシーを指定する。SET は、証明書ポリシー修飾子を使用して、実際のポリシーステートメントを示し、root ポリシーにポリシー修飾を追加する。
（SET qualifier 参照。）
　
$ certificate policy qualifier （証明書ポリシー限定子）
(I) 証明書ポリシーに付随するものであり、X.509 v3 公開鍵証明書の中の"certificatePolicies" 拡張に含められている情報。
　
$ certificate reactivation （証明書失効）
(I) CA が失効を指定したが、まだ CRL に掲載されていないデジタル証明書を有効な状態に戻す行為またはプロセス。
$ certificate rekey (証明書の鍵再生成)
(I) 異なる (通常は新規の) 公開鍵で新しい証明書を発行することにより、既存の公開鍵証明書の公開鍵の値を変更する行為またはプロセス。
（certificate renewal, certificate update, rekey 参照。）

(C) X.509 公開鍵証明書では、"rekey" (鍵再生成) の本質は、主体はそのまま残り、新しい公開鍵を主体に割り当てることである。他の変更および古い証明書の失効は、鍵の再生成をサポートする PKI および CPS が必要する場合にのみ行われる。変更がこれ以上に及ぶときは、プロセスは "certificate update" (証明書の更新) となる。

(O) MISSI における用法：
MISSI X.509 公開鍵証明書の "rekey" (鍵再生成) は、発行局が、次の点を除いて古い証明書とまったく同じ証明書を作成することを意味する。異なる点とは、新しい証明書が、新規または異なる KEA 鍵を持つ、新規または異なる DSS 鍵を持つ、あるいは新規または異なる KEA 鍵と DSS 鍵を持つことである。新しい証明書は、異なりシリアル番号を持ち、有効期間も異なることがある。新たに作成されたそれぞれの鍵には、新しい鍵の作成日と最長有効期間が割り当てられる。KEA 鍵が生成された場合は、この鍵に新しい KMID が割り当てられる。古い証明書は有効期限が過ぎるまで有効だが、これ以上、リニュアル、鍵再生成、更新が行われることはない。
　
$ certificate renewal
(I) 新しい証明書を発行することにより、既存の公開証明書によって指定されたデータバインディングの正当性を時間的に延長する行為またはプロセス。
（certificate rekey, certificate update 参照。）

(C) X.509 公開鍵証明書の場合、この用語は、有効期限は延長されるが (そして、もちろん新しいシリアル番号が割り当てられる)、主体およびその他のアイテムへの公開鍵の割り当てはそのまま残る。他のデータアイテムの変更および古い証明書の失効は、リニュアルをサポートする PKI および CPS が必要する場合にのみ行われる。変更がこれ以上に及ぶときは、プロセスは "certification rekey" (証明書の鍵再生成) または "certificate update" (証明書の更新) となる。
　
$ certificate request
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。これは、PKCS #10 で標準化され、PKIX で使用されている用語の不正確な使用法だからである。代わりに、標準用語である "certification request" を使う。
　
$ certificate revocation
(I) CA によって発行され、有効であったデジタル証明書が無効になったことを CA が宣言したときに発生するイベント。； 通常、失効日と共に宣言される。
　
(C) X.509 では、証明書を記載した CRL を発行することにより、潜在的な証明書ユーザーに失効が通知される。失効と CRL のリストは、証明書の期限が切れる前にのみ必要である。
　
$ certificate revocation list (CRL)
(I) 予定された有効期限を迎える前に、発行者によって失効されたデジタル証明書を列挙するデータ構造体。
（certificate expiration, X.509 certificate revocation list 参照。）

(O) 「有効とみなされなくなった証明書のセットを示す、証明書の発行者による署名付きのリスト。CRL に掲載された後で証明書の有効期限が切れると、次回の CRL にはその証明書は掲載されない。CRL は、失効された公開鍵証明書または属性証明書を識別するために使用され、認証局またはユーザーに発行された証明書の失効を表す。また、CRL という用語は、CRL、ARL、ACRL 等を含むさまざまな種類の失効リストに適用される一般的な用語としても用いられる。」 [FPDAM]
　
$ certificate revocation tree
(I) 証明書の失効通知を配布するメカニズム。；
ツリーの発行者によって署名されたハッシュツリーの結果を使用する。CRL の発行に代わる方法を提供するが、X.509 ではサポートされていない。
（certificate status responder 参照。）
　
$ certificate serial number （証明書シリアル番号）
(I) 次のような整数値。
(a) デジタル証明書に対応し、デジタル証明書内に含まれることがある。
(b) 証明書の発行者によって証明書に割り当てられた。
(c) 発行者によって生成されたすべての証明書の間で一意である。
(O) 「発行 CA 内で一意で、CA によって発行された 1 つの証明書に厳密に対応するの整数値。」 [X509]
　
$ certificate status responder
(N) FPKI における用法：
証明書ユーザを認証するために、認証済み証明書のステータス情報を CA に提供するよう動作するトラステッドオンラインサーバー。[FPKI] は CRL の発行の代替方法を提供するが、X.509 ではサポートされていない。
（certificate revocation tree 参照。）
　
$ certificate update （証明書の更新）
(I) 新しい証明書を発行することにより、既存の公開鍵証明書にバインドされた鍵以外のデータアイテム（特に、主体に与えられた権限) が変更される行為またはプロセス。
（certificate rekey, certificate renewal 参照。）

(C) X.509 公開鍵証明書では、このプロセスの本質は、公開鍵にバインドされているデータに根本的な変更が加えられ、古い証明書の失効が必要になることである (それ以外の場合は、単に｢証明書の鍵再生成」または「証明書の更新｣となる)。
　
$ certificate user （証明書ユーザ）
(I) デジタル証明書によって提供された情報の正当性 (他の主体の公開鍵の値など) に依存するシステム主体。
（relying party 参照。）

(O) 「確信をもって、他の主体の公開鍵を知る必要がある主体。」 [X509]

(C) システム主体は、人間、組織、あるいは人間またはシステムによって制御されているデバイスまたはプロセスである。

(D) インターネット標準文書は、この用語を証明書の"subject"の同義語として使ってはいけない（SHOULD NOT）。
　
$ certificate validation （証明書の十分性検証）
(I) デジタル証明書によってなされる主張が信頼できるものであることを立証する行為またはプロセス。
（valid certificate, validate vs. verify 参照。）

(O) 「認証パスの構築と処理の可能性を含み、証明書が有効であることを確認し、パス内のどの証明書も期限が切れていない、または失効しないことを確認するプロセス」 [FPDAM]

(C) 証明書を検証するために、証明書ユーザは、証明書のフォームと署名が正しく、証明書が現在も効力をもつことをチェックする。：
$ certification （認定）
(I) 情報システムにおける用法：
システムの設計と実装が指定のセキュリティ要件を満たす度合いを立証するための、情報システムのセキュリティ機能およびその他の防御機構の技術的な評価。 (通常は、運用承認アクションのサポートで行われる。）[FP102]
（accreditation 参照。）

(I) デジタル証明書における用法：
証明書内のデータ項目間の結び付きの真実性と正確さを保証する行為またはプロセス。
（certify 参照。）

(I) 公開鍵における用法：
公開鍵と一致する秘密鍵の所有者の名前に公開鍵を結び付ける公開鍵証明書を発行することにより、公開鍵の所有を保証する行為またはプロセス。鍵を名前に結びつけるだけでなく、公開鍵証明書はこれらの項目を制限的または説明的なデータ項目に結びつける。
（X.509 public-key certificate 参照。）

(O) SET における用法：
「 一連の要件または基準が満たされていることを確認し、通常は書面によって、この事実を他の人に証明するプロセス。正当な権限を持つ団体とプロセスによって検査され、SET プロトコルに完全に準拠すると評価されたシステムは、準拠することが認証された、呼ばれる。」 [SET2]
　
$ certification authority (CA)
(I) デジタル証明書 (特に X.509 証明書) を発行し、証明書内のデータ項目間の結びつきを保証する主体。

(O) 「1人以上のユーザに信用され、証明書を作成および割り当てる機関。認証局がユーザの鍵を作成することもある。」 [X509]

(C) 証明書ユーザは、証明書によって提供された情報の正当性に依存する。このため、CA は、証明書ユーザが信頼する第三者でなければならず、通常、政府、企業、またはその他の組織によって認められた権限をともなう公的な地位を持つ。CA は、証明書のライフサイクルを管理する責任を持ち （certificate management 参照）、証明書の種類および適用する CPS に応じて、その証明書に対応する鍵ペアのライフサイクルを管理する責任を持つことがある。
（key management 参照。）
　
$ certification authority workstation (CAW)
(I) CA（認証機関）にデジタル証明書の発行を可能にし、必要に応じて他の証明書を管理する機能を与えるコンピュータシステム。
　
$ certification hierarchy （認証階層）
(I) CA と CA が公開鍵証明書を発行する主体間の関係を示す木構造 (ループフリー) トポロジー。
（hierarchical PKI 参照。）

(C) この構造内では、1 つの CA が最上位の CA、つまり階層の一番上のレベルとなる。
（root, top CA 参照。）
最上位の CA は、2 番目に高いレベルを形成する 1 つ以上の追加 CA に公開鍵証明書を発行する。これらの CA は、3 番目に高いレベルの CA に証明書を発行し、これが繰り返される。下から 2 番目の階層の CA は、最下位のレベルを形成する CA でない主体、つまりエンドエンティティに証明書を発行する。
（end entity 参照。）
このため、すべての認証パスは最上位の CA から開始し、0 以上のレベルの他の CA をたどって下位へ向かう。すべての証明書ユーザは、パス検証の基点を最上位の CA の公開鍵に置く。

(O) MISSI における用法：
MISSI における認証階層は、3つ、もしくは 4つのレベルの CA をもつ。：
(O) PEM における用法：
PEM における認証階層は、3つのレベルの CA をもつ。[R1422]：
(O) SET における用法：
SET における認証階層は、3つ、もしくは 4つのレベルの CA をもつ。：
$ certification path
(I) 証明書ユーザがパス内の最後の証明書の署名を検証することを可能にする一連の公開鍵証明書 (または、1 つの属性証明書をともなう一連の公開鍵証明書)。これにより、最後の証明書のサブジェクトである主体の認証済みの公開鍵 (または、認証済みの属性) をユーザーが入手できる。
（certificate validation, valid certificate 参照。）

(O) 「[X.500 Directory Information Tree]  内のオブジェクトの一連の証明書で、パスの最初のオブジェクトの公開鍵と共に処理することによってパス内の最後のオブジェクトの公開鍵を入手できる。」 [X509, R2527]

(C) パスとは、「特定のユーザが他のユーザの公開鍵を入手することを可能にするために必要な証明書のリスト」である。 [X509] 最初の証明書を除く各証明書のデジタル署名が 1 つ前の証明書に含まれる公開鍵によって検証されるという意味で、リストはリンクされているといえる。； すなわち、証明書の署名に使用された秘密鍵と 1 つ前の証明書に含まれる公開鍵は、署名をした主体によって所有される鍵ペアを形成する。

(C) 前の (C) の段落の X.509 の引用で、「特定の」という用語は、ある証明書ユーザーによって検証される認証パスは、他の証明書ユーザーによっては検証されないことを意味している。これは、最初の証明書 (ルート証明書のこともある) が信頼済みの証明書であるか、最初の証明書が信頼済みの鍵 (ルート鍵のこともある) で検証されなければならないが、このような信頼は各ユーザーごとに相対的に定義されるもので、すべてのユーザーに対して絶対的に定義されるものではないからである。
　
$ certification policy
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。代わりに、意味に応じて、"certificate policy" もしくは "certification practice statement" を使う。
　
$ certification practice statement (CPS)
(I) 「認証局が証明書の発行のために採用する運用規定。」 [ABA, R2527]
（certificate policy 参照。）

(C) CPS は公開されたセキュリティポリシーで、特定の CA から発行された証明書が特定のアプリケーションで十分に信頼できるかどうかを証明書ユーザーが判断するときに役立つ。CPS は、
(a) CA によるシステムの詳細と証明書管理業務で採用している既定の定義、
(b) CA と証明書を発行された主体との間の契約の一部、
(c) CA に適用される法令または規制、
(d) 複数のドキュメントを含むこれらの種類の組み合わせである。[ABA]

(C) 通常、CPS は証明書ポリシーよりも詳細で手続き的な目的を持つ。CPS が特定の CA または CA コミュニティに適用されるのに対し、証明書ポリシーは CA 間また CA コミュニティ間に適用される。1 つの CPS を持つ CA が複数の証明書ポリシーをサポートすることがある。これは、異なる適用目的として、または異なるユーザコミュニティによって使用される。それぞれ異なる CPS を持つ複数の CA が、同じ証明書ポリシーをサポートすることがある。 [R2527]
　
$ certification request
(I) PCKS #10 によって定義され、PKIXA アルゴリズムで使用されている、アルゴリズム非依存のトランザクションフォーマット。DN、公開鍵、および属性セット (オプション) を含む。これらは、認証を要求する主体によってまとめて署名され、CA に送信される。CA は要求を X.509 公開鍵証明書または他の種類の証明書に変換する。
　
$ certify
1.
(I) デジタル証明書を発行し、これによって真実性、正確さ、および証明書 (例： X.509 public key certificate 参照) 内のデータ項目 (証明書の主体者や公開鍵の所有など) の結びつきを保証する。
（certification 参照。）

(C) 「公開鍵を証明する」ことは、証明書の主体者と鍵の結び付きを保証する公開鍵証明書を発行することを意味する。

2.
(I) 真実性、正確さ、およびデジタル証明書内のデータ項目間の結び付きを検証する手段を採用する行為。

(C) 検証に使用する尺度の説明は、CA の CPS に含まれていなければならない。
　
$ CFB
cipher feedback 参照。
　
$ Challenge Handshake Authentication Protocol (CHAP)(チャレンジハンドシェイク認証プロトコル)
(I) PPP用のピアエンティティ認証方式で、ランダムに生成されたチャレンジを使用し、チャレンジと秘密鍵による暗号技術的なハッシュに基づくレスポンスの一致を要求する。[R1994]
（challenge-response, PAP 参照。）
　
$ challenge-response (チャレンジ・レスポンス）
(I) チャレンジへのレスポンスとして得られる正しい認証情報を要求することによって一意性を検証する認証プロセス。 コンピュータシステムでは、通常、認証情報は予測不可能なチャレンジ値に対するレスポンスとして計算しなければならない値である。
 
$ Challenge-Response Authentication Mechanism (CRAM) (チャレンジ・レスポンス認証方式)
(I) IMAP4 における用法：
IMAP4 AUTHENTICATE での使用を目的としたメカニズム [R2195] で、IMAP4 クライアントは、鍵化されたハッシュ [R2104] を使用して自分自身を IMAP サーバーに対して認証する。
（POP3 APOP 参照。）

(C) サーバーは、クライアントへの準備済みレスポンスに一意のタイムスタンプを含める。クライアントは、クライアント名に演算結果のハッシュ値を加えて応答する。このハッシュ値は、クライアントとサーバーだけが知っている共有秘密値とタイムスタンプを結合した文字列に MD5 を適用することによって得られるものである。
 
　
$ channel （チャネル）
(I) システム内の情報伝送路。
（covert channel 参照。）
　
$ CHAP
Challenge Handshake Authentication Protocol 参照。
 
　
$ checksum （チェックサム）
(I) 次のような値。
(a) データオブジェクトの内容に依存する関数によって計算され、
(b) データ内の変更を検出するために、オブジェクトと共に保存または転送される。
（cyclic redundancy check, data integrity service, error detection code, hash function, keyed hash, protected checksum 参照。）

(C) データオブジェクトが変更されていないという各章を得るために、後でデータを使用する主体はチェックサムを計算し、オブジェクト共に保存されているまたは転送されたチェックサムと比較することができる。
　
(C) コンピュータシステムとネットワークは、データの偶発的な変更を検出するためにチェックサム（および他のメカニズム）を採用する。しかし、能動的に回線を盗聴した者は、変更されたデータと一致するように、対応するチェックサムを変更できる。それゆえ、チェックサム関数自体、能動的な攻撃に対してはあまり良い対策ではないものもある。能動的な攻撃を防御するには、チェックサム関数を慎重に選択し（cryptographic hash 参照）、チェックサムの結果を暗号化して保護する必要がある。
（digital signature, keyed hash 参照。）
　
$ chosen-ciphertext attack （選択暗号文攻撃）
(I) 分析者が、選択した（たとえば、書き取った）暗号文に対応する平文を知っている状態で、鍵の解読を試みる暗号解析テクニック。
 
　
$ chosen-plaintext attack （選択平文攻撃）
(I) 分析者が、選択した（たとえば、書き取った）平文に対応する暗号文を知っている状態で、鍵の解読を試みる暗号解析テクニック。
　
$ CIAC
Computer Incident Advisory Capability 参照。
　
$ CIK
cryptographic ignition key 参照。
　
$ cipher
(I) 暗号化・複号のための暗号アルゴリズム。
 
　
$ cipher block chaining (CBC)
(I) 生成した暗号文ブロックを取り込むことによって、EBC (Electronic CodeBook) モードを拡張したブロック暗号モード。[FP081]
（ [R1829], [R2451] 参照。）

(C) このモードでは、アルゴリズムから出力された暗号文ブロックを次の平文ブロックと組み合わせ（排他的論理和をとる）、これをアルゴリズムの次の入力ブロックとする。
　
$ cipher feedback (CFB)
(I) 生成した暗号文ブロックを取り込み、ブロック長以下の平文の可変長セグメントと演算を行うことによって、EBC (Electronic CodeBook) モードを拡張したブロック暗号モード。 [FP081]

(C) このモードでは、直前に生成された暗号文セグメントをアルゴリズムの入力として使用し（つまり、暗号文をフィードバックする）、出力ブロックを生成する。次に、この出力ブロックを平文セグメント（ブロック長以下）と組み合わせ（排他的論理和をとる）、次の暗号文セグメントとする。
　
$ ciphertext （暗号文）
(I) (I) 暗号化によって変形され、意味情報コンテンツ（たとえば、その意味合いなど）が失われた、あるいは利用できないデータ。
（cleartext, plaintext 参照。）

(O) 「暗号化の使用過程で生成されたデータ。結果として得られたデータの意味情報は利用できない。」 [I7498 Part 2]
　
$ ciphertext-only attack  （暗号文単独攻撃）
(I) 分析者が、盗聴した暗号文のみの知識から単独で鍵の解読を試みる暗号解析テクニック（分析者は、暗号アルゴリズム、平文が書かれた言語、平文の案件、平文に含まれる可能性のある単語などの、他の手掛かりを得ることもある）。
　
$ CIPSO
Common IP Security Option 参照。
　
$ CKL
compromised key list 参照。
 
　
$ class 2, 3, 4, or 5 （クラス 2、3、4 または 5）
(O) 米国国防総省における用法：
リスクと防護する情報の価値に基づく PKI 証明のレベル。[DOD3]：
$ classification （秘密区分）
$ classification level （秘密区分レベル）
(I)
(1.) データ防護のために、階層的、制限的なセキュリティラベルが適用された、秘密区分された情報の集まり。
(2.) 情報への適用が必要な防護のレベル。
（security level 参照。）
　
$ classified （秘密区分とされた）
(I) セキュリティポリシーによって正式に要求され、データ守秘サービスを与えられ、防護状態を示すセキュリティラベル（暗黙的である可能性もある）を付けられた情報を表す（保存または転送されたもの、任意の形式）
（unclassified 参照。）

(C) この用語は、基礎となっている概念は政府部門以外においても適用できるが、主に政府部門、特に軍において使われる。例えば、米国国防総省において、これは、不正な公開に対する防護を要求するために「Executive Order 12958」（"Classified National Security Information", 1995年 4月20日）または以前の任意の命令に基づいて決められ、文書形式での自身の秘密区分状態を示すよう指定されている情報を意味する。
　
$ clean system （クリーンなシステム）
(I) 信頼されたソフトウェア配布メディアから、オペレーティングシステム、アプリケーションシステムソフトウェア、およびファイルを新規にインストールしたコンピュータシステム。

(C) セキュアな状況では、クリーンシステムは必ずしも必要ではない。
　
$ clearance （クリアランス）
security clearance 参照。
　
$ clearance level （クリアランスレベル）
(I) セキュリティクリアランスがユーザにアクセスを認可する情報のセキュリティレベル。
　
$ cleartext （平文）
(I) 意味的な情報内容（すなわち、意味）が理解できる、または直接利用できるデータ。
（plaintext 参照。）

(O) 「理解可能なデータ、この意味的な内容は利用できる。」 [I7498 Part 2]

(D) インターネット標準文書は、この用語を、"plaintext"（暗号化作業への入力）の同義語として使ってはいけない（SHOULD NOT）。これは、暗号化作業への入力は、それ自身が他の操作によって出力された暗号文である可能性があるためである。
（superencryption 参照。）
　
$ client （クライアント）
(I) 「サーバー（server）」と呼ばれる他のシステム主体によって提供されるサービスを要求し、使うシステム主体。
（server 参照。）

(C) 通常、要求側の主体はコンピュータプロセスで、人間のユーザの代わりに要求を実行する。サーバー自身が、他のサーバーのクライアントになっているケースもある。
　
$ CLIPPER chip （CLIPPER チップ）
(N) 暗号技術プロセッサをともなう集積回路（The Mykotronx, Inc. MYK-82）で、SKIPJACK 暗号化アルゴリズムを実装し、鍵預託をサポートする。
（CAPSTONE chip, Escrowed Encryption Standard 参照。）

(C) チップの鍵寄託方式は、チップの一意のシリアル番号を防護する、すべてのチップに共通の SKIPJACK 鍵を含み、チップによって暗号化されたすべてのデータを防護する、チップ固有の 2 番目の SKIPJACK 鍵を含む。2 番目の鍵は、分割鍵コンポーネントとして、NIST および米国財務省によって保持される。
　
$ closed security environment （閉じたセキュリティ環境）
(O) 米国国防総省における用法：
次の両方の条件を満たすシステム環境：
(a) アプリケーション開発者（保守者も含む）が、悪意のコードを導入しなかったという受け入れ可能な仮定を提供するのに十分なクリアランスと権限を持っている。
(b) システムアプリケーションおよびそれを実行する装置が、アプリケーションの実行前および実行中に、悪意のロジックが導入されないように防護されていることを示す十分な保証を設定コントロールが提供する。[NCS04]
（open security environment 参照。）
　
$ code （コード）
(I) 名詞：
情報を表すのに使用される記号システムで、根源的に別のものを表す可能性がある。
（encode 参照。）

(D) インターネット標準文書は、この用語を次の用語の同義語として使ってはいけない（SHOULD NOT）。：
((a) "cipher"（暗号）、"hash"（ハッシュ）、または "a cryptographic algorithm"（暗号アルゴリズム）を意味する他の単語。；
(b) "ciphertext"（暗号文）または
(c) "encrypt"（暗号化）、"hash"（ハッシュ）、または暗号アルゴリズムの適用を示す他の単語。

(D) インターネット標準文書は、この単語を次の用語の略語として使ってはいけない（SHOULD NOT）。： country code（国コード）、cyclic redundancy code（循環冗長コード）、Data Authentication Code（データ認証コード）、error detection code（エラー検出コード）、Message Authentication Code（メッセージ認証コード）、object code（オブジェクトコード）、または source code（ソースコード）。 誤解を避けるために、少なくとも最初の使用時に、完全修飾した用語を使用すること。

　
$ color change （色変更）
(I) 定期的な処理モードで運用されているシステムにおいて、1 つの処理期間のすべての情報を廃棄し、次の処理期間に移行する行為。
　
$ Common Criteria （コモンクライテリア）
$ Common Criteria for Information Technology Security
(N) 「コモンクライテリア」は、オペレーティングシステム、コンピュータネットワーク、分散システム、およびアプリケーションなどの IT 製品を評価する際の標準である。コモンクライテリアは、セキュリティ機能および保証基準の要件を示す。 [CCIB]

(C) カナダ、フランス、ドイツ、オランダ、イギリス、米国（NIST および NSA）は、1993 年から、European ITSEC, Canadian Trusted Computer Product Evaluation Criteria (CTCPEC)、米国「Federal Criteria for Information Technology Security」 (FC)、およびその前身の TCSEC に基づいて、この標準の開発に着手した。作業は、ISO/IEC JTC 1 SC 27 （セキュリティテクニック）の WG 3 (セキュリティクライテリア) と共同して行われた。クライテリアの Version 2.1 は、ISO/IEC の IS 15408 と等価である。[I15408] 米国政府は、この標準によって TCSEC と FIPS PUB 140-1 の両方を最終的に置き換える予定である。
（NIAP 参照。）

(C) データ守秘性、データ完全性、可用性を示す標準で、セキュリティの他の様相に適用される可能性がある。これは、悪意かそうでないかに関わらず、人間の活動から発生した情報への脅威に焦点を当てるが、人的以外の脅威に適用される。これは、ハードウェア、ファームウェア、またはソフトウェアに実装されたセキュリティ尺度に適用されるが、次のものには適用されない。
(a) 技術セキュリティとは直接関連のない管理的なセキュリティ
(b) 電磁放射制御等のセキュリティの物理的な技術面
(c) クライテリアが適用される可能性のある評価方式、または管理的および法的な枠組み
(d) 評価結果を使用するための手続き
(e) 暗号アルゴリズム固有の品質の評価
　
$ Common IP Security Option (CIPSO)
Internet Protocol Security Option （における 2番目の定義）参照。
　
$ common name
(以下の文字列を示す。
(a) ディレクトリオブジェクト（"commonName" 属性）の X.500 DN の一部である可能性があり、
(b) 何らかの制限付きスコープ内でオブジェクトが一般的に知られるために使用されている名前（多義の可能性がある）で、
(c) それが対応する国または文化での命名規則に従う。 [X520]
（X.509 public-key certificate （における"subject", "issuer"）参照。）

(C) 例： "Dr. E. F. Moore", "The United Nations" または "12-th Floor Laser Printer"。
　
$ communication security (COMSEC)
(I) 通信システムのセキュリティサービスを実装および保証する方法。特に、データの守秘性、完全性、および通信を行う主体間の認証を提供するものをいう。

(C) 通常、暗号技術的アルゴリズムと鍵管理の方式とプロセス、これらを実装するデバイス、および鍵素材とデバイスのライフサイクル管理を含むものと理解されている。
　
$ community string
(I) SNMP version 1 で平文のパスワードとして機能する 8 進の文字列形式のコミュニティ名。 [R1157]
　
$ compartment （コンパートメント）
(I) 情報の基本的な秘密区分によって提供されるアクセスコントロールに加えて特殊なアクセスコントロールを必要とする秘密情報項目のグループ。
（category 参照。）

(C) この用語は、通常、情報のために使用される特殊な処理手順を含むものと理解されている。
　
$ compromise （侵す）
data compromise, security compromise 参照。
　
$ compromised key list (CKL)
(O) MISSI における用法：
権限のない公開または変更が行われた可能性のある鍵を識別するリスト。
（compromise 参照。）

(C) CKL は CRL の発行と同様に、CA によって発行される。しかし、CKL は KMID のみを示すだけで、鍵を保持する主体または鍵が関連付けられている証明書は示さない。
　
$ COMPUSEC
computer security 参照。
　
$ computer emergency response team (CERT)
(I) コンピュータおよびネットワークの情報セキュリティ（INFOSEC）を研究する組織で、攻撃の被害者へのインシデントレスポンスサービスの提供、脆弱性と脅威に関するアラートの発行、およびコンピュータとネットワークのセキュリティを改善するその他の情報の提供を目的とする。
（CSIRT, security incident 参照。）

(C) 例： カーネギー・メロン大学の Coordination Center（単に「CERT」と呼ばれることがある）、Computer Incident Advisory Capability。
　
$ Computer Incident Advisory Capability (CIAC)
(N) 米国エネルギー省にある CERT （computer emergency response team）。
　
$ computer network （コンピュータネットワーク）
(I) サブネットワークまたは内部ネットワークを伴うホストコンピュータの集まりで、これを介して相互にデータを交換できる。

(C) この定義は、他のコンピュータのリモート端末としてダイヤルインを行う 1 台のパーソナルコンピュータで構成される単純なシステムから複雑なインターネットに至るまで、すべての規模と種類のシステムをカバーすることを目的としている。
　
$ computer security (COMPUSEC) （コンピュータセキュリティ）
(I) コンピュータシステムのセキュリティサービスを実装し保証する方法で、特にアクセスコントロールサービスを保証するものをいう。

(C) 通常、コンピュータハードウェアおよびソフトウェア（特に、オペレーティングシステム）の機構、機能、および技術的特性を含むものと理解されている。
　
$ computer security incident response team (CSIRT)
(I) 「定義された構成員のサイトに関連するセキュリティインシデントへのレスポンスを調整およびサポートする」組織体。 [R2350]
（CERT, FIRST, security incident 参照。）

(C) CSIRT と見なされるためには、組織体は、次のことをしなければならない。：
$ computer security object
(I) コンピュータ化された環境で、セキュリティの状態を維持するために使用されるリソース、ツール、またはメカニズムを定義または表現するもの。異なるユーザコミュニティによって選択または定義された標準において参照される多くの要素が含まれる。[CSOR]
（object identifier, Computer Security Objects Register 参照。）
　
$ Computer Security Objects Register (CSOR)
(N) NIST によって運営されているサービスで、一意の名前によって識別される安定したオブジェクト定義を提供するために、コンピュータセキュリティ用のカタログを構築している。このレジスターを使用することにより、セキュアなデータ交換において、セキュリティパラメータおよびアルゴリズムの正確な指定が可能になる。

(C) CSOR は、国際標準コミュニティおよび ANSI によって確立された登録ガイドラインに従う。これらのガイドラインは、登録認定業者の最小限の責任を定め、国際登録階層の最上位の分岐を与える。この国際登録階層において、CSOR は分岐の元で一意の識別子を割り当てる責任を持つ {joint-iso-ccitt(2) country(16) us(840) gov(101) csor(3)}。
　
$ COMSEC
communication security 参照。
　
$ confidentiality （守秘性）
data confidentiality 参照。
　
$ configuration control （設定コントロール）
(I) システムの開発および運用のすべての段階において、ハードウェア、ファームウェア、ソフトウェア、およびドキュメントへの変更を統制するプロセス。
（administrative security 参照。）

(C) 設定コントロールは、権限のない変更または悪意の変更を防止し、システムの完全性を提供するのに役立つ。
（malicious logic 参照。）
　
$ confinement property （監禁属性）
Bell-LaPadula Model （における 2番目の定義）参照。
　
$ connectionless data integrity service
(I) ストリーム内のデータグラムの順番を考慮することなく、データグラムの変更を検出することによって、個々の IP データグラムに対するデータインテグリティサービスを提供するセキュリティサービス。

(C) コネクション指向のデータインテグリティサービスは、データグラムのストリーム内で、失われたまたは順番が変更されたデータグラムを検出できなければならない。
　
$ contingency plan （緊急時対応計画）
(I) セキュリティプログラムの一環として、重要なシステムリソースの可用性を維持し、危機下での運用の継続を促進するために、緊急対応、バックアップ作業、および災害後の復旧をシステム内で行うための計画。 [NCS04]
（availability 参照。）
　
$ controlled security mode
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。これは、米国国防総省のシステム運用承認を規制するポリシーの以前のバージョンにおいて規定されていたが、 現在のバージョンでは「区分されたセキュリティモード」に包括された。[DOD2]

(C) 情報システムにおける運用モードを示す用語。このモードでは、システムへのアクセス権を持つ少なくとも一部のユーザーは、セキュリティクリアランスを持たず、システムに含まれる秘密区分されたすべての素材を知る必要性も持たない。しかし、身元保証と秘密区分レベルに基づくユーザーおよび秘密区分された素材の分割とコントロールは、「マルチレベルセキュリティ」のように、必ずしもオペレーティングシステムのコントロールに従う必要はない。

(C) コントロールされたモードは、「専用セキュリティモード」や「システム高セキュリティモード」よりも制限がゆるく、真の「マルチレベルセキュリティモード」に一般的に対応するレベルよりはリスクの低いレベルで、防御ポリシーの要件に合致させることを目的としている。これは、システムへの同時アクセスが許可されているユーザーの身元保証レベルの特定の制限と共に、システムソフトウェアの脆弱性の実質的な尺度を削除または削減する明示的な方法を実装することにより、達成される。
　
$ cookie （クッキー）
(I) アクセスコントロールにおける用法：
アクセスコントロールシステムにおける"capability"もしくは"ticket"についての同義語。

(I) IPsec における用法：
セキュリティ協定（SA）の確立の間に特定のサービス否認攻撃を防止するために、ISAKMP によって交換されるデータ。

(I) HTTP における用法：
状態情報をクライアント側に保存し、将来、取り出してサーバーで使用するために、HTTP サーバーとブラウザ（サーバーのクライアント）間で行われるデータの交換。

(C) HTTP サーバーはデータをクライアントに送信するとき、HTTP 接続が終了した後もクライアントによって保持されるクッキーを送信することがある。サーバーは、このメカニズムを使用して、以降の接続で状態情報を取得することにより、HTTP ベースのアプリケーションに対するクライアント側の状態情報を永続的に得ることができる。クッキーには、状態が有効となる URL 範囲の説明が含まれることがある。将来、この範囲内でクライアントからリクエストが発行されると、クッキーの現在の値がサーバーに送信される。クッキーは、Web での行動習慣を示すプロファイルの生成に使用されることがあるので、個人のプライバシー侵害につながることもある。
　
$ Coordinated Universal Time (UTC)
(N) UTC は International Atomic Time (TAI) に閏秒を追加することによって算出される。国際度量衡局（International Bureau of Weights and Measures）は、毎月１回、多くの研究所からのデータの平均を求めることにより、TAI を計算する。
（GeneralizedTime, UTCTime 参照。）
　
$ copy
card copy 参照。
　
$ correctness integrity
(I) データそのものではなく、データの値が表す情報の正確性と完全性。アカウンタビリティおよびエラー処理の問題に強く関連している。
（data integrity, source integrity 参照。）
　
$ correctness proof
(I) システムセキュリティの仕様と、その仕様の実装との間の整合性の数学的な証拠。
（formal specification 参照。）
　
$ countermeasure （対策）
(I) 脅威、脆弱性、または攻撃を減少させる行為、デバイス、手順、またはテクニック。終了、防御、被害の最小化、発見と通知による修正行為の実行をともなう。

(C) インターネットプロトコルにおいて、対策はプロトコル機能、要素関数、または使用制限の形態をとることがある。
　
$ country code （国コード）
(I) ISO によって、国のために定義された識別子。 [I3166]

(C) ISO Standard 3166 は、各国ごとに、アルファベット 2 文字による一意のコード、アルファベット 3 文字による一意のコード、および 3 桁のコードを定義している。これらのコードの多くの使用法の中でも、2 文字のコードはトップレベルドメイン名として使用されている。
　
$ covert channel （裏チャネル）
(I) 2つの協働しているエンティティが、その認可された範囲を超えることなく、システムのセキュリティポリシーを侵害するやり方で情報を転送することを許してしまうシステム内チャネル。
（channel, out of band 参照。）

(O) 「2つの協働しているプロセスが、システムのセキュリティポリシーを侵害する作法で情報を転送することを許してしまう通信チャネル。」 [NCS04]

(C) 協働している当該エンティティは、2者とも内部者であっても、もしくは、1内部者と 1外部者である可能性がある。当然ながら、外部者は、全くアクセス認可をもたない。covert channel は、システムアーキテクチャが設計していないし、また、情報を転送することを意図していないシステムの失敗である。：
$ CPS
certification practice statement 参照。
　
$ cracker （クラッカー）
(I) 招かれざすに、他のシステムのセキュリティを破る、または他のシステムへのアクセス権を得ることを試みる者。
（hacker, intruder 参照。）
　
$ CRAM
Challenge-Response Authentication Mechanism 参照。
　
$ CRC
cyclic redundancy check 参照。
　
$ credential (s) （クレデンシャル）
(I) 主張された同一性またはシステムエンティティの認可を確立するために転送または提示されるデータ。
（authentication information, capability, ticket 参照。）

(O) 「エンティティの主張された同一性を確立するために転送されるデータ。」 [I7498 Part 2]
　
$ critical （クリティカル）
1. (I) 「クリティカル（Critical）」なシステム資源：
アクセスが拒否されると（たとえば、可用性の不足など）、主要な機能を実行するシステムユーザーの能力が奪われたり、他の重大な結果を引き起こすサービスまたは他のシステム資源の状態。
（availability, sensitive 参照。）

2. (N) 「クリティカル（Critical）」拡張：
X.509 証明書（または CRL）の各拡張は、クリティカルまたは非クリティカルのいずれかとして指定される。拡張がクリティカルであり、証明書ユーザ（または CRL ユーザ）が拡張タイプを認識できない、またはそのセマンティクスを実装できない場合は、ユーザは証明書を無効なものとして扱う必要がある。拡張が非クリティカルの場合は、拡張タイプを認識または実装できないユーザは、拡張を無視し、証明書（CRL）の残りの部分を処理することができる。
　
$ CRL
certificate revocation list 参照。
　
$ CRL distribution point
distribution point 参照。
　
$ CRL extension
extension 参照。
　
$ cross-certificate
cross-certification 参照。
　
$ cross-certification （横断認証）
(I) 2 つの CA 間で、一方の CA が他方の CA の公開鍵を認証し、その公開鍵証明書を発行する行為またはプロセス。

(C) 横断認証によって、別の認証階層で認証されているユーザ間でも、お互いの証明書を検証することができる。
　
$ cryptanalysis （暗号解析）
(I) システム設計において提供されている防護を破るのに必要な知識を得るために、暗号技術システムの解析を扱う数理科学。
（cryptology 参照。）

(O) 「守秘性のある変数および/または平文を含む秘密のデータを抽出するために、暗号技術的システムおよび/またはその入出力を解析すること。」 [I7498 Part 2]

(C) (O) の定義は従来の暗号解析の目標（つまり、鍵を使用せずに暗号文を平文（通常は、クリアテキスト）に変換すること）を示すが、この定義は暗号システムにのみ適用される。今日では、この用語はすべての種類の暗号アルゴリズムと鍵管理と関連して使用され、(I) の定義はこれを反映している。しかし、すべてのケースで、暗号解析者は、平文、鍵、またはアルゴリズムなどの機密データを開示または再生成することを試みる。暗号システムへの基本的な暗号解析攻撃には、暗号文単独攻撃、既知平文攻撃、選択平文攻撃、選択暗号文攻撃があり、これらは他の種類の暗号技術に標準化する。
　
$ crypto
(D) この用語集に載っている定義済みの特定の用語の一部を除いて、インターネット標準文書は、この短縮された用語を使ってはいけない（SHOULD NOT）。なぜなら、誤解される可能性があるからである。代わりに、"cryptography" もしくは "cryptographic" を使う。
　
$ cryptographic algorithm （暗号アルゴリズム）
(I) 暗号技術の科学を採用するアルゴリズム。暗号化アルゴリズム、 暗号技術的ハッシュ アルゴリズム、デジタル署名アルゴリズム、鍵共有アルゴリズムを含む。
　
$ cryptographic application programming interface (CAPI)
(I) アプリケーションプログラムが暗号技術的サービスにアクセスするときに使用するソースコードのフォーマットとプロシージャ。実際の実装と比べて抽象的に定義されている。
例： PKCS #11, [R2628] 参照。
　
$ cryptographic card
(I) スマートカードまたは PC カードの形態した暗号技術的トークン。
　
$ cryptographic component
(I) 暗号技術に関連する任意のシステムコンポーネントのための一般用語。
（cryptographic module 参照。）
　
$ cryptographic hash
hash function （における 2番目の定義）参照。
　
$ cryptographic ignition key (CIK)
(I) 暗号鍵を保存、転送、および保護するために使用される物理的な（通常は、電気的な）トークン。
(「crypto ignition key」と省略形で呼ばれることもある。)

(C) 典型的な使用方法は、CIK と暗号技術的モジュール間で分離鍵を分割することであり、この 2 つを組み合わせて鍵暗号化鍵を再生成し、モジュールとそれに含まれる他の鍵を活性化することが必要である。
　
$ cryptographic key
(I) 通常は、短く「鍵」と呼ばれる。暗号アルゴリズムによって実行される変形方法を変更する入力パラメータ。
　
(O) 「暗号化および復号化の処理を制御するシンボルの連続」 [I7498 Part 2]

(C) 鍵の値を秘密に保つ必要がある場合は、それを構成するシンボルの連続（通常はビット）はランダムにする、または少なくとも擬似的にランダムにしなければならない。これは、攻撃者が鍵を推測するのを難しくするためである。
（cryptanalysis, brute force 参照。）
　
$ Cryptographic Message Syntax (CMS)
(I) デジタル署名、ハッシュ、および任意のメッセージの暗号化を包括する構文。[R2630]

(C) CMS は PKCS #7 から継承した。CMS の値は ASN.1 で指定され、BER エンコーディングを使用する。構文では、ネスティングによる複数のカプセル化、メッセージコンテンツに沿った任意属性の署名、およびデジタル証明書ベースの鍵管理に対するさまざまなアーキテクチャのサポートが認められている。
　
$ cryptographic module （暗号技術的モジュール）
(I) 暗号技術的ロジックまたはプロセスを実装するハードウェア、ソフトウェア、ファームウェアまたはこれらの組み合わせで、暗号アルゴリズムを含み、モジュールの暗号技術的境界内に含まれる。これは、明確に定義された連続する境界線で、モジュールの物理的な境界を確立する。[FP140]
　
$ cryptographic system （暗号技術的システム）
(I) アプリケーションコンテキストでのアルゴリズムの使用をサポートする鍵管理プロセスを組み合わせた暗号アルゴリズムのセット。

(C) この (I) の定義は、下記 (O) の定義よりも広い範囲のアルゴリズムを網羅します。：

(O) 「平文から暗号文への変形、またはこの逆の変形の集まりで [ただし、デジタル署名、暗号技術的ハッシュ、鍵一致アルゴリズムは除外]、鍵によって選択された特定の変形が使用される。通常、変形は数学的アルゴリズムによって定義される。」 [X509]
　
$ cryptographic token （暗号技術的トークン）
(I) 可搬性があり、ユーザによって制御される物理デバイスで、暗号技術的情報の保存に使用される。暗号技術的機能を実行する可能性がある。
（cryptographic card, token 参照。）

(C) スマートトークンは、複数の暗号技術的アルゴリズムを実装する可能性があり、乱数生成器などの、関連するアルゴリズムと鍵管理機能を実装する可能性がある。スマート暗号トークンは、暗号技術的モジュールを含むか、あるいはそのように明示的に設計されていない可能性がある。
　
$ cryptography （暗号技術）
(I) 意味を理解不能にする（すなわち、意味内容を隠す）、検出不能な変更を防止する、または権限のない使用を防止するためにデータの変形を扱う数理科学。
（cryptology, steganography 参照。）
　
(O) 「情報内容の秘匿、検出不能な変更の防止、および/または権限のない使用の防止を目的としたデータの変形に対する原理、手段、方法を具体化する専門技術. . . . 暗号技術は、暗号化と復号化に使用する方法を決定する。」 [I7498 Part 2]
　
$ Cryptoki
PKCS #11 （における 2番目の定義）参照。
　
$ cryptology
(I) 暗号技術と暗号解析の両方を含む科学であり、ステガノグラフィーを含むこともある。
　
$ cryptonet
(I) 共通鍵アルゴリズムの秘密暗号鍵を共有するシステム主体のグループ。
　
$ cryptoperiod （暗号有効期間）
(I) 特定の鍵が暗号技術システムでの使用を認定された期間。
（key management 参照。）

(C) 暗号有効期間（cryptoperiod）は、通常、日時での期間で示されるが、暗号アルゴリズムで鍵を使用して処理できるデータの最大量で示されることもある。暗号有効期間（cryptoperiod）の指定は、鍵再生成のコストと暗号解析の成功のリスクのトレードオフをともなう。

(C) われわれはその接頭辞については不賛成であるが、この用語は COMPUSEC における伝統的な用法である。
（crypto 参照。）
証明書と公開鍵の文脈において、 しばしば、"key lifetime" と "validity period" が代わりに使われる。
　
$ cryptosystem
(D) インターネット標準文書は、この用語を cryptographic system の略語として使ってはいけない（SHOULD NOT）。
（理論については、crypto 参照。）
　
$ CSIRT
computer security incident response team 参照。
　
$ CSOR
Computer Security Objects Register 参照。
　
$ cut-and-paste attack （カットアンドペースト攻撃）
(I) 暗号文のデータの完全性に対する能動的な攻撃。暗号文のセクションを他の暗号文のセクションで置き換え、結果的には正しく復号されているように見えるが、実際には、攻撃者の意図どおりに偽造するような攻撃。
　
$ cyclic redundancy check (CRC)
(I) しばしば、"cyclic redundancy code" と呼ばれる。チェックサムアルゴリズムの一種で、暗号技術的ハッシュではないが、データが偶発的に変更される可能性のある状況で、データインテグリティサービスを実装するために使用される。

B<- 3 ->D