O<- 3 ->R


P English 

$ P1363
IEEE P1363 参照。
 
$ PAA
policy approving authority 参照。
 
$ packet filter (パケットフィルタ)
filtering router (における 2番目の定義)参照。
 
$ pagejacking
(I) "Web page hijacking" の短縮語。仮装(masquerade)攻撃のひとつ。ここで、攻撃者は、標的サーバー からホームページもしくは他の素材をコピー(盗用)し、攻撃者がコントロールするサーバー上にそのページを再掲載し、再掲載されたページが主要な Web 検索サービスによってインデックス化されるようにし、それによってブラウザーを標的サーバーから攻撃者のサーバーにそらす。

(D) インターネット標準文書は、定義を含めることなしに、この用語を使ってはいけない(SHOULD NOT)。なぜなら、この用語は、大部分の辞書に掲載されておらず、国際的な読者を混乱させる可能性があるからである。
Green Book (の用法における注意)参照。)
 
$ PAN
primary account number 参照。
 
$ PAP
Password Authentication Protocol 参照。
 
$ partitioned security mode (区分されたセキュリティモード)
(N) 情報システムの運用のモードのひとつ。ここでは、すべてのユーザがクリアランスをもつが、そのシステムによって扱われる情報について、公式なアクセス認可や need-to-know をもつことは必要不可欠ではない。このモードは、米国国防総省のシステム運用承認(system accreditation)に関するポリシーにおいて定義されている。[DoD2]
 
$ passive attack (待ち伏せ攻撃)
attack (における 2番目の定義)参照。
 
$ passive wiretapping (待ち伏せ回線盗聴)
wiretapping (における 2番目の定義)参照。
 
$ password (パスワード)
(I) 秘密のデータ値であり、通常、認証情報として使われる文字列。
challenge-response 参照。)

(C) パスワードは、通常、認証過程において明示的に提供されるユーザ ID と突き合わされるが、場合によっては、ユーザ ID は、黙示的である可能性がある。

(C) 認証情報としてのパスワードの使用は、「そのパスワードは 身元を認証中のシステム主体のみが知っていること」を想定する。それゆえ、回線盗聴可能なネットワーク環境においては、クリアテキスト形態の固定的な(すなわち、反復利用される)パスワードの転送に依存する単純な認証は、不適切である。
one-time password, strong authentication 参照。)
 
$ Password Authentication Protocol (PAP) (パスワード認証プロトコル)
(I) PPP におけるシンプルな認証メカニズム。PAP において、ユーザ識別子とパスワードが、平文で送信される。 [R1334]
CHAP 参照。)
 
$ password sniffing (パスワード盗聴)
(I) 待ち受け回線盗聴。通常、パスワードの知識を得るため、LAN 上においてなされる。
sniffing (における用法)参照。)
 
$ path discovery (パス発見)
(I) デジタル証明書について、信用された鍵から、その特定の証明書に至る認証パスを構成する一連の公開鍵証明書を発見する過程。
 
$ path validation (パス検証)
(I)
(a) 認証パス中のすべてのデジタル証明書、および
(b) それらの証明書間に要求される関係について
検証する処理。それゆえ、パス上の最後の証明書の内容を検証する。
certificate validation 参照。)
 
$ payment card (決済カード)
(N) SET における用法:
「金融機関によって発行され、カード所持社と金融機関の間の関係を反映するクレジットカード、デビットカード、チャージカードおよび銀行カード 」 [SET2] の総称。
 
$ payment gateway (決済ゲートウェイ)
(O) SET における用法:
購買者の支援を得て、商人に電子商取引サービスを提供する目的で、購買者によって操作されるシステム、もしくは、購買者によって指定された第三者であり [SET1, SET2]、これは、購買者に、その認可、捕捉、および、商人の決済メッセージの処理を支援するために提示され、カード所持者からの決済指示を含む。
 
$ payment gateway certification authority (SET PCA)
(O) SET における用法:
決済ゲートウェイに対するデジタル証明書を発行し、ブランドのルールに従って、決済カードのブランド、購買者もしくは、それ以外の主体の代わりに運用される CA。SET PCA は、侵された決済ゲートウェイ証明書について CRL 発行する。[SET2]
PCA 参照。)
 
$ PC card (PC カード)
(N) クレジットカードの大きさのプラグイン周辺機器。これは、当初、ノート PC 用のメモリー拡張を提供するために開発されたが、他の機能拡張のためにも使われる。
FORTEZZA, PCMCIA 参照。)

(C) 国際的な PC カード標準は、汎用的な形態を 3つの標準サイズ(タイプ I、タイプ II およびタイプ III)として規定しており、その各々は、そのカードとそれを挿すソケットの間に 68 ピンのインターフェイス をもつ。3 種のすべては、同一の長さと幅をもち、クレジットカードくらいの大きさであるが、厚さが 3.3 mm のものから 10.5 mm のものまである。例には、ストレージモジュール、モデム、デバイスインターフェィスアダプターおよび暗号技術的モジュールが含まれる。
 
