電子署名の概念整理(当事者型対クラウド型(リモート署名・立会人型))

「電子署名」がいろいろいなタイプがあって、分かりにくいということなので、自分なりの考えをまとめてみます。

なお、厳密を期するために、公開鍵暗号技術をもちいて、ドキメュントについて真正性とインテグリティを確保する技術をデジタル署名ということにします。

信号が添付されたドキュメントがどこにあるのか、ということで、当事者型とクラウド型に分けることができます。当事者型のイメージは、こちらです。

 

 

 

 

 

 

 

 

デジタル署名の付されたドキュメントが当事者間で交換されて、それぞれ保管されるイメージです。90年代のデジタル署名のふされた契約書のイメージというとこんな感じだったような気がします。

しかしながら、いろいろなサービスが、クラウドで提供されるようになります。

このクラウドで提供されるサービスには、二つの型があります。

一つはリモート署名です。

 

 

 

 

 

 

 

 

これは、当事者A、当事者Bともに

(1)社会的に外形上表示されるA、Bと、社会通念上、同一であると識別される法的実体に対して付されるデジタル署名の権限を用いて、

(2)クラウド上のプラットフォームで、それぞれ意思表示がなされる形です。

(1)は、その法的実体が、Aであることは、認証局が、一定の基準に基づいて確認しますし、また、当事者Aのみが、クラウド上に、デジタル署名をなしうるような技術的基準に遵守した運用にもとづいてデジタル署名がなされます。

これによって、上記のドキュメントの真正性とインテグリティが確保されます。

Aさん、Bさんの腕が伸びて雲のなかで、署名をしているイメージです。

これに対して、立会人型という仕組みは、

 

 

 

 

 

 

 

 

このような図で示されます。当事者Aは、このサービスの求める事項の登録によってアカウントを作成します。電子メールアドレス(A@kaisyaA.com) kマシーンから、当事者Bの従業員とされる電子メールアドレス (B@kaisyB.com)宛に、アカウントの利用に関する連絡がいきます。

操作者がそれぞれの当事者の枠から、すこし離れているのは、そのメールアドレスの人が操作をなしたことからしか真正性が判断されないので、その人の権限やそのアドレスが、その会社に属することが保証されていないことを物語っています。

お互いのマシーンの操作者は、プラットフォーム上で、合意のドキュメントを成立させます。するとこのドキュメントに立会人が電子署名をなすので、この成立したドキュメントがその後改ざん・変更されないことについては、この立会人の電子署名の効力で明らかにすることができます。

上のリモート署名のスタイルと比較した場合に、操作者Aが、当事者Aに効果を帰属させることができるか、というのは、この仕組みでは、「技術的に」担保されてないことになります。

これが「技術的に」担保されていないからといって、この合意のドキュメントが証拠として無価値かというとそのようなことは一切ありません。

「リモート署名は電子署名である&クラウド型電子契約にお墨付き」 で触れたように、

電子署名法第三条の推定効が働かない場合であっても、個別の事情に照らして電磁的記 録の真正な成立を裁判所が認定することは可能である。

ということになります。リアルワールドで、すべての契約に印鑑証明書を添付するわけではないです。リアルワールドの裁判において、印鑑証明書が付されていない契約書だから、効力がありませんとは誰もいわないです。それと同じです。

直接、訪問して、知っている人が、その流れのなかで、きちんとドュキメントに応じた対応を取っていれば、そのドキュメントに署名したのが操作者A、Bであって、しかも、それそれれの会社を代表する権限を有していることは、いうまでもないということがいえるでしょう。

その限りでリスク評価をしているのです。それと同じです。継続的な関係のなかで、契約を締結するのであれば、上のようなリモート署名型までのサービスを利用するまでもないというのは、健全なリスク評価だと思います。

 

 

日経のハンコに関する社説は、一次情報にあたる必要がある

日経新聞で、「IT企業発の脱ハンコの波を全産業に」という記事が社説として出ています

この最後には、

政府や国会は企業の取り組みを後押しするために、使い勝手が悪いとされる電子署名法の改正など法制面の整備も進めてほしい。

という意見があります。この記事は、ITリサーチ・アートのエントでふれた「「クラウド上の契約に法的リスク」という記事(エントリはこちら)をもとにするものかと思いますが、この記事自体が、規制改革推進会議の一次情報にあたっていないお粗末なものでした。

もし、本当に、「規制改革推進会議」の資料をあたっていれば、政府は、脱ハンコのために法的な障害は存在しないということを明確に認めているのだということがわかるはずです。この部分は、私は、「リモート署名は電子署名である&クラウド型電子契約にお墨付き」で書きました。

むしろ、規制改革推進会議での省庁の回答の内容を正確に、そして、(確かに専門的な分かりにくいところがあるのは認めるので)分かりやすく、経済人に伝えるこそが、日経新聞のミッションだろうと思います。

