利用者のための注釈
651 受信の否認不可は、受信者が情報を受信したことの証拠を他の利用者/サブジェクトに提 供するための要件を定義する。受信の証拠(ディジタル署名など)が、受信者属性とその情 報をつなぐ証拠を提供するため、受信者は、情報を受信したことを否認することができな い。発信者あるいは第三者は、受信の証拠を検証できる。この証拠は、偽造可能であるべ きではない。
652 情報が受信されたという証拠の提供は、必ずしも情報が読まれた、あるいは理解されたこ とを意味せず、単に配信されたことを示すことに注意すべきである。
653 もし情報あるいは関連する属性が何らかの方法で変えられると、元の情報に関する受信 の証拠の確認が失敗するかもしれない。そのため、PP/ST 作成者は、FDP_UIT.1 データ 交換完全性のような完全性に関する要件をPP/STに含めることを考慮すべきである。
654 否認不可ではいくつかの異なる役割が関連しており、各々は1つまたは複数のサブジェク トにおいて組み合わせることができる。最初の役割は、受信の証拠を要求するサブジェク トである(FCO_NRR.1 受信の選択的証明の場合だけ)。2 番目の役割は、受信者及び/ま たは証拠が提供される他のサブジェクト(公証人など)である。3 番目の役割は、受信の証 拠の検証を要求するサブジェクト、例えば、発信者あるいは調停者などの第三者である。
655 PP/ST作成者は、受信の証拠の有効性を検証するのに必要な条件を特定しなければなら
ない。特定される条件の例は、証拠の検証は24時間以内にされねばならない、というもの である。したがって、これらの条件は、証拠の提供を数年間可能にするなど、法的な要件 への否認不可の適応を可能にする。
656 ほとんどの場合、受信者の識別情報が、送信を受信した利用者の識別情報になる。場合 によっては、PP/ST 作成者は、その利用者の識別情報がエクスポートされるのを望まない ことがある。そのような場合、PP/ST 作成者は、このクラスを含めるのが適切かどうか、ある いは伝送サービスプロバイダの識別情報あるいはホストの識別情報が使用されるべきかど うかを考慮しなければならない。
657 利用者識別情報に加えて(あるいはその代わりに)、PP/ST 作成者は、情報が受信された 時間をより重要と考えるかもしれない。例えば、提案が所定の日付で締め切られる場合、
よく検討してもらうためには、発注は所定の日付までに受信されねばならない。そのような 例では、これらの要件は、タイムスタンプ表示(受信の時間)を提供するようカスタマイズす ることができる。
FCO_NRR.1 受信の選択的証明割付
操作 割付:
658 FCO_NRR.1.1において、PP/ST作成者は、受信機能の証拠に、例えば電子メール
メッセージなど、情報サブジェクトの種別を記入すべきである。
選択:
659 FCO_NRR.1.1 において、PP/ST 作成者は、受信の証拠を要求できる利用者/サブ
ジェクトを特定すべきである。
割付:
660 FCO_NRR.1.1 において、PP/ST 作成者は、選択によっては、受信の証拠を要求で
きる第三者を特定すべきである。第三者とは、調停者、裁判官、法的機関などがな り得る。
661 FCO_NRR.1.2 において、PP/ST 作成者は、情報にリンクしなければならない属性、
例えば、受信者識別情報、受信時刻、受信場所などのリストを記入すべきである。
662 FCO_NRR.1.2において、PP/ST作成者は、メッセージ本文など、その属性が受信の
証拠を提供する、情報内の情報フィールドのリストを記入すべきである。
選択:
663 FCO_NRR.1.3 において、PP/ST 作成者は、受信の証拠を検証できる利用者/サブ
ジェクトを特定すべきである。
割付:
664 FCO_NRR.1.3において、PP/ST 作成者は、その証拠を検証できる制限についての
リストを記入すべきである。例えば、証拠は24時間の範囲内でだけ検証されるなど。
「直ちに」や「無制限」を割り付けることは許される。
665 FCO_NRR.1.3 において、PP/ST 作成者は、選択によっては、受信の証拠を検証で
きる第三者を特定すべきである。
FCO_NRR.2 受信の強制的証明
操作 割付:
666 FCO_NRR.2.1において、PP/ST作成者は、受信機能の証拠に、例えば電子メール
メッセージなど、情報サブジェクトの種別を記入すべきである。
667 FCO_NRR.2.2 において、PP/ST 作成者は、情報にリンクしなければならない属性、
例えば、受信者識別情報、受信時刻、受信場所などのリストを記入すべきである。
668 FCO_NRR.2.2において、PP/ST作成者は、メッセージ本文など、その属性が受信の
証拠を提供する、情報内の情報フィールドのリストを記入すべきである。
選択:
669 FCO_NRR.2.3 において、PP/ST 作成者は、受信の証拠を検証できる利用者/サブ
ジェクトを特定すべきである。
割付:
670 FCO_NRR.2.3において、PP/ST 作成者は、その証拠を検証できる制限についての
リストを記入すべきである。例えば、証拠は24時間の範囲内でだけ検証されるなど。
「直ちに」や「無制限」を割り付けることは許される。
671 FCO_NRR.2.3 において、PP/ST 作成者は、選択によっては、受信の証拠を検証で
きる第三者を特定すべきである。第三者とは、調停者、裁判官、法的機関などがな り得る。
附属書E クラス FCS: 暗号サポート (規定)
672 TSF は、いくつかの高レベルのセキュリティ対策方針を満たすのを助けるため、暗号機能
性を採用することができる。これらは次のものである(ただし、限定されない): 識別と認証、
否認不可、高信頼パス、高信頼チャネル、及びデータ分離。このクラスは、TOE が暗号機 能を実装する場合に使用され、その実装は、ハードウェア、ファームウェア、及び/またはソ フトウェアにおいて行われる。
673 FCS: 暗号サポートクラスは、暗号鍵管理(FCS_CKM)と、暗号操作(FCS_COP)の 2 個の ファミリから構成される。暗号鍵管理(FCS_CKM)ファミリは暗号鍵の管理面に対応し、暗 号操作(FCS_COP)ファミリは、それらの暗号鍵の運用上の使用に関連する。
674 TOEで実装する暗号鍵生成方法ごとに、もしあれば、PP/ST作成者はFCS_CKM.1暗号
鍵生成のコンポーネントを選択すべきである。
675 TOEで実装する暗号鍵配付方法ごとに、もしあれば、PP/ST作成者はFCS_CKM.2暗号
鍵配付のコンポーネントを選択すべきである。
676 TOEで実装する暗号鍵アクセス方法ごとに、もしあれば、PP/ST作成者はFCS_CKM.3暗
号鍵アクセスのコンポーネントを選択すべきである。
677 TOEで実装する暗号鍵破棄方法ごとに、もしあれば、PP/ST作成者はFCS_CKM.4暗号
鍵破棄のコンポーネントを選択すべきである。
678 TOE で実行する暗号操作(ディジタル署名、データ暗号化、鍵交換、セキュアハッシュな
ど)ごとに、もしあれば、PP/ST 作成者は FCS_COP.1 暗号操作のコンポーネントを選択す べきである。
679 暗号機能性は、FCO クラス: 通信において特定された対策方針を満たすために、かつ データ認証(FDP_DAU)、蓄積データ完全性(FDP_SDI)、TSF 間利用者データ機密転送 保護(FDP_UCT)、TSF 間利用者データ完全性転送保護(FDP_UIT)、秘密についての仕 様(FIA_SOS)、利用者認証(FIA_UAU)ファミリにおける様々な対策方針を満たすために 使用できる。暗号機能性がそれ以外のクラスに対する対策方針を満たすために使われる 場合は、個々の機能コンポーネントが、暗号機能性が満たさねばならない対策方針を特 定する。FCS: 暗号サポートクラスにおける対策方針は、TOE の暗号機能性が消費者に よって求められるときに使用されるべきである。
680 図23は、このクラスのコンポーネント構成を示す。
図23 FCS: 暗号サポートクラスのコンポーネント構成