$ PCA
(D) インターネット標準文書は、修飾する形容詞なしに、この略語を使ってはいけない(SHOULD NOT)。なぜなら、曖昧になるからである。
Internet policy certification authority, (MISSI) policy creation authority, (SET) payment gateway certification authority 参照。)
 
$ PCMCIA
(N) Personal Computer Memory Card International Association。製造者、開発者およびベンダーから成るグループ。PC 用のプラグイン周辺機器であるメモリカードを標準化するために1989年に設立され、現在、PC カードの形態で動作するあらゆる技術を扱うように拡張された。
PC card 参照。)
 
$ peer entity authentication (ピア主体認証/相対主体認証)
(I) 「協定中の相手(ピア主体)が本人であるとする共同の手順。」 [I7498 Part 2]
authentication 参照。)
 
$ peer entity authentication service (ピア主体認証サービス/相対主体認証サービス)
(I) 主張する者、もしくは、協定におけるシステム主体についての身元を検証するセキュリティサービス。
authentication, authentication service 参照。)

(C) このサービスは、ある主体の身元を他方に確認させる協定の確立時、もしくは、その過程において使われ、それゆえ、最初の主体による仮装から防護する。しかし、データ発信元認証サービスとは異なり、このサービスは、2 つの主体間に協定が存在すること、および、当該サービスによって提供される確認がサービスが提供れる時点においてのみ妥当であることを要求する。

(C) data integrity service における「データインテグリティサービスと認証サービスの関係」参照。
 
$ PEM
Privacy Enhanced Mail 参照。
 
$ penetration (侵入)
(I) 防護されたシステム資源に対するアクセスであり、完遂する可能性と反復可能性がある認可されていないもの。
attack, violation 参照。)
 
$ penetration test (侵入テスト)
(I) システム テストのひとつ。 しばしば、システム認定の部分である。ここで、評価者は、システムのセキュリティ機能を迂回することを試みる。[NCS04]

(C) 侵入テストは、様々な制約や条件下で行われる可能性がある。しかし、TCSEC 評価について、評価者は、ソースコード、マニュアルおよび回路図を含むすべてのシステム設計と実装についての文書をもち、通常のユーザについての制約と比べて厳しくない制約のもとで働くと想定されている。
 
$ perfect forward secrecy
public-key forward secrecy (における検討)参照。
 
$ perimeter (境界)
security perimeter 参照。
 
$ periods processing (間隔処理)
(I) システム運用のモードのひとつであり、ここでは、程度が異なる秘密区分の情報が、同一のシステムによって、明確に異なる時間帯に、そのシステムが間の時間に正しく清められるようにして、(あるいは、浄化されるようにして)処理される。
color change 参照。)
 
$ permission (認可)
(I) 「認可(authorization)」の同義語であるが、PKI の文脈においては、「認可(authorization)」が選好される。
privilege 参照。)
 
$ personal identification number (PIN)
(I) システム資源に対してアクセスできるようにするためのパスワードとして使われる文字列 。
authentication information 参照。)
 
(C) "identification" と "number" の単語から成るにも関わらず、PIN は、めったにユーザ識別子の役割を果たさず、PIN の文字は必ずしも数値である必要はない。この概念についての、より良い名前は、PASS(Personal Authentication System String)である。
 
(C) リテール銀行アプリケーションは、通常、4 文字の PIN を使う。FORTEZZA PC カードは、ユーザもしくは SSO PIN について 12 文字までのものを使う。
 
$ personality (人格)
$ personality label (人格ラベル)
(O) MISSI における用法:
カードのユーザが果たす役割をサポートするために、FORTEZZA PC カード上に保管されている関連するプライベート鍵や仕様の用法とともに、同一のサブジェクト DN をもつ MISSI X.509 公開鍵証明書の集合。

(C) カードのユーザが FORTEZZA 対応アプリケーションにおいて使うために人格を選択するとき、そのデータは、そのアプリケーションの行為の特徴(その人格)を判定する。カードのユーザは、カード上に複数の人格をもつ可能性がある。各々は、「人格ラベル」をもつ。(これは、アプリケーションが、使われるべき人格を選択/変更するために、ユーザに表示できるユーザにとって親和的な文字列である。)例えば、軍事的ユーザのカードは、3 つの人格を含む可能性がある。:
  • GENERAL HALFTRACK
  • COMMANDER FORT SWAMPY
  • NEW YEAR'S EVE PARTY CHAIRMAN
各人格は、(「デジタル署名」対「暗号化」のような)異なる目的ことに、あるいは、異なる認可ごとに(DSA 対 RSA のように)異なる種類の、ひとつ、もしくは、複数の証明書を含む。
 
$ personnel security (要員的セキュリティ)
(I) 「システムにアクセスする者が、当該システムのセキュリティポリシーによって要求される正統なクリアランス、認可および『need-to-know』をもつこと」を確保するための手順。
 
$ PGP (登録商標)
Pretty Good Privacy 参照。
 