私のエントリや規制改革会議での各省庁の回答を読んでもらえばわかるように、「ハンコ」文化を支えているのは、

法律ではなく

法律がハードルになっているとして脱ハンコはハードルが高いのだという誤った認識を広めている側

にあるのだ、ということがいえるだろうと思います。

そのような誤った認識を広めているのが、単なる誤解なのかもしれませんし、新たな技術を受容したくないバイアスによるのかもしれません。もしくは、自分でリスク評価をしたくないという他人任せの性格なのかもしれません。

社説というのは、会社の顔であり、面目をかけて作成さているものと理解しています。しかしながら、日本有数の経済新聞が、俗説にそのまま乗っかっるのは、恥ずかしいことかと思います。もしくは、この会議を詳しく読んでみるという特集でも、月曜日のコーナーでやるべきレベルの話だろうと思います。

こういってもらえるうちが花だと思うべきでしょうね>日経新聞

最後に、e-Signature/電子署名/デジタル署名の概念整理の図をもう一度。

 

 

 

「トランプ大統領 ソーシャルメディア対象の大統領令に署名」と公表者の法理

「トランプ大統領 ソーシャルメディア対象の大統領令に署名」という報道がなされています。

メディア的には、自分のツイートに、ファクトチェックのコメントをつけられた大統領が、これを制限しようと、腹を立てて、大統領令を発令したみたいな流れですが、はたしてそうなのでしょうか。

まずは、原文にあたってみましょう。大統領令は、こちら

第1条は、言論の自由の重要性を強調しています。しかしながら、それらが、

近年のオンライン・プラットフォームの成長は、現代の通信技術に修正第一条の理想を適用することについて重要な疑問を投げかけている。

としています。

第2条は、「オンライン検閲に対する保護」です。

具体的には、(良きサマリア人の法理である)通信品位法(CDA)の第230条(c)項(第230条(c))によって創設された責任の免除が重要な役割を果たしていること、その一方で、その免責の範囲を明確にすべきであると考えていることが主張されています。

この法理は、

オンラインプラットフォームが他人が投稿した一部のコンテンツへのアクセスを制限した場合、名誉毀損などの不法行為の目的で、そのサイトに投稿されたすべてのコンテンツの「パブリッシャー(公表者)」になるとした初期の判例に対処するために考案されたものです

法の下で許される最大限の範囲で、この規定が歪められて、好ましくないコンテンツを削除するために「善意」で行動するのとは程遠い、代わりに(多くの場合、利用規約に反して)同意しない視点を抑圧するために偽善的または口実のある行動をとるオンラインプラットフォームに対する責任保護を提供するように歪められないようにすることが、米国の政策です。

(略)

第230条は、一握りの企業が、開かれた議論の場を促進するという名目で、国の言論の重要な手段を支配する大企業に成長し、その権力を使ってコンテンツを検閲したり、自分たちが嫌いな視点を黙らせたりする場合に、それらの巨大な企業を完全に免責することを許可することを意図したものではありません。 インタラクティブ・コンピュータ・サービス・プロバイダーがコンテンツの削除やアクセス制限を行い、その行為が(c)(2)(A)号の基準を満たしていない場合、そのプロバイダーは編集行為を行っていることになります。 このようなプロバイダは、(c)(2)(A)号に定められている責任限定の盾をに失うのが適切であり、オンライン・プロバイダではない従来の編集者や出版社と同様に責任を問われるべきであるというのが米国の方針です。

というのが、具体的な問題点の提起になります。

そして、具体的な解釈論として明示されるべき事項としては、どうか、というと

(i) 第230条(c)(1)項と(c)(2)項の相互関係、特に、(c)(2)項(A)で特に保護されていない方法でコンテンツへのアクセスを制限する対話型コンピュータサービスのプロバイダは、(c)(1)項の保護を主張できない場合があることを明確にし、決定すること。

(ii) 素材へのアクセスや利用可能性を制限する行為が、第230条(c)(2)(A)号の意味で「善意で行われた」とは言えない条件、特に、以下のような場合に「善意で行われた」と言えるかどうか。

(A) 偽装的、口実的、またはプロバイダの利用規約と矛盾している場合。

(B) 十分な通知、合理的な説明、または意見を聞く有意義な機会を提供しなかった後に取られたもの。

その他適切な場合

第3条は、「連邦納税者の表現の自由を制限するプラットフォームからの保護」です。

連邦政府が、オンラインプラットフォームに対して広告宣伝費として支払っているのを見直すように言っています。

第4条は、不公正もしくは欺瞞的な行為等の見直しです。第5条は、州による見直し、第6条は、立法の準備、第7条は、定義、8条は、一般的規定になります。


ここで、上の通信品位法による責任制限とパブリッシャーの法理との関係を見ていきます。

