U<- 3 ->W

V English　

$ v1 certificate （v1 証明書）
(C) 曖昧に、バージョン 1 フォーマットの X.509 公開鍵証明書か、あるいは、バージョン 1 フォーマットの X.509 属性証明書のいずれかをいう。しかし、この用語を使う多くの人々は、「X.509 が公開鍵を含まない属性証明書を規定すること」を知らない。それゆえ、インターネット標準文書は、この用語を "version 1 X.509 public-key certificate" の短縮語として使うことができる（MAY）が、初回に完全な用語を使った後に限られる。

(D) インターネット標準文書は、この用語を "version 1 X.509 attribute certificate" の省略語として使ってはいけない（SHOULD NOT）。

$ v1 CRL
(I) "X.509 CRL in version 1 format"の略語。

(C) インターネット標準文書は、初回に完全な用語を使い、この略語を定義した後にのみ、この略語を使う必要がある。

$ v2 certificate （v2 証明書）
(I) "X.509 public-key certificate in version 2 format" の略語。

(C) インターネット標準文書は、初回に完全な用語を使い、この略語を定義した後にのみ、この略語を使う必要がある。

$ v2 CRL
(I) "X.509 CRL in version 2 format" の略語。

(C) インターネット標準文書は、初回に完全な用語を使い、この略語を定義した後にのみ、この略語を使う必要がある。

$ v3 certificate （v3 証明書）
(I) "X.509 public-key certificate in version 3 format" の略語。

(C) インターネット標準文書は、初回に完全な用語を使い、この略語を定義した後にのみ、この略語を使う必要がある。

$ valid certificate （有効な証明書）
(I) 結合されているデータが信用できるとするデジタル証明書。； 検証可能な証明書。
（validate vs. verify 参照。）

$ valid signature
(D) インターネット標準文書は、この用語を使ってはいけない（SHOULD NOT）。； 代わりに、"authentic signature" を使う。この小辞典は、"validate the certificate" や "verify the signature" と言うことを推奨する。； それゆえ、署名が "valid" であるということは、整合しないことになろう。
（validate vs. verify 参照。）

$ validate vs. verify （「十分性の検証」対「正確性の検証」）
(C) PKI コミュニティは、「証明書ユーザがデジタル証明書が信用できることの確認を行うこと」を記述するとき、用語を整合性無く使う。通常、我々は、「署名を検証する（verify the signature）」と言うが、「証明書を検証する（validate the certificate）」と言う。； すなわち、我々は、原子の真実を "verify" するが、"verify" された要素から成る、あるいは、"verify" された要素に依拠するデータ構造、関係およびシステムを "validate" する。しかし、あまりに頻繁に、verify と validate は、交替に使われる。インターネット標準文書は、整合性を確保するためと、 インターネットのセキュリティ用語法を普通の英語に整合させるために、次の 2つのルールに準拠する必要がある（SHOULD）。：

ルール 1 についての理論は、「"valid"は、ラテン語における "strong" を意味する単語に由来するものである」ということである。それゆえ、"to validate" は、データが十分であることを確認することを意味する。証明書ユーザは、その証明書が宣言する身元と鍵の結合において、信用を確立するために公開鍵証明書を validate する。（また、"to validate" は、何かを公式に承認することも意味する可能性がある。； 例： NIST は、暗号技術的モジュールの FIPS PUB 140-1 への準拠性を検証する。)

ルール 2 についての理論は、「"verify" は、ラテン語における "true" を意味する単語に由来するものである」ということである。それゆえ、"to verify" は、証拠を吟味すること、あるいは、テストを実施することによって、ある宣言の真実を提供することを意味する。身元を検証するために、認証過程は、提供もしくは生成された識別情報を試験する。証明書を検証するために、証明書ユーザは、処理を行うことによって、証明書上のデジタル署名を検証し、「現在時刻が証明書の有効期間内であること」を検証し、追加的な証明書を含む認証パスを検証する必要がある可能性がある。
　
$ validation （検証、有効性検証）
validate vs. verify 参照。