$ Photuris
(I) UDP に基づくセッション鍵のための鍵確立プロトコル。IPsec プロトコルの AH および ESP とともに利用するために設計された。IKE によって廃止された。
 
$ phreaking (フリーキング)
(I) 「電話フリーキング(telephone breaking)」の短縮語。電話システム(もしくは、拡大して、あらゆる他の通信もしくは情報システム)上、もしくは、これに対する攻撃。[Raym]

(D) インターネット標準文書は、この用語を使ってはいけない(SHOULD NOT)。なぜなら、この用語は、大部分の辞書に掲載されておらず、国際的な読者を混乱させる可能性があるからである。
 
$ physical security (物理的セキュリティ)
(I) システムに対する無権限な物理的アクセスを予防する有形の手段。
(例: フェンス、壁および他の障壁; 錠、金庫および金庫室; 番犬および武装した警護; センサーやアラーム(ベル))[FP031, R1455]
 
$ piggyback attack (ピギーバック攻撃/未利用時間における攻撃/肩車攻撃)
(I) 積極的な回線盗聴の 1 形態。ここで、攻撃者は、別のユーザによる正規の通信接続が無い時間にシステムに対するアクセス権限を得る。しばしば、「未利用時間(between-the-lines)」における攻撃と呼ばれる。
hijack attack, man-in-the-middle 参照。)
 
$ PIN
personal identification number 参照。
 
$ ping of death (死の ping)
(I) 宛先マシンの入力バッファをオーバーフローさせる意図をもって、不正に大きい ICMP [R0792] echo リクエストパケット("ping")を送信し、それをクラッシュさせる攻撃。
 
$ ping sweep (ping スィープ)
(I) 脆弱性について探査可能なホストを発見する目的で、ICMP [R0792] echo リクエスト("ping")を IP アドレス帯宛に送信する攻撃。
 
$ PKCS
Public-Key Cryptography Standards 参照。
 
$ PKCS #7
(N) PKCS シリーズ中の標準 [PKC07, R2315] のひとつ。; デジタル署名やデジタル封筒のような暗号技術が適用される可能性があるデータについての構文を規定する。
 
$ PKCS #10
(N) PKCS シリーズ中の標準 [PKC10] ; 公開鍵証明書のリクエストについて構文を規定している。
certification request 参照。)

(C) PKCS #10 リクエストは、DN および公開鍵を含んでおり、他の属性を含む可能性があり、リクエストを行う主体によって署名される。当該リクエストは、X.509 公開鍵証明書(もしくは、何らかの他の形態)に変換して送り返す CA 宛に、おそらく PKCS #7 フォーマットで送られる。
 
$ PKCS #11
(N) PKCS シリーズ中の標準 [PKC11] ;
暗号技術的情報を保持し、暗号技術的機能を行うデバイスのための Cryptoki ("crypto-key" と発音される。; "cryptographic token interface" の短縮語)と呼ばれるソフトウェア CAPI を規定する。
 
$ PKI
public-key infrastructure 参照。
 
$ PKIX
(I)
(1.) "Public-Key Infrastructure (X.509)" の短縮語であり、IETF ワーキンググループの名前、これは、インターネット用に X.509 に基づく PKI をサポートするために必要なアーキテクチャおよび一式のプロトコルを仕様化している。
(2.) このアークテク茶と一式のプロトコルについての総称。

(C) PKIX の目標は、複数のインターネットアプリケーションにおける X.509 公開鍵証明書の利用を容易にし、これらの証明書を使う異なる実装間における相互運用可能性を促進することにある。結果として、PKI は、一定範囲の信用および階層環境と、一定範囲の利用環境をサポートするフレームワークを提供することが意図されている。PKIX は、下記の事項を規定している。
(a) インターネット用の X.509 v3 公開鍵証明書標準、および X.509 v2 CRL 標準のプロファイル
(b) 証明書もしくは証明書状態のような情報を得るために利用者によって使われる運用プロトコル
(c) PKI の正しい管理のために必要とされる情報を交換するためにシステム主体によって使われる管理プロトコル
(d) PKIX の他の部分で直接には対応されていない PKI セキュリティの分野を範囲とする証明書ポリシーおよび CPS についての情報
 
$ PKIX private extension (PKIX プライベート拡張)
(I) PKIX は、発行 CA をサポートするオンライン検証サービスを識別するためのプライベートな拡張を規定している。
 
$ plaintext (プレーンテキスト)
(I) 暗号化処理に入力され、これによって変換されるデータ、もしくは、復号処理の出力であるデータ。

(C) 通常、暗号化操作へのプレインテキスト入力はクリアテキスト(平文)である。しかし、場合によっては、入力は、その他の暗号化操作の出力暗号文であることがある。
superencryption 参照。)
 