これらの点については、私の会社のITリサーチアートが総務省からの調査を受託してなした「諸外国におけるインターネット上の権利侵害情報対策に関する調査研究の請負-報告書-」の報告書で明らかになっています。

まずは、上で「「パブリッシャー(公表者)」になるとした初期の判例」というのをみていきます。

パブリッシャーの法理については、報告書123頁で触れています。まず、「公表」とは、意図的又は過失により、ある事項の第三者への伝達に関与し、又は、当該伝達を許可することをいいます。そして、「当該表現を行った者のみならず、当該表現の伝達に関与した者(編集者など)、それを許可した者(出版社)も行為者となる。」のです。

でもって、1990年代にこの法理がインターネットに適用されるか、というのが議論されることになりました。イギリスとアメリカは、別途の発展を遂げます。

アメリカでの判決の発展は、188頁です。Cubby v. CompuServe, 776 F. Supp.
135(S.D.N.Y,1991)、Stratton Oakmont v. Prodigy, No. 31063/94, 1995 WL 805178 (N.Y.Sup. Ct. Dec. 11,1995)があり、通信品位法が制定されました。そして、Zeran判決で、上の230 条(c)が広く適用される契機になりました。

イギリスでは、 Godfrey v Demon Internet Limited 事件 [2001] QB 201 で、プブリッシャーの法理が、ISPに適用されることが確認されています。なので、基本的には、ISPにも名誉毀損が成立するものとされていました。その後、2013年名誉毀損法の成立などがなされます(報告書131頁)

オーストラリアでは、1999年放送サービス法改正法によって、免責が認められて、英国のプブリッシャー法理を否定しました。


230条(c)については、報告書の187頁に記載されています。

問題のある情報を制限・排除する良きサマリア人の保護
(1)公表者としての取扱い
インタラクティブ・コンピュータ・サービスのいかなるプロバイダ又はユーザーも、他のコンテンツ提供者によって提供された情報について、パブリッシャーとして取り扱われてはならない
(2)民事責任
いかなるプロバイダも以下のことを理由として責任を負わされてはならない

(A)下品、わいせつ、煽情的、卑猥、過剰に暴力的、嫌がらせその他問題があるとプロバイダが考える情報(略)に対するアクセス又は当該情報の利用を制限するために善意でとられた行動
(B)前段落所定の情報に対するアクセスを制限する技術的手段を実現するためにとられた行動(略)」

その一方で、インターネットのプレイヤーが、通信について伝達を主とするISPから、自ら、コンテンツを表示する情報コンテンツプロバイダーに変わってきたという事情がありました。

米国では、既に、通信品位法第 230 条(c)が、情報コンテンツプロバイダーかどうかが争われたという事案がありました。Jones v. Dirty world entertainment recordings llc.事件において、裁判所は、同項は、情報インタラクティブ・プロバイダが、問題のコンテンツの情報コンテント・プロバイダでない場合に限って認められるにすぎない、そして、ウェブサイト管理者が、コンテンツの創作若しくは発展(development)に、部分的に影響があれば、その点については、責任を負うべきであること、ただし、主張された違法性に主として貢献する(to materially contributing)」部分に限って判断されること、の判断をなしました。

その意味で、通信品位法第 230 条(c)の適用範囲については、あまり明確ではないのではないかとして議論されていたのだと思います。また、広範囲すぎるのではないか、という議論も出ているということも指摘されていました(報告書189頁)。

なので、大統領の一時的な私怨を晴らすための大統領令という見方は、正確ではないのではないか、というのが私の見方です。

「接触確認アプリ」の仕様書について (2)

仕様書 第1編を見た「接触確認アプリ」の仕様書について (1)のに続いて、第2編 仕様(要件定義)です。

第2編 仕様(要件定義)

要件定義は、機能要件と非機能要件に分かれています。

第1章 機能要件の定義

1. 機能に関する事項

これは、さらに基本機能(インストール)、認証機能、あと、アップル・グーグル枠組(Apple Google Frameworkですね、AGF)で実現する機能にわけて論じられています。アップル・グーグル枠組は、私のブログだと、既に見ているし、あと、本で、触れています。

インストールで興味深いところは、オプトインで、利用規約、ブルートゥース利用の案内、通知機能利用の確認がなされることが確認されているところです。また、同意の撤回についても、確認がなされています。

陽性利用者の接触履歴のアップロードが、「認証機能」という名称のもとで論じられています。これが、「認証機能」たるゆえんは、「いたずらの陽性者の通知を防止する」ための陽性者の端末の認証という趣旨ですね。

これは、世界でも共通の問題意識で、シンガポールは、保健所の職員がワンタイムパスワードでいれる仕組みですね。イギリスのNHSXは、自己申告の症状でもOKとしているので、ちょっと問題という記事を読みました。

この部分のフローと画面遷移の記載があります。