$ validity period （有効期間）
(I) デジタル証明書が CRL 上にある場合、もしくは、その鍵が CKL 上にある場合を除いて、データ要素間の結合（特に、サブジェクト名と、公開鍵証明書中のその公開鍵の値の結合） が有効である期間を規定するデジタル証明書中のデータ要素。

$ value-added network (VAN)
(I) EDI トランザクションを顧客に代わって転送、受信、蓄積する（通常、商業の企業の）コンピュータネットワークもしくはサブネットワーク。

(C) VAN は、また、EDI フォーマット変換から EDI-to-FAX 変換、統合化されたビジネスシステムまでにわたる追加的なサービスを提供する可能性がある。

$ VAN
value-added network 参照。

$ verification （（正確性の）検証）
1. システム検証：
a セキュリティポリシーと最上位の仕様を比較すること、最上位の仕様をソースコードと比較すること、あるいは、ソースコードをオブジェクトコードと比較することのように、正しい対応について、2 つのレベルのシステム仕様を比較する過程。[NCS04]
2. 身元検証：
主張されている身元が真実であることを確立するために情報を提供する。

$ verify （（正確性を）検証する）
validate vs. verify 参照。

$ violation （侵害）
security violation 参照。

$ virtual private network (VPN)
(I) 公衆のシステム資源から成る論理的な（すなわち、人工的、もしくは、シミュレートされた）コンピュータネットワークであり、（インターネットのような）物理的ネットワーク（すなわち、実際のネットワーク）の制限的な用法。暗号化を（ホストもしくはゲートウェイで）使うことによることもあれば、現実のネットワークをまたいで仮想的なネットワークのリンクをトンネリングすることによることもある。

(C) 例えば、企業は、いくつかの異なるサイトにおいて、ファイアウォールによって各々、インターネットに接続された LAN をもつ場合、この企業は、以下のように  VPN を構築できる。
(a) インターネットをまたいで、ファイアウォールからファイアウォールまで接続するために、暗号化されたトンネルを使う。
(b) ファイアウォール経由以外のいかなるトラフィックをも許可しない。
VPN を構築し、運用することは、一般に、専用の物理的なネットワークより安価である。なぜなら、仮想的ネットワークは、システム資源の費用を実在するネットワークの他のユーザと共有するからである。

$ virus （ウイルス）
(I) 他のプログラムに感染すること（すなわち、自身の複製を挿入し、その一部となること）によって広める、隠れた、コンピュータ ソフトウェアの自己増殖部分であり、通常、悪意あるロジック。ウイルスは、自身では動作することができない。； ウイルスは、その宿主プログラムが、そのウイルスを活動させるために動作させられることを必要とする。

$ VPN
virtual private network 参照。

$ vulnerability （脆弱性）
(I) システムのセキュリティポリシーを侵害するように攻略される可能性がある、システムの設計／実装／運用管理における欠陥もしくは弱点。
　
(C) 大部分のシステムは、何らかの脆弱性をもっているが、このことは、「そのシステムが使うには欠陥がありすぎること」を意味しない。脅威のずべてが攻撃につながるわけではなく、すべての攻撃が成功するわけではない。成功は、脆弱性の程度、攻撃の強さ、使われているあらゆる対策の有効性に依存する。その攻撃が実行することが非常に困難な脆弱性の攻略を必要とする場合、その脆弱性は、問題である可能性がある。攻撃者にとって利益が小さいと認識される場合、たとえ容易に攻略される脆弱性であっても、我慢できる可能性がある。しかし、その攻撃が良く理解されており、容易にできる場合、かつ、その脆弱なシステムが 広範に及ぶユーザによって採用されている場合、誰かが攻撃を行う利益が十分ある可能性が高い。

U<- 3 ->W