$ Point-to-Point Protocol (PPP)
(I) 2 ピア間のリンク上で、ネットワーク層(主に OSI 第 3 層)プロトコルデータパケットのカプセル化と全二重(full-duplex)転送のためと、同一リンク上に異なるネットワーク層のプロトコルをマルチプレックス化するためのインターネット標準プロトコル。[R1661] ネットワーク層データを交換する前に相手を相互に認証するために、ピア主体認証プロトコルを選択し、利用するためのオプションとしての交渉を含む。
CHAP, EAP, PAP 参照。)
 
$ Point-to-Point Tunneling Protocol (PPTP)
(I) (当初 Ascend と Microsoft によって開発された)クライアント/サーバー型インターネットプロトコルのひとつ。これは、ダイアルアップユーザが "PPP over IP" をトンネリングすることによって、ネットワークをまたいでダイアルアップのリンクの仮想的な拡張を作成することを可能にする。
L2TP 参照。)

(C) PPP は、あらゆるインターネットプロトコルスィートのネットワーク層プロトコル(もしくは、OSI 第 3 層プロトコル)をカプセル化できる。それゆえ、PPTP は、セキュリティ サービスを仕様としない。; これは、いかなる必要とされるセキュリティを提供するためにも、その上下層のプロトコルに依存する。PPTP は、最初のダイアルアップサーバー(すなわち、PPTP アクセス集約器(特定目的用ホスト上で動作するクライアント))の場所と、ダイアルアッププロトコル(PPP)接続の終点であり、ネットワークへのアクセスが提供される(すなわち、一般的目的のホスト上で動作する PPTP ネットワークサーバー)の場所を分離できるようにする。
 
$ policy
(D) インターネット標準文書は、"security policy" もしくは "certificate policy" の同義語として、この単語を使ってはいけない(SHOULD NOT)。代わりに、誤解を避けるため、少なくとも最初の用法において完全に修飾された用語を使う。
 
$ policy approving authority (PAA)
(O) MISSI における用法:
MISSI 認証階層(certification hierarchy)の最高位の署名機関。この用語は、その権威ある機関もしくは役割と、この役割を果たす者の両方をいう。
root registry 参照。

(C) PAA は、MISSI PCA を登録し、それらの X.509 公開鍵証明書に署名する。PAA は、CRL を発行するが、CKL は発行しない。PAA は、他の PAA に対して横断証明書を発行する可能性がある。
 
$ policy certification authority (Internet PCA)
(I) IPRA (Internet Policy Registration Authority)のもとで、インターネット認証階層の 2 番目のレベルに位置する X.509-compliant CA。各 PCA は、その発行されたセキュリティポリシー(certification practice statement 参照)に準拠し、すべての PCA について IPRA によって確立される制約内において運用される。[R1422]
policy creation authority 参照。)
 
$ policy creation authority (MISSI PCA)
(O) MISSI における用法:
MISSI 認証階層(certification hierarchy)の 2番目のレベル。;
MISSI ユーザのセキュリティポリシードメインの運用管理的ルート、および、他の付属機関。この用語は、機関のオフィスもしくは役割と、オフィス内に居る人間の両方をいう。
policy certification authority 参照。)

(C) MISSI PCA の証明書は、policy approving authority によって発行される。PCA は、その CA をドメイン中に登録し、その設定を規定し、PCA の X.509 公開鍵証明書を発行する。(PCA は、また、SCA、ORA、および他のエンド主体に証明書を発行する可能性があるが、PCA は、通常、これを行わない。) PCA は、定期的に CRL と CKL をそのドメイン宛に発行する。
 
$ Policy Management Authority (ポリシー管理機関)
(N) カナダにおける用法:
カナダ政府において、PKI 監督とポリシー管理に責任を負う組織体。
 
$ policy mapping (ポリシーマッピング)
(I) 「ドメイン中の CA が、その他のドメイン中の CA を認証するとき、2 番目のドメイン中の特定の証明書ポリシーが、最初のドメインの機関によって、最初のドメイン中の特定の証明書ポリシーと同等である(ただし、すべての事項に関して同一であるとは限らない)と見なされる可能性があると認識すること。」 [X509]
 
$ POP3
Post Office Protocol, version 3 参照。
 
$ POP3 APOP
(I) POP3 の「コマンド」(トランザクション種別、もしくは、プロトコル内プロトコルと表記した方がよい。)であり、これによって、POP3 クライアントは、オプションとして、自身を POP3 サーバーに認証させ、(サーバー実装によっては)リプレイ攻撃に対抗するために、(MD5 に基づく)鍵付きハッシュを使う。
CRAM, POP3 AUTH, IMAP4 AUTHENTICATE 参照。)

(C) サーバーは、クライアント宛の挨拶の際に、固有のタイムスタンプを含める。続いてクライアントによってサーバー宛に送られる APOP コマンドは、クライアントの名前と、「タイムスタンプ」と(クライアントとサーバーのみが知る)「共有された秘密」の両方から成る文字列に対して MD5 を適用したハッシュ結果を含む。APOP は、クライアントが平文パスワードをサーバー宛に送る POP3 の USER および PASS(すなわち、パスワード)コマンドのペアを使うことの代替手段を提供するために設計された。
 