あと、近接接触した人数の総計の画面表示については、AGと調整中のようです。家族との間を近接接触といわれてもなんで、ホワイトリスト機能も要件になりますね。

利用中の機能は、AGFで提供なのでパス。

そのあと、フェーズ的には、近接接触者への通知ですね。AGF風には「ばく露通知」です。(ただ、理論的には、変動する近接識別子(Rolling Proximity Identifier@接触符号と訳されていますね)が送信されて、端末で、照合されるので、通知でもないでしょ、という人もいます。そのとおりです。正しく、理解することはとても大切です。) これは、図を貼っておきます(仕様書16頁より)。

この場合に、接触確認がなされると、接触確認フラグが、通知サーバーにいくのですが、保健所はスルーです。でもって、わが国だと、利用者が、保健所には、そのアプリでガイダンスを得て、「必要に応じて連絡」ということになっています。

なので、意図的にと思われますが、本来の「コンタクトトレーシング」という趣旨からは離れて、近接接触者の行動変容を促す、というのに重点がおかれた仕組みになっています。公式には、接触「確認」アプリといっています。

通知サーバー統計機能が記載されています。これは、上の図でいうと、接触確認フラグから統計をとるということですね。(調整中だそうです)

2. ファイルに関する事項

これについては、については、特に注意する事項はありませんでした。

3. 外部インタフェースに関する事項

これについては、日次キーと時刻による診断キーが送出されて、それを各自が手元で照合する仕組みが記載されています。(ここは、DP-3TとAGFの違いになっていたのかな、ここも本の修正が必要なりそうです。すみません。)

第2章 非機能要件の定義

1. ユーザビリティ及びアクセシビリティに関する事項

同意事項が多いこと、直感的操作、適切なガイダンス、視覚的な理解、英語の準備、未成年のための代理登録が触れられています。

2. システム方式に関する事項

システム(中央サーバの仕組みだと思います)は、クラウドサービスを利用することがうたわれています。あとは、OSは、両方、AGF準拠と。

3. 規模に関する事項

スマートフォンの国民の個人保有率が64.7%(令和元年版情報通信白
書)であるので、最大で国民の6割以上が導入することを目指す想定で
基盤等の拡張性を確保する。

だそうです。100%のインストール率を目指しているのかもしれません。個人的には、オプトインは、「スマッジ」ですね。でも、日本人だと奇跡はありうるのかも。ノーベル経済学をもふっとばすアマビエの御札効果ですね。

14日分の接触データ、日次キーの提供でもって、4月6日週レベルで押さえ込むからねという見込みがでています。

4. 性能に関する事項

応答時間(3秒以内)、通信回線の輻輳防止等、ブルートゥースの較正ですね。ブルートゥースの較正は、他の国でも論点になっているという認識です。

5. 信頼性に関する事項

稼働率ですね。

6. 拡張性に関する事項

処理能力の拡張が可能性、モジュール設計、接触カウント機能等の拡張、相互運用性にも対応が触れられています。

国際的な相互互換性について留意すべきことが触れられています。本のなかでは、これも重要な原則の一つとしています。

7. 上位互換性に関する事項

APIによる接続を原則とすることです。

8. 中立性に関する事項

ベンダーロックインの解消等、オープンな標準的技術または製品を用いること、開発ドキュメントの透明性の確保への配慮です。

9. 継続性に関する事項

一時的な停止で大きな社会的混乱を引き起こすものではないこと、端末の機種変更時のデータ引き継ぎは考慮しないことです。

10. 個人情報保護に関すること/11. 情報セキュリティに関する事項

別途の留意事項によります。

12. 情報システム稼働環境に関する事項

国内リージョンのクラウドサービスであることが、明らかにされています。これは、プライバシーやセキュリティの評価の際に問題がでてきます。

13. テストに関する事項

ベータ版のテストも検討することだそうです。

14. 運用に関する事項

通知サーバーの運用の自動化、異常発生時の工夫、FAQの整備、ユーザーとのコミュニケーションなどが記載されています。

15. 保守に関する事項

信頼性、継続性に配慮、サーバーの停止時間ができるだけ短期になるよう配慮、とのことです。

16. 関連ドキュメントの整備

整備されるべきドキュメントとして、利用規約等、設計書及び関連ドキュメント(ソースコード、通知サーバーの運用マニ ュアル含む)、簡易説明およびFAQ があげられています。

ということで、仕様書の分析は、終了。基本的には、このようにオープンな形で検討できるのは、すごくいいですね。


でもって、「接触確認アプリに関する有識者検討会合」で定める個人情報保護・セキュリティに関する留意事項をみていくことになります。

が、この検討は、アマゾンKindle出版で販売されている「新型コロナウイルス対プライバシー-コンタクトトレーシングと法」を6月1日のアップデートを行うなかでしようと思います。