Identification・Authenticity・Authentication・真正性

「弁護士ドットコム」さんで、14日に「社会のデジタル化と法律実務」というのを話すので、スライドを作りながら、いろいろと考えていたところ、特に、トラストまわりでも使う真正性・Identification・Authenticity・Authenticationあたりの用語が、混乱しかけているので、自分のためにメモしようかと思っています。

まずは、上の図の左側。アナログ的な行為ですね。紙があって、思想主体たる本人が、その紙に記載されている文書を自己の思想であると「認証」して、その「名義」でもって、署名(または、押印)します。そして、その紙が、そのまま、裁判所の前に呈示されるわけで、単純明快(?)。

右側のデジタル社会になると、いろいろいな話がでてきます。会社の場合をさて置いても、思想主体って、誰なんでしょうか。そのあと作成されるドキュメントの名義人なのでしょうか。それともプログラムの作動者か。

次にドキュメントの受領者からみたとき、そのドキュメントが、誰からのデータであるか、というのを確認する行為というのは、どういう意味をもつのでしょうか。ドキュメントが、誰の思想であるかを識別(identificate)した上で、その表示された思想が、正確に作成された上に、受領にいたるまでに同一であるということが明らかになるということなのかなと思います。

この場合、思想が誰のものかというのを確認するには、識別子を提供してもらって((identification)確認することになるのでしょう。その作成のチェーンをみていった上で、正確に作成されて、同一であることが認証される(Authentication)ものとなるのでしょう。この場合に、この確認する行為やルールが認証(Authorisation)ですね。

(なお、identificationについては、こちらのブログが勉強になりました)

法的に真正性(Authenticity)と呼ばれているものをみていきましょう。

我が国でいけば、民事訴訟法第228条1項

文書は、その成立が真正であることを証明しなければならない。

とされています。そして、228条4項においては、

私文書は、本人又はその代理人の署名又は押印があるときは、真正に成立したものと推定する。

とされています。

米国であれば、連邦証拠規則901条(a)です。同条は、

 証拠のアイテムを認証(authenticating)し、または、識別する(identifying)要件を満たすには、提案者(proponent)は、問題となっている(コンピュータ記録あるいはその他の証拠)がその申請者が要求しているものであるということを認定することを基礎づけるのに十分な証拠を示さなければならない。

と定めています。これについて、司法省の捜索差押ガイドラインは、真正性という名称で呼んでいます。

この真正性について、同ガイドラインは、3つの問題があることを分析しています

第1に、当事者は、当該記録が作成されたのちに改変され、操作されあるいは毀損されたどうかを問題とすることによって、コンピュータの生成した記録とコンピュータに蔵置された記録の両方の真正性について異議を申し立てることができる。

第2に、当事者は、当該記録を生成したコンピュータプログラムの信頼性を問題にすることによって、コンピュータの生成した記録の真正性を問題にすることができる。

第3に、当事者は、その作成者の同一性を問題にすることによって、コンピュータに蔵置された記録の真正性に異議を申し立てることができる。

これらをひとつの図にあわせることができるか、ということになります。

これは、上のガイドラインの3つの段階があること、それについて、法的に、真正性を明らかにすること(認証-authentication)がいろいろな証明を助ける仕組みを準備していることを示しています。

あと、ここの関係で把握しておくべき概念は、eIDASに関していわれているセキュリティ性質としてのデータのオリジンの認証でしょうか。「秘密鍵の保有者のみが、対応する公開鍵でサインされたデータのオリジンのポイントとなりうるから、サインされたデータのオリジンの証明となる。」という表現になっていて、この作用が、データのオリジン認証(authentication)といわれています(例えば、Security guidelines on the appropriate use of qualified electronic signaturesなどの表現 例 3.2Security properties )

ということで、メモを作っても、なかなか整理されないのですが、

(1)真正性という用語は、成立に関する部分と、内容に関する部分とをともにいっている。

(2)成立に関する部分は、連邦証拠規則だと、識別といわれているようである。

(3)真正性を明らかにする行為が認証と呼ばれている。

あたりをメモしておくことにします

 

 

トラストワークショップ参加ありがとうございます。

トラストサービスの調査ワークショップ無事成功のうちに終了いたしました。

参加いただきましたみなさま本当にありがとうございます。

トラストサービスWGの開催が、新聞報道等でなされるなか、非常にタイムリーな企画となり、熱心な議論がなされたのは、非常に有意義であったかと思います。

トラストサービスWGの報道としては、

日経新聞「電子書類に公的認証-改ざん防ぎ信用担保 国際商取引を円滑化」

読売新聞「電子書類に公的認証・・・総務省会議」

ブログとしては、「”総務省が画策する「日本版eIDAS」は電子契約普及の追い風となるか」ですね

当社としても、3月末にむけての報告書完成にむけてさらに努力する所存です。

 

「通信の秘密」にコメントする前に気をつけたいこと

昨年来、なにかあると「通信の秘密」という言葉に関連して、報道されることが多くなってきました。

例えば、

(1)ISPによるブロッキングが、憲法の「通信の秘密」の規定に違反するおそれ

(2)NHKによる「総務省 IoT機器に無差別侵入し調査へ 前例ない調査に懸念も 」報道 (どうも、NHKの報道は消えていますね)

(3)捜査当局が、スマホからのデータ抽出は、「電話やメールの内容は憲法が定める「通信の秘密」に当たる。」

とかです。

個人的には、これらが、法的にきちんとした分析に基づいて「通信の秘密」という用語を用いてるのかなという疑念をもっています。

この点で、注意すべきことは、憲法における「通信の秘密」と電気通信事業法における「通信の秘密」が法律の概念としては、あって、それぞれの関係が不明であること、しかしながら、憲法の教科書では、ほとんど、同一であるとされる記述が一般であることです。

この点については、明確な検討がなされていないどいうことがいえるわけです。ただし、憲法の教科書の一般的なアプローチからは、憲法の通信の秘密も、(電気通信事業法と同じで)国内の遠隔通信に関して、電気通信事業者の取扱中にかかる通信に関する秘密を念頭において議論されているということになります。
(有線通信や無線通信はちょっとおきます)

ここで、電気通信事業者の取扱中というのは、「発信者が通信の発した時点から受信者がその通信を受けるまでの間をいい、電気通信事業者の管理支配下にある状態のものをさします」( 電気通信振興会 逐条解説 35ページ)。

例えば、スマホでいえば、そのスマホ内に物理的に保存されているデータは、利用者の管理支配下にあることになります。(利用者の宅内にある自営端末(略)は、「電気通信事業者の取扱中」とはなりえない)ちなみに、この物理的にどこで支配が変わるのか、というのが、責任分界点ですね。

なので、少なくても一般的な電気通信事業法の概念からいくと、例えば、改正NICT法での調査が、「通信の秘密」に違反するおそれとかいわれると?とおもうわけです。
(そもそも、根拠規定で、違法性が阻却されているだろうというのは、さておいてですが)

さらに、この話は、いま一つ、突っ込みがあるわけです。実は、逐条解説をみると、「蓄積機能を有する自営端末において、すでに蓄積された情報を事後に検閲する場合(略)などは、(電気通信事業法3条、4条-高橋の補充です 原文は3条)禁止している行為ではないものの、憲法21条2項および有線電気通信法9条違反に該当する行為となりうる」(35ページ)と記載されています。

なので、そのレベルで、解釈論をなしているのであれば、(2)および(3)は、嘘とはいえないということになります。もっとも、(2)および(3)ともに法的な根拠があってなしている行為なので、そもそも違法とは考えられないという根本的な問題をなぜに無視するのか、という当たり前の問題が残ることになります。

NICT法によるアクセスの総務省令による基準

ここ数日の報道の関係で、去年の7月に書いた「NICT法改正と不正アクセス禁止法」という記事が、ある程度、アクセスいただいているようです。

その段階では、はっきりしてしないかったことがらに具体的なアクセスの基準があるわけです。この点については、昨年に、省令がでていてはっきりしますので、その点をメモしておきたいと思います。(というか、省令がなかなかひっかからないので、その所在のメモです)

省令の名称は、「国立研究開発法人情報通信研究機構法(平成十一年法律第百六十二号)附則第八条第四項第一号及びび第九条の規定に基づき、国立研究開発法人情報通信研究機構法附則第八条第四項第一号に規定する総務省令で定める基準及び第九条に規定する業務の実施に関する計画に関する省令」(総務省令61号)(平成30年11月1日)です。

概要は、こちら

省令本体は、こちらです。

1条は、(識別符号の基準)
一 字数八以上であること。
二 これまで送信型対電気通信設備サイバー攻撃のために用いられたもの、同一の文字のみ又は連続した文字のみを用いたものその他の容易に推測されるもの以外のものであること。

2条は実施計画
2項は、「機構が作成する実施計画には、次に掲げる事項を記載しなければならない。」として、業務従事者の氏名・所属部署・連絡先(1号)、IPアドレスその他設備に関する事項(2号)、識別符号の方針及び当該方針に基づき入力する識別符号(3号)、対象のIPアドレス等(4号)、ログ等のセキュリティ管理措置その他(5号)、その他
です。

とりあえず解説のメモもでているようです。

ちなみに、通信の端末に保存されているデータから、通信先がわかったとしても、それは、「電気通信事業者の取扱中にかかる通信」とはいえない(例によって宅内ね)ので、通信の秘密というのは、ミスリーディングのような気がするんですけどね。

 

トラストサービスの調査ワークショップ 2019のプログラム

トラストサービスの調査ワークショップ 2019が、変更になりました。

変更後のプログラムは、こちらです。

13:30  開会
13:30~13:35 総務省挨拶 (調整中)
13:35~14:00 eIDASの現状
駒澤綜合法律事務所 辯護士/株式会社ITリサーチ・アート 代表取締役 高橋 郁夫
14:00~14:25 欧州の法規制
ポリシー・リサーチ・ユニット(総務省情報通信政策研究所特別研究員) 佐々木 勉
14:25~14:50 EUの技術標準
セコム株式会社 IS研究所 コミュニケーションプラットフォームディビジョン マネージャー 松本 泰
14:50~15:00 休憩
15:00~15:25 トラストサービス推進フォーラムの取組
セイコーソリューションズ株式会社 DXソリューション統括部 部長 柴田 孝一
15:25~15:50 日・EUのトラストサービスに関する制度比較
セコムトラストシステムズ株式会社 プロフェッショナルサポート1部 担当部長 西山 晃
15:50~16:00 休憩
16:00~17:00 パネルディスカッション
高橋 佐々木 松本 柴田 西山
17:00 閉会
です

トラストサービス推進フォーラムの活動の紹介等もさせていただき、さらに、多角的な観点から、我が国における今後のトラストサービスのあり方を考える機会にいたしたいと思います。

皆様 よろしくお願いします。

トラストサービスフォーラムinベルリン Day2 その3

最後のセッションです。

最初は、Dimitris Zacharopoulosさんの「CA/ブラウザフォーラム(CA/Browser Forum-Status and future activities)です。スライドはこちら

CA/ブラウザフォーラムというのは、規制団体ではなく、また、監督機関でもありません。むしろ、世界的な「標準機関」に近いものといえるでしょう。SSL/TLS証明書の提供/発行/ガバナンスについての相互のポリシ、実務をともに定めています

ブラウザは、トラストサービスプロバイダを「ルートプログラム」を通じて、そのssl/TLSトラストサービスを「監督」しています。
フォーラムは、ガバナンスの変更によって、フォーラムがサーバー証明書ワーキンググループとなりました。また、サブコミッティ、証明書発行者、証明書利用者へと名称の変更がありました。

また、他の話題としては、監査が、ETSIの標準とWebTrustの基準が、収斂しつつあります。

効果的な監督というのも重要な問題です。現在は、適合性評価機関となっています。が、誤った証明書は、適合性評価機関によって発見されるものではないのです。監督機関は、スキームをテストするにすぎないのです。
その意味で、関係当事者は、証明書「製品」によって十分に保護されているのか、トラストをおいているのか、という問題があるのです。
また、現状でのSSL/TLSが、十分なのか、監査報告書での不適合部分が小規模とされること、適格タイムスタンプは、RFC3161のタイムスタンプではないこと、などの問題があるとされています。

次は、Andreas Philippさんの「ハイブリッドPKI/IoTのソリューション」(Hybrid PKI: Solution for IoT)です。スライドは、こちら

IoTセキュリティの重要性は増しており、また、PKIは、IoTにおいても事実上の標準になっているとされます。
IoTは、多様性を有しており、フリーサイズの解決策は存在しないこと、そこで、PKIに注目することになります。同社の対応としては、世界的な配置、負荷のピーク、OTについてのPKIソリューションなどがあります。
工場での動作を考えてみましょう。
イメージのスライドは、こんな感じです(スライド14から)

クライアントのオンサイトでの処理があり、工場での処理もされ、それも認証局、登録局、サーバーのアプライアンスが発展することになります。工場ともなれば、誤作動の場合の安全性の問題は到底看過できません。
まさに、PKIも組み合わせたハイブリッドで、動かしてみましょうということになるのかと思います。

最後は、Andrea Valleさんの「アドビとクラウド署名コンソーシアム」(Adobe and the Cloud Signature Consortium)です。スライドは、こちら

クラウド署名コンソーシアムは、クラウド署名についての標準を構築しようというものです。

2016年に設立され、クラウドベースの電子信託サービスの促進、相互作用を容易にするために共通のアーキテクチャーとビルディングブロックを設計する、これらのやり取りを容易かつ相互運用可能にするためのプロトコルおよびAPIの技術仕様を作成、技術仕様をオープンスタンダードとして公開する、などのミッションを有しています。 (このようなプレスリリースもあります)
トラストサービスのための基準の開発のための貢献の相互交換を可能にするためにETSIとの協力協定を確立しており、具体的には、CSC API仕様は、ETSI TS 119 432「リモートデジタル署名作成のためのプロトコル」で参照されています。
また、CSC API V1仕様は、一般に公開されています。http://cloudsignatureconsortium.org/specifications

あとは、CSC技術仕様の簡単な説明、ロードマップ、アドビ署名がCSC の仕様に準拠していることなどの説明がありました。そのあと、実際のデモ、アドビ署名のロードマップについての説明もなされました。

トラストサービスフォーラムinベルリン Day2 その2 後半

第2セッションですが、一番興味深かったOlivier Delos ( Sealed)さんの「トラストリスト:何?-現在の状況、イニシアチブ、次のステップと課題」(Trusted Lists:
What’s up? Current situation & initiatives Next steps and challenges )です

eIDAS規則は、ピラミットをなしています。

この図は、適格トラストサービスに関して、EUトラストマークを頂点に、トラストマーク、監督体制、適格トラストサービスプロバイダ、適格トラストサービスに関する規定、それらを支えるベストプラクティス、標準がピラミッド構造をなしているのを物語っています。

トラストマークを直接にささえているのは、トラストリストです。

トラストリストは、適格トラストサービス(提供者)に対して、基本的な効果を有しています。
トラストリストの手続と様式は、共同体 実装決定(CID)2015/1505によって特定されています。この実装決定は、サービス指令によって、設立されたトラストリストとの継続性を確保し、適格事業者の法的確実性をたしかにするものです。また、適格電子署名・適格電子シールの有効性確認をすることで、クロスボーダーの認証を促進しようとするものです。

トラストリストは、加盟国が自動処理に適するようになさなければならない/適格事業者の情報を含まなければならない(強制的)、可読的な形で提供する/適格ではない事業者の情報を含むことができる(任意的)という双方の性格を有します。

上記実装決定(CID)2015/1505は、ETSIのTS 119 612 v2.1.1に基づいています。構成としては、トラストリストスキームおよび運営者、EC LOTL(トラストリストのリスト)へのリンク、適格事業者・適格事業のリストから成り立っています。

共同体トラストリストのリストは、加盟国のトラストリストの情報を含んだXMLのファイルであって署名/シールがされています。詳細な情報は、EUの公式がジャーナルで公表されています。ピボットリストのリストがあり、機械可読な証明の変更であって、その特別なインスタンスということになります。

また、EUトラストマークは、クリックすることによって、トラストリストをみる(Trusted List Browser)ことができます。
TLSO(Trusted List Scheme Operator)コミュニティがあります。そこでは、トラストリスト管理ツール、同ブラウサ、加盟国からの通知、サービスデスクなどが提供されています。

これをみることで、各国においてどのような適格トラストプロバイダーが、どう登録されているかがわかります。登録されている数をみてみると以下のようになります。

適格事業者数は、以下のとおり。

適格電子署名認証事業者

適格電子シール認証事業者

適格ウエブサイト認証事業者

事業者数

143

83

35

国数

27

22国

16国

増減事業者

-8

81

35

国数

-2

20

16

 

適格電子署名検証事業者

適格電子シール検証事業者

事業者数

9

9

国数

8

8

増減事業者

7

7

国数

6

6

 

適格タイムスタンプ事業者

適格電子配達内容証明事業者

事業者数

85

5

国数

21

4

増減事業者

63

3

国数

14

3

 なお、増減といっているのは、eIDAS実施6月後の時点での事業者数との相違の数です。

EUの範囲を越えて、相互認証をなすということが問題になります(eIDAS規則14条)。

この点では、法・監督・技術の三つの柱の観点から、マッピングを実現していかなければなりません。

ENISAでは、「監査の世界的承認」という文書を提供しています (という話ですが、見つかりませんでした)。
ETSIのSTF560(ESI 560 Standards for machine-processable signature policy formats and the global acceptance of European Trust Services)も参照する必要があります。
次のチャレンジとしては、意識と教育で、卓越を目指して、道を舗装していくことになります。

Dean Coclin ( Digicert)は、「SSLの産業傾向」です。スライドは、こちら

プレゼンは、いろいろいな交通標識の話で始まります。これに比較して、SSLのグリーンやグレイのサインは、わかりやすいでしょうか。

お札は、また、すかしがはいっています。EV証明書のセキュリティも同様です。

EV証明書は、偽造防止であり、適格ウエブサイト証明書は、EVに頼っています。アイデンティティが重要であれば、何が、EVを改善するのでしょうか。

また、ブラウザの設定によりhttpsへの移行が劇的な増加をみせています。(クロームだと78%以上、アンドロイドでも68%以上です) Chrome69からは、安全の文字がなくなっています。

アップルのsafariの表示も変わってきていますし、また、EVの市場も増加しています。

証明書のタイプでいうと、DV(ドメイン証明書)が94.3%、OV(企業証明書)が、5%、EVは、0.7%です。しかしながら、トラフィックだと状況が変わります。きわめて印象的です。

ちなみに3種については、こちらをどうぞ。

 

 

 

 

トラストサービスフォーラムinベルリン Day2 その2 前半

Day2の2コマ目のセッションです。

最初は、Michael Taborさんの「PSD2は、eIDAS適格証明書を金融サービスに導入する」(PSD2 introduces eIDAS qualified certificates to financial services)というプレゼンです。スライドは、こちら

決済サービス指令2は、このフォーラムのメモでも度々出てきています(Day1 その1、Day2 その1後半)。委任規則も、Day2のその1後半でふれました。

アカウント情報サービス(定義は、指令4条(16))が提供されると、本人は、一回の登録だけで、あとは、各金融機関に本人の情報が安全に提供されることになって、このように変わっていくということがポイントになります。まさに、eKYC(電子的「顧客確認」)が実現するのです。 (KYCについては、「フィンテックで進むか、 本人確認(KYC)のイノベーション」のリンクを張っておきます)

また、決済開始サービスプロバイダ(PISP)という概念が準備されています。この概念は、他の決済サービスプロバイダにおいて保有されている決済に関するサービスの利用者の求めに応じて、決済命令を開始するサービスを行うものです(同(15)。これが実現すると

のような図になっていきます。

決済サービス指令2のもとにおいては、技術標準119 495において、「電子署名基盤;部門要件;決済サービス指令(2015/2366 EU)における適格証明書プロファイルおよびタイムスタンプポリシ要件」が定められています。

この標準においては、5が、証明書プロファイル要件で、6が ポリシ要件になります。

附属文書Aが、ASN.1 宣言で、Bが、決済サービス指令2を満たす証明書とは、どういうものかということについての解説です。

これらの証明書については、決済開始サービスとアカウント情報サービスが、利用を義務づけられており、銀行におけるアカウントサービスにおいては、利用が強く推奨されています。

決済サービスプロバイダは、その本人性/インテグリティ確認のために、適格電子シールと適格ウエブサイト証明書を利用することになります。

委任規則34条は、各プロバイダの登録番号等の記載とその役割、監督機関の名称が証明書に記載されなければならないことを定めています。

Nick Pope ( Security & Standards Associates)「オープンバンキングにおける適格証明書において呈示された問題点」 ( Open Issues on Use of eIDAS Qualified Certificates in Open Banking)です。

スライドは、一般公開されていません。なので、要点のみをまとめることにします。

要は、適格証明書に関して、PSD2証明書プロバイダーとはどういうことか、証明書を信じることとは、どういうことか、責任とはどういうことか、などの問題が提起されているということだそうです。

とりあえずは、ホームページへのリンクを張っておきましょう。

 

トラストサービスフォーラムinベルリン Day2 その1 後半

次は、「PKIは、どのくらい使われるか(How much PKI is in:PSD2; eIDAS; GDPR)」というArno Fiedler( Nimbus)さんの話です。欧州の規範を利用してeIDASを実装するという趣旨での話です。スライドは、こちらです。

欧州は、現在、デジタル単一市場を目指しており、決済については、SEPA(単一決済エリア)が目指されていることになります。
ここで、特に、決済サービス指令2(PSD2)のための技術的標準をみることになります。
ちなみに、決済サービス指令2の 本文はこちら)で、についての簡単な説明についてはこちらです。

関連する規定としては、

第29条トレーサビリティ

決済サービス提供者は、決済サービスユーザー、他の決済サービスプロバイダー、および商人を含む他の企業の間で確立された通信セッションが、タイムスタンプなどに依拠するように、確かにしなければならない

第34条 証明書

識別のために、(略) 支払いサービス提供者は、規則(EU)No 910/2014の第3条(30)に記載されているような電子シールのための、または第3条(39)第35条に記載されているようなウェブサイトの認証のための認定証明書に依拠しなければならない。

通信セッションのセキュリティ

1 ./ インターネットによるデータ交換に際して、データの機密性および完全性を保護するために、強力で広く認識されている暗号化技術を使用して、各通信セッションを通して通信相手間で安全な暗号化が適用される

とされています。
また、GDPRにおいては、32条の仮名化、32条の取扱の安全措置が、関連してることになります。
eIDAS要件では、5条(データ取扱および保護)、13条(責任および証明の責任)、15条(ユニバーサルアクセス)、16条(罰則)、19条(セキュリティ要件)がかかわってきます。
最後に、欧州のeIDとがブルーワンダーになるようにということで、プレゼンは、終了です。

次は、Andrea Röck(Universign, ETSI STF 524 expert)さんの「ETSIの電子署名と署名検証サービス」(ETSI ESI and Signature Validation Services)というプレゼンです。スライドは、こちら
基本的な内容は、(1)eIDASにおける標準のアップデート(2)署名検証サービスです。
(1)eIDASにおける標準のアップデート
最初にフレームワークは、こちらです。

アップデートされたものとしては、CA Policy Requirements: EN 319 411-1/2、決済サービス指令2のもとでの適格証明書のアップデート、リモート署名に関して、信頼しうるシステムのためのCEN(欧州標準化委員会)標準(EN規格については、こちらhttps://rnavi.ndl.go.jp/research_guide/entry/theme-honbun-400383.php )、生成のプロトコルとコンポーネント要件、内容配達証明、長期保存、トラストリスト、監査要件の補充、機械による取扱の様式があります。具体的なものは、スライドにあげられています。また、最後に、欧州のトラストサービスについての国際的承認の話がでています。

個人的には、「決済サービス指令2(PSD2) のもとでの適格証明書のアップデート」と「欧州のトラストサービスについての国際的承認」が気になるところです。

PSD2については、委任規則が本人確認等についての細かい点を定めています。

具体的には、「2015/2366(EU)指令における強力な利用者識別および通信の一般かつ安全なオープンな標準に関する委員会委任規則(Commission Delegated Regulation (EU) 2018/389 of 27 November 2017 supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication )」になります。この委任規則の本文は、こちらでみれます。

また、欧州のトラストサービスについての国際的承認」においては、「Study report on Global Acceptance of EU Trust Services」(‘DTR/ESI-000123)があげられています。スケジュールをみることができますが、まだ、早期案の作成中のようです。また、ワークショップがふれられていて、ターゲットとして日本が最初にあがっているのは、興味深いところです。

(2)署名検証
「ETSI STF 524」(特別タスクフォース 524)ですが、これは、2016年に始まり、三つのドキュメントがでています。
TS 119 102-2: Validation Report(https://www.etsi.org/standards-search#search=TS119102-2
TS 119 441: Policy Requirements for TSPs Providing Signature Validation Services(https://www.etsi.org/deliver/etsi_ts/119400_119499/119441/01.01.01_60/ts_119441v010101p.pdf
TS 119 442: Protocol for Signature Validation Services (https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=47246
あと、関連のドキュメントもあります。

Matthias Wiedenhorst (TÜVIT)は、「監査報告の苦闘(The struggleofauditreporting)」です。スライドは、こちら

eIDAS3条(18)による適合性評価機構が、国家評価機構としてなす組織は、実質的に唯一であるということになる。

評価の一般的なマトリックスは、TR 119 000, V1.2.1により、 ETSI EN 319シリーズが、トラストサービスプロバイダの監査についてのひとつの欧州の標準ということになる。
しかしながら、監査報告の枠組みについては、いろいろな枠組みが存在することになります。

まずは、ENISAのトラストサービスの適合性評価ガイドライン(Conformity assessment of Trust Service Providers – Technical guidelines on trust services)。(https://www.enisa.europa.eu/publications/tsp-conformity-assessment

ETSI TS 119 403-2 V1.1.1 (2018-07)(https://www.etsi.org/deliver/etsi_ts/119400_119499/11940302/01.01.01_60/ts_11940302v010101p.pdf
ETSI TS 119 403-3(https://docbox.etsi.org/esi/Open/Latest_Drafts/ESI-0019403-3v007-for-public.pdf

結局、ひとつの様式にするのは、現実的ではないとして、誰が、問題点を解決するのであろうかという問いがなされます。

適合性評価機関委員会(ACAB-c)か、FESA(トラストサービス提供者への監督機関フォーラム)か、または、EUか、ということになります。