$ POP3 AUTH
(I) POP3 における「コマンド」。(トランザクション種別、もしくは、プロトコル内プロトコルと表記した方がよい。)[R1734] これによって、POP3 クライアントは、オプションとして、POP3 サーバー宛にクライアントをサーバーに認証させるメカニズムを提案し、他のセキュリティサービスを提供する。
POP3 APOP, IMAP4 AUTHENTICATE 参照。)

(C) サーバーが提案を受容する場合、当該コマンドには、チャレンジ/レスポンス認証プロトコルの実行が続き、オプションとして、以降の POP3 の相互的活動についての防護メカニズムの交渉が続く。この POP3 AUTH によって使われるセキュリティメカニズムは、IMAP4 によって使われているものである。
 
$ port scan (ポートスキャン)
(I) 活動しているポートを発見し、そのサービスの既知の脆弱性を攻略する目的で、クライアントリクエストをホスト上のサーバーポート番号帯宛に送信する攻撃。
 
$ POSIX
(N) Portable Operating System Interface for Computer Environments。アプリケーションのソースコードのレベルにおける移植可能性をサポートするためのオペレーティングシステムのインターフェイスおよび環境を規定する標準。[FP151, IS9945-1] (元は IEEE 標準 P1003.1)これは、アプリケーション開発者とシステム実装者の両者によって利用されることを意図している。

(C) P1003.1 は、自由裁量的なアクセスコントロール(DAC)や特権を含む大部分の UNIX システムのセキュリティ機能のようなセキュリティ機能をサポートしている。IEEE ドラフト標準 P1003.6.1 は、基礎となる標準においては提供されない追加的な機能を規定し、下記の事項を含む。
(a) 自由裁量的アクセスコントロール
(b) 監査証跡メカニズム
(c) 特権メカニズム
(d) 強制的アクセスコントロール
(e) 情報ラベルメカニズム
 
$ Post Office Protocol, version 3 (POP3)
(I) インターネット標準プロトコルのひとつ [R1939]。これによって、クライアントワークステーションは、サーバーが受信し、クライアントのために保持しているメールメッセージを受信するためにサーバーホスト上のメールボックスに直接アクセスできる。
IMAP4 参照。)

(C) POP3 は、オプションとして、クライアントをサーバーに認証させ、他のセキュリティサービスを提供するメカニズムをもつ。
POP3 APOP, POP3 AUTH 参照。)
 
$ PPP
Point-to-Point Protocol 参照。
 
$ PPTP
Point-to-Point Tunneling Protocol 参照。
 
$ pre-authorization (事前認可)
(I) 認証リクエストが CA 宛に認可主体によって事前に提供されるデータに照らして、自動的に(正確性が)検証されることを可能にする CAW の能力主体。
 
$ Pretty Good Privacy (trademark) (PGP(登録商標))
(O) Network Associates 社の登録商標。インターネット上の電子メールや他のアプリケーションにデータセキュリティを提供するために暗号技術を使うコンピュータプログラム(および関連プロトコル)をいう。
MOSS, PEM, S/MIME 参照。)

(C) PGP は、IDEA の CFB モードによってメッセージを暗号化し、RSA で暗号化することによって IDEA 鍵を配布し、MD5 と RSA によってメッセージ上のデジタル署名を作成する。公開鍵の所有について確立するために、PGP は、「信用の輪(web of trust)」に依拠している 。
Privacy Enhanced Mail 参照。)
 
$ primary account number (PAN)
(O) SET における用法:
「カード発行者およびカード所持者を識別する割り当て番号。この口座番号は、発行者識別番号、個人口座番号識別、および、伴う ISO 7812-1985 によって規定されるチェックデジットから成る。」 [SET2, IS7812]
bank identification number 参照。)

(C) PAN は、磁気ストライプによるクレジットカード上に、浮き彫りされていたり、エンコードされていたり、その両方がなされている。PAN は、取引が配達される発行者、および、別段に特定の指示がなされない限り適用される口座を識別する。PAN の "bank identification number" 部分を割り当てる機関は、American Bankers Association である。
 
$ privacy (プライバシー)
(I) 自分のために活動している主体(通常は人間)が、その環境と相互にやりとりする程度を判定するための権利であり、当該主体が自身についての情報を他人と共有しても良いと考えている程度を含む。
(anonymity 参照。)
 
(O) 「自らに関するどの情報が、収集・蓄積される可能性があり、誰によって、誰宛に当該情報が開示できるかを支配し影響を与える個人の権利。」 [I7498 Part 2]

(D) インターネット標準文書は、この用語を「データ守秘性(data confidentiality)」もしくは「データ守秘性サービス(data confidentiality service)」の同義語として使ってはいけない(SHOULD NOT)。これらは、異なる概念である。プライバシーは、セキュリティの種類というよりも、セキュリティについての理由である。例えば、個人データを蓄積するシステムは、 データが維持管理されているあらゆる人間に対する加害、妨害、不便もしくは不公平を予防し、その人のプライバシーを守るために、データを防護する必要がある。その理由により、そのシステムは、データ守秘性サービスを提供する必要がある可能性がある。
 
$ Privacy Enhanced Mail (PEM)
(I) 電子メールにデータの守秘性、データのインテグリティ、および、データ発信元認証を提供するインターネットプロトコル。[R1421, R1422]
MOSS, MSP, PGP, S/MIME 参照。)

(C) PEM は、メッセージを DES の CBC モードで暗号化し、DES 鍵の鍵配布をそれらを RSA で暗号化することによって提供し、メッセージの MD2 か MD5 のいずれかのハッシュ結果上に RSA で署名する。公開鍵の所有権を確立するために、PEM は、認証階層を RSA と MD2 で署名された X.509 公開鍵証明書と X.509 CRL とともに使う。
Pretty Good Privacy 参照。)

(C) PEM は、広範な鍵管理手法と互換性があるように設計されたが、テキストメッセージについてのセキュリティサービスに限って仕様としたものであり、MOSS のように、インターネットにおいて広くは実装されてこなかった。
 
$ private component (プライベートなコンポーネント/プライベート鍵)
(I) "private key" の同義語。

(D) 大部分の場合、インターネット標準文書は、この用語を使ってはいけない(SHOULD NOT )。; 読者を混乱させることを避けるために、代わりに "private key" を使う。 しかし、この用語は、鍵ペアに特化して検討するときに使うことができる(MAY)。; 例: 「鍵ペアは、公開コンポーネントとプライベートなコンポーネントをもつ。」
 
$ private extension (プライベート拡張)
extension (における 2番目の定義)参照。
 
$ private key (プライベート鍵)
(I) 公開鍵暗号技術について使われる暗号技術的鍵のペアの秘密コンポーネント。
key pair, public key 参照。)

(O) 「(公開鍵暗号システムにおいて)ユーザの鍵ペアのうち、そのユーザのみが知っている鍵。」 [X509]
 
$ privilege (特権/権限)
(I) 特に、コンピュータのオペレーティングシステムについての文脈において、セキュリティ関連機能を行うための認可、もしくは一式の認可。
 
$ privilege management infrastructure
(N) 「認可サービスを提供するために要求される処理の全体。」すなわち、属性証明書に関する過程。[FPDAM]
PKI 参照。)

(D) インターネット標準文書は、この用語と、その定義を使ってはいけない(SHOULD NOT)。なぜなら、この定義は曖昧であり、代替的定義についてコンセンサスが無いからである。
 
$ privileged process (特権プロセス)
(I) 通常のプロセスには認可されていないある種のセキュリティ関連機能を行うことが認可され、(それゆえ信用されている)コンピュータプロセス。
privilege, trusted process 参照。)
 
$ procedural security
(D) インターネット標準文書は、"administrative security" の同義語として、この用語を使ってはいけない(SHOULD NOT)。あらゆる種類のセキュリティは、手順を含む可能性がある。; それゆえ、 この用語は、誤解を招く可能性がある。代わりに、"administrative security", "communication security", "computer security", "emanations security", "personnel security", "physical security" もしくは意味されている具体的なことを使う。
security architecture 参照。)
 
$ proprietary (情報資産)
(I) 個人または組織体によって所有されている情報(もしくは他の属性)を言い、その利用は、当該主体によって制限されている。
 
$ protected checksum (保護されたチェックサム)
(I) 「データオブジェクトに対して行われた変更に合うように、そのチェックサムを変更することを試みる積極的な攻撃」に対抗して防護する手段によって、データオブジェクトについて計算されるチェックサム。
digital signature, keyed hash, checksum (における検討)参照。)
 
$ protected distribution system (保護された配布システム)
(I) (平文)データの暗号化されていない転送のための利用を許容するようにする十分な(音響的、電子的、電磁的および物理的)対策を含む回線もしくは光ファイバーシステム。
 
$ protection authority (保護機関)
Internet Protocol Security Option (における 2番目の定義)参照。
 
$ protection ring (保護リング)
(I) システムについての階層的な特権オペレーションモードのひとつ。これは、そのモードで動作することが認可されているプロセスに特定のアクセス権限を与える。
 
$ protocol (プロトコル)
(I) システム間における何らかの協定(例: 通信)を実装し、管理する一式のルール(すなわち、フォーマットおよび手順)。
(例: Internet Protocol 参照。)

(C) 特に、複数のシステム主体によって、共同の目標を達成するために行われる情報処理と通信を含む一連の指示された段階。[A9042]
 
$ protocol suite (プロトコルスィート)
(I) コンピュータネットワーク中で使われる相補的な通信プロトコルの集合。
Internet, OSI 参照。)
 
$ proxy server (プロキシサーバー)
(I) クライアント/サーバー型コンピュータシステムにおいて、クライアントにはサーバーとして見え、かつ、サーバーにはクライアントとして見えることによって、プロトコルを中継するコンピュータプロセス(しばしば、ファイアウォールとして、あるいはファイアウォールの一部として使われる)。
SOCKS 参照。)

(C) ファイアウォールにおいて、プロキシサーバーは、通常、要塞化されたホスト上で動作し、これは、いくつかのプロトコル(例: FTP, HTTP, TELNET)のためのプロキシをサポートする可能性がある。防護されたネットワーク中のクライアントが外部サーバーに直接接続する代わりに、内部のクライアントは、外部サーバーに接続する代わりにプロキシサーバーに接続する。プロキシサーバーは、ファイアウォールの内側からのリクエストを待ち、ファイアウォール外部の当該遠隔のサーバーにリクエストを転送し、レスポンスを得たとき、クライアント宛にレスポンスを送り返す。プロキシは、クライアントに対して透過的である可能性もあれば、最初にプロキシサーバーに接続して、次に、本当のサーバーに対する接続を開始するためにも、その協定を使う必要がある可能性がある。

(C) プロキシは、一般に、そのキャッシング、高度なログ記録およびアクセス制御を行う能力について、SOCKS より選好される。プロキシは、クライアントのピア主体認証に基づくアクセス制御や、クライアントがその能力をもたないときのサーバーのピア主体認証のように、通常、関連プロトコルの一部として提供されるセキュリティサービスを越えたものを提供できる。OSI 第 7 層におけるプロキシは、OSI 第 3 層においてフィルタリングルーターができることよりきめ細かなセキュリティ サービスを提供できる。例えば、FTP プロキシは、防護されたネットワークから出方向の転送を許可する一方で、入り方向のものを棄却できる。
 
$ pseudo-random (擬似乱数)
(I) 乱雑(すなわち、予測困難)にみえる一連の値であるが、実際には決定論的なアルゴリズムによって生成されるもの。
random 参照。)
 
$ pseudo-random number generator (擬似乱数生成器)
(I) 一定の統計的なテストをすれば、一見、乱数に見えるが、実際には擬似乱数である一連の数(通常は数値)を決定論的に生成するために利用される処理。

(C) 擬似乱数生成器は、通常、ソフトウェアとして実装される。
 
$ public component (公開コンポーネント/公開鍵)
(I) 「公開鍵(public key)」の同義語。

(D) 大部分の場合、インターネット標準文書は、この用語を使ってはいけない(SHOULD NOT)。; 読者を混乱させることを避けるために、代わりに「プライベート鍵(private key)」を使う。 しかし、この用語は、具体的に、鍵ペアについて検討するときに使うことができる(MAY)。; 例: 「鍵ペアは、公開コンポーネントとプライベートコンポーネントをもつ。」
 
$ public key (公開鍵)
(I) 公開鍵暗号技術について使われる暗号技術的な鍵のペアのうち、公衆に開示可能なコンポーネントの方。
key pair, private key 参照。)

(O) 「(公開鍵暗号システムにおいて)ユーザの鍵ペアのうち、公知の鍵。」 [X509]
 
$ public-key certificate (公開鍵証明書)
(I) システム主体の身元を公開鍵の値に結合し、追加的なデータ項目にも結合する可能性があるデジタル証明書。; 公開鍵の所有を証明するデジタル的に署名されたデータ構造体。
X.509 public-key certificate 参照。)

(C) 公開鍵証明書上のデジタル署名は、偽装不能である。それゆえ、その証明書は、ディレクトリに収めることによって、(ディレクトリが証明書のデータインテグリティを保護する必要なく)公開できる。

(O) 「ユーザの公開鍵は、何らかの他の情報とともに、しれを発行した認証機関のプライベート鍵で署名することによって偽装不能なものとして与えられる。」[X509]
 
$ public-key cryptography (公開鍵暗号技術)
(I) "asymmetric cryptography"について普及している同義語。
 
$ Public-Key Cryptography Standards (PKCS)
(I) 公開鍵暗号技術の基本的な応用のために、データ構造およびアルゴリズム用法について、RSA Laboratories によって発行された一連の仕様。
PKCS #7, PKCS #10, PKCS #11 参照。)

(C) PKCS は、1991年に始まった。産学協働によるもの。当初、Apple, Digital, Lotus, Microsoft, Northern Telecom, Sun, MIT が含まれていた。今日、この仕様は広く使われているが、ANSI, ITU-T, IETF のような公式の標準化団体によって承認されていない。RSA Laboratories は、PKCS に関して唯一の意思決定機関としての立場を維持している。
 
$ public-key forward secrecy (PFS)
(I) 公開鍵暗号技術に基づく鍵共有プロトコルについて、「セッション鍵が長期の公開鍵とプライベート鍵のセットから引き出されること」を確保する属性は、将来、一方のプライベート鍵が侵された場合でも侵されない。

(C) 既存の RFC には、"perfect forward secrecy" という用語を使っているものがあるが、それを定義しているものも無ければ、詳細に規定しているものも無い。この小辞典を準備する過程において、我々は、この用語について良い定義を見つけることを試みたが、これは錯綜した領域であることを発見した。達人たちは、合意しなかった。すべての実践的な目的のためには、その文献は、Diffie-Hellman アルゴリズムについて述べることによって "perfect forward secrecy" を定義している。(Hilarie Orman によって示唆された)"public-key forward secrecy" という用語、および、ここでそれについて述べている (I) の定義は、現行のインターネット文書と整合するように書かれているが、まだ、狭く、用語法について改善の余地がある。

(C) インターネットセキュリティコミュニティの挑戦。:
我々は、インターネット標準において使われる暗号技術的アルゴリズムやプロトコル全般についての分類法(ここで検討される基本的な属性を扱うことができるように、切り分けられた網羅的な用語と定義の類)を必要とする。:

(C) 「セッション鍵」対「長期鍵」について:
達人たちは、次の事項について合意しなかった。
(C) "forward" 対 "backward":
達人たちは、"forward" という単語について満足しなかった。なぜなら、「この」暗号化鍵の侵害は、"forward" ではない "backward" である 「以前の」鍵を侵害することも想定していないからである。S/KEY において、t 時点において使われていた鍵が侵された場合、それ以前において使われていたすべての鍵が侵されている。「長期」鍵(すなわち、ハッシュ化スキームの基礎)が確かなものでなくされた場合、過去・未来のすべての鍵は、侵されている。; それゆえ、「S/KEY には "forward secrecy" も "backward secrecy" も無い」といえる。
 
(C) 「公開鍵暗号技術」対「共通鍵暗号技術」:
達人たちは、共通鍵暗号技術的システムの文脈において、"forward secrecy" について合意しなかった。公開鍵暗号技術が無いとき、あらゆる長期鍵の侵害は、当該長期鍵から得られるいかなるセッション鍵をも侵害してしまう。例えば、Kerberos は、「forward secret」ではない。なぜなら、クライアントのパスワードを侵害すること(それゆえ、クライアントとその認証サーバーによって共有されている鍵を侵害すること)は、クライアントとチケット交付サーバーによって共有された将来のセッション鍵を侵害するからである。

(C) 「通常の "forward secrecy"」対「『完璧な(perfect)」"forward secrecy"」:
達人たちは、これら 2つの間の相違について合意しなかった。相違はないという者もいたし、「最初の命名が不幸であった」として「完璧(perfect)」という単語を落とすことを示唆する者もいた。長期プライベート鍵のひとつが侵された場合に "forward secrecy" を使い、プライベート鍵 の両方(もしくは、当該プロトコルが複数主体向けのものであるとき、すべてのプライベート鍵)が侵されたとき、"perfect" を付加することを示唆する者もいる。

(C) 謝辞:
Bill Burr, Burt Kaliski, Steve Kent, Paul Van Oorschot, Michael Wiener そして、特に、Hilarie Orman は、この検討におけるアイディアに貢献してくれた。
 
$ public-key infrastructure (PKI) (公開鍵インフラストラクチャ)
(I) 公開鍵暗号技術のアプリケーションについてのユーザのコミュニティのために、何らかの証明書管理、アーカイブ管理、鍵管理およびトークン管理機能を行う認証局(および、オプションとして登録局および他の支援的なサーバーやエージェント)のシステム。
hierarchical PKI, mesh PKI, security management infrastructure, trust-file PKI 参照。)

(O) PKIX における用法:
一式のハードウェア、ソフトウェア、人間、ポリシー、および手順であり、公開鍵暗号技術に基づくデジタル証明書を作成・管理・蓄積・配布・失効するために必要とされる。
 
(C) PKI の核となる機能は、次のとおり。
(a) ユーザを登録し、その公開鍵証明書を発行する。
(b) 要求されたとき、証明書を失効する。
(c) 後日、証明書の十分性を検証する。
必要とされるデータをアーカイブする。データの守秘性のための鍵ペアは、CA もしくは RA によって生成(および、おそらく寄託)される可能性があるが、PKI クライアントに自身のデジタル署名鍵ペアを生成することを要求することは、暗号技術的システムのシステムインテグリティを維持管理するのに有用である。なぜなら、このようにすれば、当該クライアントのみが、常に自身が使うプライベート鍵を所持するからである。また、PKI のコンポーネントが運用する際に準拠するセキュリティポリシーである CPS を承認し、調整するために、機関が設立される可能性がある。

(C) 数多くの他のサーバーやエージェントがコア PKI をサポートし、PKI クライアントがそれらからサービスを得る可能性がある。このようなサービスの全体像は、まだ完全には理解されておらず、進化しつつあるが、サポートする役割は、アーカイブエージェント、認定された配布エージェント、確認(confirmation)エージェント、デジタル公証人、ディレクトリ、鍵寄託エージェント、鍵生成エージェント、発行者やサブジェクトが PKI において一意の識別子をもつことを確保する命名エージェント、リポジトリ、チケット交付エージェントおよび タイムスタンプエージェントを含む可能性がある。
 

O<- 3 ->R