行政手続における書面主義の見直し及びオンライン利用率を大胆に引き上げる取組について(戸籍謄抄本の請求等のオンライン化の促進等)

加工

内閣府第1回デジタルワーキング・グループ 令和3年9月8日(水)

https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/digital/20210908/agenda.html

議題.行政手続における書面主義の見直し及びオンライン利用率を大胆に引き上げる取組について(戸籍謄抄本の請求等のオンライン化の促進等)

・戸籍謄抄本の請求等のオンライン化の取組・課題について(株式会社グラファーからのヒアリング)

・戸籍謄抄本の請求等のオンライン化に係る国の取組等について(法務省からのヒアリング論点に対する回答

【論点1-③】

 戸籍の記載事項は、ベースレジストリにも指定されており、関連する手続のデジタル化が強く求められると考えられる。「法務省情報化推進会議」等において、戸籍謄抄本の請求・交付、届出分野のデジタル化を進める観点から、どのような検討が行われたか(事務次官がどのようにリーダーシップを発揮したかを含む)、具体的にご説明願いたい。

【論点1-③】

 本年7月に開催した「法務省情報化推進会議」においては,戸籍謄抄本の請求・交付,届出分野のデジタル化を含めた国民目線でのオンライン化やキャッシュレス化の推進などの課題に対する取組を強力に推進するために,省全体のデジタル化推進体制を強化する必要があるとの認識を出席者一同で確認した。

 そして,戸籍謄抄本の請求・交付,届出分野のデジタル化については,事務次官のリーダーシップの下,PMOにおいて,CIO補佐官からの知見も得つつ,担当PJMOと協議を重ね,オンライン利用率向上等に向けた検討を行うなどしている。

 また,戸籍情報の連携のための関係省庁との協議,例えば,旅券発給手続に関する外務省や内閣官房番号制度推進室との協議や年金手続などの社会保障手続に関する厚生労働省との協議などに当たって相談を受けるなどしている。

 さらに,戸籍事務におけるマイナンバー制度の利活用を推進するべく,①マイナンバーの提供等による戸籍謄抄本の添付省略並びに②戸籍の届出における戸籍謄抄本の添付省略及び本籍地以外の市区町村での戸籍謄本の発行を実現するために必要な経費を令和4年度予算概算要求に盛り込んでいる。

【論点2-①】

 現在、検討・策定を進めている基本計画等について、可能な範囲で、具体的内容をご説明願いたい。なお、目標については、狭い意味でのオンライン利用率に留まらず、コンビニ交付や情報連携により戸籍謄抄本等の添付が不要となる件数も考慮したものとすべきである。

【回答2-①】

 令和5年度中に戸籍情報連携システムを構築・稼動させることを予定している。これにより,戸籍の届出における戸籍証明書の提出や他の行政手続に添付する戸籍証明書の添付省略が図られることにより,そもそも戸籍証明書を取得する場面が減少することとなる。その結果,全ての市区町村の住民がその恩恵を受けることができることとなる。オンライン利用率の目標設定については,御指摘を踏まえつつ,検討してまいりたい。

【論点3-①】

 コロナ禍を踏まえて書面・押印・対面の見直しが進められる中におけるオンライン請求及びコンビニ請求に関する国民のニーズについて、可能な限り定量的にお示し願いたい。

【回答3-①】

 平成29(2017)年に実施した調査研究における結果,将来における戸籍証明書の取得方法に関するニーズとして,「インターネットでマイナンバーカードの電子証明書を利用して取得」するニーズが12.9%,「最寄りのコンビニエンスストアでマイナンバーカードを使ってマルチコピー機から取得」するニーズが11.1%あったところであるが,当局が構築する戸籍情報連携システムが稼動することにより,戸籍の届出における戸籍証明書の提出や他の行政手続に添付する戸籍証明書の添付省略が図られることにより,そもそも戸籍証明書を取得する場面が減少することとなり,全ての市区町村の住民がその恩恵を受けることができることとなる。

【論点3-②】

 戸籍謄抄本をオンライン請求もしくはコンビニ請求できる自治体数は人口カバー率でどの程度か、定量的にお示し願いたい。

【回答3-②】

 オンラインによる戸籍証明書の交付請求が可能な自治体は,本年7月1日現在,1896市区町村のうち,17市区町村(約 0.8%)であり,本籍人口は約 250 万人で,全体の約2%となっている。

 また,コンビニ交付の仕組みを使った戸籍証明書の交付請求が可能な自治体は,本年7月1日現在,1896市区町村のうち,693市区町村(約36.5%)である。なお,コンビニ交付は,住民票の住所を置く市区町村と本籍を置く市区町村が同一である場合にのみ交付請求ができる場合と,これらが同一でなくても交付請求ができる場合とがあるが,戸籍には住所情報がないため,コンビニ交付を受けることができる正確な人口割合は不明であるものの,人口比で約55%前後であると推計される。

【論点3-③】

 平成 29 年時点においてもオンライン請求及びコンビニ請求に対する一定のニーズが示されているが、オンライン請求やコンビニ請求を導入する自治体数が現況に止まる要因をどのように考えているか、具体的にご説明願いたい。

【論点3-④】

 論点3-③を把握するため、どのような取組を行ったのか、具体的にご説明願いたい。

【論点3-⑤】

 論点3-③について、具体的な把握ができていないとすれば、「デジタル社会の基盤となる制度を所管する省」としての取組が十分とは言えないと考えるが、法務省としての見解をお示し願いたい。

【回答3-③から⑤まで】

 市区町村において戸籍事務に従事する職員にヒアリングしたところ,オンライン請求については,コンビニ交付に比べ交付までに時間がかかることから,住民からのニーズが高くないこと,戸籍事務のためだけにオンライン請求を受け付ける環境を構築することに意義が見出せないこと,などが挙げられる。

 また,コンビニ交付については,オンライン請求に比べ比較的普及が進んでいるところ,特に地方の小規模自治体については,本籍人が必ずしも住民とは限らず,導入することが当該自治体の住民の利便性の向上に資するものとはいえないことから,予算措置の優先順位が低いことが挙げられる。

 さらに,いずれの仕組みについても,地方公共団体の事務が多数ある中で,その仕組みの導入は戸籍証明書の交付請求の場面に限ったものではない。

 もっとも,当局が構築する戸籍情報連携システムが稼動することにより,戸籍の届出における戸籍証明書の提出や他の行政手続に添付する戸籍証明書の添付省略が図られることにより,コンビニ交付やオンライン申請により戸籍証明書を取得する場面が大幅に減少することになる見込みである。

【論点3-⑥】

 オンライン請求やコンビニ請求を実現した自治体においても、必ずしも、オンライン請求やコンビニ請求の利用状況はそれほど多くないが、その要因をどのように考えているか、具体的にご説明願いたい。

【回答3-⑥】

 オンライン請求やコンビニ交付による請求を実施する前提として,マイナンバーカードを使って行う必要があるところ,マイナンバーカードが完全に普及していないことも一因であると考えられる。

 また,オンライン請求を導入している自治体において,現在,紙の証明書を郵送で返信する方式又は自治体の窓口で交付していることから,コンビニ交付と比較して交付までの時間がかかることが要因として挙げられる。

【論点3-⑨】

 オンライン請求システムを提供しているグラファー社からは、デジタル手続法により、戸籍のオンライン請求が制度上可能となっている旨を把握していない自治体職員もいるとの課題が示されている。オンライン請求が可能であること等について、自治体への周知徹底が不十分であると考えるが、法務省としての見解及び今後の対応についてお示し願いたい。

【回答3-⑨】

 オンライン請求は,デジタル手続法の施行前から法制上可能であり,平成16年の戸籍法令の改正により,導入することが可能である。平成16年には標準仕様書を通達として発出し,これに関する解説記事も掲載しているほか,平成22年(東京都中野区の取扱いの認容事例),令和2年(埼玉県志木市の取扱いの認容事例)にオンライン請求の認容事例を紹介する周知を実施も行った。さらに,デジタル手続法が成立したことを踏まえ,オンラインシステムを導入している市区町村の一覧を掲載し,制度の周知を図っているところである。

【論点3-⑪】

 オンライン請求システムを提供しているグラファー社からは、法務省が整備している「戸籍手続オンラインシステム構築のための標準仕様書」について、最新のデジタル技術を踏まえた改訂が必要との課題が示されている。法務省が整備している「戸籍手続オンラインシステム構築のための標準仕様書」については、最新のデジタル技術や、自治体における実際の運用状況等も踏まえ、不断の見直しが必要であり、ベンダーや自治体関係者等と定期的に意見交換をして課題や対応策を検討することが不可欠と考えるが、法務省の取組について、具体的にご説明願いたい。

【回答3-⑪】

 戸籍情報システムの仕様書については,例年,調査研究委託として実施される標準仕様研究会において改訂が実施されている。この研究会は,法務省職員や地方自治体職員,戸籍情報システム事業者から構成され,制度改正や技術の進歩等に合わせた仕様書の改訂について研究しており,定期的な意見交換が実施されているところである。

・・・・・・・・・・・・・・・・・・・・・・・・

司法書士を入れていただけないかな、と思います。

・・・・・・・・・・・・・・・・・・・

【論点3-⑫】

 一部の自治体からは、申請部分が電子化されても、戸籍情報を管理する内部システムと連動していないことから人による筆頭者等の審査・補正が必要、また、戸籍情報以外にも他のデータからDV等被害者に該当するか否か人による審査が必要等の理由から、オンライン請求を導入しても、自治体内部の効率化が図れないとの課題が示されている。デジタル化の推進に当たっては、申請者のインターフェイスだけでなく、自治体内部の業務も含め一連の業務をデジタル完結することが必要であるが、法務省としてどのような対応を行っているのか、具体的にご説明願いたい。

【論点3-⑬】

 論点3-⑫について、自治体任せにするのでは、「デジタル社会の基盤となる制度を所管する省」としての取組が十分とは言えないと考えるが、法務省としての見解をお示し願いたい。

【回答3-⑫及び⑬】

 戸籍証明書の交付申請に当たっては,戸籍を特定する必要があり,戸籍の特定は,本籍及び筆頭者氏名を明らかにすることにより行うこととなるが,本籍及び筆頭者氏名が正しく特定されない場合には,交付すべき戸籍証明書が明らかにならないことから,申請内容を修正する必要がある。本籍及び筆頭者氏名以外の情報により個人情報を特定する方法としては,例えば,個人のマイナンバーにより特定する方法が考えられるが,マイナンバーと戸籍情報との紐付けについては,関係府省担当者も委員として参加した法制審議会戸籍法部会においても審議され,個人情報保護の観点から,直接紐付けをすべきではないとされたところである。そのため,現在,マイナンバーと戸籍情報は紐付いておらず(又は「マイナンバーカードには戸籍情報は登録されておらず」),マイナンバーによっては戸籍が特定されないことから,申請する側で戸籍を特定する必要がある。

 また,DV加害者やその代理人から,DV被害者等が記載された戸籍に係る戸籍証明書の交付請求がされた場合には,当該請求が不当な目的によるものであるか否かを審査する必要があるところであり,いずれも交付請求の適否の審査において必要な行為であると考えている。もっとも,DV被害者等が記載された戸籍に係る戸籍証明書の取扱いについては,DV被害者等からの申出を受けて証明書が交付されないような仕組みを検討中である。

・・・・・・・・・・・・・・・・・

戸籍証明書の交付申請に当たって、請求者の生年月日が不要ということを初めて知りました。

・・・・・・・・・・・・・・・・・・・・・・・

【論点3-⑭】

 法務省では、DV加害者からの請求への対応は、当該請求が戸籍法第 10条2項の「不当な目的」に該当するか否かを自治体が個別判断すべきとしていると承知している。当然にして慎重かつ正確な判断が求められる性質の審査であると考えるが、一方でその審査には相応の事務負担が自治体に発生しているものと考えられる。他方で、埼玉県戸田市では、グラファー社と連携した上で、自治体内部における審査業務のデジタル化の実証実験を行っていると承知している。総務省と連携の上で戸田市の取組に関する課題・効果を検証し、デジタル技術を用いて画一的に判断可能な審査項目・業務について、事務負担軽減のための取組みの横展開を図るべきと考えるが、法務省としての見解をお示し願いたい。

【回答3-⑭】

 埼玉県戸田市における「審査業務のデジタル化の実証実験」の内容については,有益な情報があれば,是非お聞かせいただきたいと考えており,管轄法務局とも連携し,審査業務の効率化に資する事務負担の軽減に向けた取組を進めてまいりたい。

【論点3-⑮】

 「規制改革実施計画(令和3年6月 18 日閣議決定)」において、「キャッシュレス化の推進」が決定されているところ、郵送による請求の際には、手数料を定額小為替で納付するよう求める自治体も多数ある実態を踏まえると、自治体任せにするのでは、「デジタル社会の基盤となる制度を所管する省」としての取組が十分とは言えないと考えるが、法務省の見解及び今後の対応についてお示し願いたい。

【回答3-⑮】

 手数料の徴収に関する事項は,地方自治法に基づき条例によることとされているところであり,地方公共団体の事務は多数ある中で,決済方法の問題については,戸籍証明書の交付請求の場面に限ったものではないが,キャッシュレス決済の取組を進めている自治体の実例を紹介するなど,関係府省と連携して,利用者の利便性の向上に資する取組を進めてまいりたい。

【論点3-⑯】

 一部の自治体からは、請求総数のうち、士業による職務上請求が占める割合が高く、正当な理由であるか等の審査が必要で、本人請求を前提としたオンライン請求やコンビニ請求では対応できないとの課題が示されているが、士業団体等との協議状況も含め、法務省としての取組を具体的にご説明願いたい。

【回答3-⑯】

 士業者が戸籍証明書を請求する場合には,個人情報保護の観点から,その職務上必要とされるかについて,正当な事由の有無について審査が必要となる。

 当該請求については,利便性の向上を求める意見もある一方,本年8月にも,行政書士による不正請求が発覚するなど,不正請求事件も多く見られるところであり,市区町村からも,人権上の見地から,請求の事由を正確に記載するよう指導すべきとする意見もあるところであり,様々な意見を踏まえる必要があると考えている。

 なお,オンラインによる士業者からの職務上請求を可能とする戸籍法施行規則の改正については検討し,その旨を内閣府に回答したところである。

【論点3-⑰】

 平成 29 年8月の「戸籍制度に関する研究会最終取りまとめ」において、平成7年度から平成 15 年度までの間、戸籍の電算化に必要な経費について、特別交付税による財政支援がされ、各市区町村がベンダー(8社)から個別に戸籍情報システムを調達して順次電算化を進めた結果、電算化した自治体の数は、平成7年時点の 24 庁から平成 15 年には 1,497 庁へと拡大したことが示されている。

 一部の自治体からは、戸籍に限らずコンビニ請求を実施する際のサーバー設置費や、コンビニ等に支払う手数料が財政的に課題であるとの意見が示されているところ、総務省では一定の地財措置を講ずる等の取組を行っている。戸籍のオンライン請求及びコンビニ請求の拡大に向け、財政支援や複数の自治体による共同の取組の支援など法務省としての対応を検討すべきと考えるが、法務省の見解及び今後の対応についてお示し願いたい。

【回答3-⑰】

 財政措置の可否については,関係府省と相談の上で対応してまいりたい。

【論点4-①】

 「行政手続における戸籍謄抄本の添付省略」、「戸籍の届出における戸籍謄抄本の添付省略」、「本籍地以外での戸籍謄抄本の発行」のそれぞれにつき、検討状況及び課題並びに実現に向けた今後のスケジュールについて、具体的にご説明願いたい。

【回答4-①】

 行政手続における戸籍謄本等の添付省略等については,法務省において新たに整備する戸籍情報連携システムによって戸籍情報の提供を可能とすることとなるところ,その検討状況等は以下のとおりである。

○「行政手続における戸籍謄抄本の添付省略」

以下の2通りの実現方式について,現在,設計・開発を行っている。

① マイナンバー制度に基づき情報提供ネットワークシステムを通じて戸籍情報を提供する方式

 改正戸籍法(令和元年法律第17号)附則第1条第5号による施行日(令和6年3月予定)の導入を目指して開発中である。

 ・開発・テスト:令和4年度まで ・情報提供用個人識別符号取得:令和4年度 ・連携テスト:令和5年度 ・運用開始:令和6年3月

② 電子的な戸籍記録事項の証明情報(戸籍電子証明書)をオンラインで提供する方式

令和6年度中の導入を目指して設計中である。

 ・対象行政機関と調整の上,現在設計中 ・運用開始:令和6年度以降

○「戸籍の届出における戸籍謄抄本の添付省略」

改正戸籍法(令和元年法律第17号)附則第1条第5号による施行日(令和6年3月予定)の導入を目指して開発中である。

・開発・テスト:令和4年度まで・連携テスト:令和5年度・運用開始:令和6年3月

○「本籍地以外での戸籍謄本の発行」

 改正戸籍法附則第1条第5号による施行日(令和6年3月予定)の導入を目指して開発中である。

・開発・テスト:令和4年度まで・連携テスト:令和5年度・運用開始:令和6年3月

【論点4-②】

 「デジタル・ガバメント実行計画(令和2年 12 月 25 日閣議決定)」において、「戸籍謄本・抄本は、身分関係等を証明することを目的として、年間約 4,200 万件(令和元年)が発行されており、法令に基づく約 500 種類以上の国の行政手続において提出を求めることとなっている。」とあるが、速やかに添付省略が実現され、国民・行政双方のデジタル化・事務負担の軽減が図られる必要がある。上記取組みによって、500 種類以上の手続について、いつまでに、どの程度の手続(種類数・件数ベース・内容)で添付省略が実現されるのか、ご説明願いたい。

【回答4-②】

 IT室による「ワンスオンリー実現に必要な情報連携拡大等検討のための基礎調査」結果等を踏まえ,合計で 600 種類以上,少なくとも 1,000 万件以上の手続について,戸籍謄抄本の添付省略が実現される見込みであり,その詳細は以下のとおりである。

○「行政手続における戸籍謄抄本の添付省略」

①マイナンバー制度に基づき情報提供ネットワークシステムを通じて戸籍情報を提供する方式

 ・約 580 手続,件数 約 580 万件 ・令和6年度から順次開始

② 電子的な戸籍記録事項の証明情報(戸籍電子証明書)をオンラインで提供する方式

 ・約 30 手続,件数 約 345 万件 ・令和6年度中に開始

○「戸籍の届出における戸籍謄抄本の添付省略」

・件数 約 121 万件・令和6年3月から開始

【論点4-③】

 平成 29 年8月の「戸籍制度に関する研究会最終取りまとめ」において、「戸籍謄本等の交付請求をした目的」として「パスポートの申請のため:61.6%」、「婚姻届など戸籍の届出で提出するため:50.2%」、「年金や児童扶養手当などの社会保障給付金受給に関する手続で提出するため:27.0%」等のニーズが示されている。これら国民のニーズが高い手続については、速やかに添付省略が実現される必要がある。法務省としての取組を具体的にご説明願いたい。

【回答4-③】

 戸籍情報連携システムを整備することで,国民のニーズが高いとされた以下の手続について,戸籍謄抄本の添付省略が実現される見込みである。

○「パスポートの申請のため:61.6%」【論点4-①】の回答で示した「行政手続における戸籍謄抄本の添付省略」の②電子的な戸籍記録事項の証明情報(戸籍電子証明書)を提供する方式により,添付省略が実現される。

○「婚姻届など戸籍の届出で提出するため:50.2%」【論点4-①】の回答で示した「戸籍の届出における戸籍謄抄本の添付省略」により,添付省略が実現される。

○「年金や児童扶養手当などの社会保障給付金受給に関する手続で提出するため:27.0%」

【論点4-①】の回答で示した「行政手続における戸籍謄抄本の添付省略」マイナンバーに基づき情報提供ネットワークシステムを通じて戸籍情報を提供する方式により,添付省略が実現される。

【論点4-⑤】

 平成 29 年8月の「戸籍制度に関する研究会最終取りまとめ」において、全国の市区町村における戸籍謄本等の利用目的別の比率は「相続関係手続」が 33.9%に上ることが示されており、相続時においては、民間の手続きについても戸籍謄抄本の添付を求める手続が多数ある。国民負担の軽減の観点から、民間手続における戸籍謄抄本の利用についても可能な限り定量的・具体的に手続の種類・内容を把握したうえで、情報連携による添付省略の取組について、検討を開始すべきと考える。法務省としての見解をお示し願いたい。なお、十分にデジタル化が進まない中で、本籍地以外での戸籍謄抄本の請求が可能にすれば、都市部の自治体等において他の自治体分の戸籍請求も増えることも想定されるところであり、こうした問題について、法務省としてどのようにどのように考えているか、併せてお示し願いたい。

【回答4-⑤】

(民間手続における戸籍謄抄本の利用について)

 戸籍謄抄本については,利用目的別の比率の高い行政手続だけでなく,民間でも相続時においては添付を求める手続が多数あるものと承知している。

 この点に関し,デジタル・ガバメント実行計画の「死亡・相続ワンストップサービス」においては,「内閣官房は、戸籍情報連携システムの戸籍電子証明書(電子的な戸籍記録事項の証明情報)を活用した法定相続人の特定に係る遺族等の負担軽減策について、法務省と検討を行う」とされており,引き続き内閣官房の検討に協力してまいりたい。

 なお,【論点4-①】の回答で示した「本籍地以外での戸籍謄本の発行」により,本籍地以外の市区町村の窓口でも,自らや父母等の戸籍謄本の取得を可能とする広域交付の仕組みが導入されるため,国民の利便性向上に大きく資することとなると考える。

(「都市部の自治体等において他の自治体分の戸籍請求も増える」について)

 御指摘のとおり,人口が集中する都市部の自治体等においては,他の自治体の戸籍謄本の請求が増えることも想定されるところではあるが,国民の利便性向上のため,都市部の自治体等の理解を得つつ,所要の検討を進めてまいりたい。

・・・・・・・・・・・・・・・・・・・

戸籍謄本の交付は、自治体の収入にはならないのでしょうか。

・・・・・・・・・・・・・・・・・・・・・

【論点5-①】

平成 16 年から制度上可能となっているにもかかわらず、現在、導入している自治体は無いことについて、具体的な要因をどのように考えているか、ご説明願いたい。

【論点5-②】

論点5-①について、具体的な把握ができていないとすれば、「デジタル社会の基盤となる制度を所管する省」としての取組が十分とは言えないと考えるが、法務省としての見解をお示し願いたい。

【回答5-①及び②】

 届出のオンラインシステムを導入しない理由について,証明書のオンラインシステムを導入する市区町村に聞いたところ,以下の課題があるとのことであった。

①オンライン届出と紙の届出が混在することとなり、処理が複雑となる。

  • オンライン届出情報の他市区町村への送付や添付資料の確認など検討課題が多い。
  • 戸籍のオンライン届出については,届出人や証人についても電子署名が必要であるなど,届出を行うまでのハードルが高く,現実的でない。

【論点5-③】

 死亡時における国民の手続負担軽減の観点からは、死亡・相続ワンストップサービスの利便性向上等が必要である。「第 14 回デジタル・ガバメント分科会(令和3年 3月 26 日)」において、死亡届及び死亡診断書(死体検案書)の提出をオンラインで完結する仕組みの構築に向けて、厚生労働省と共に検討を開始することが示されているが、具体的に何がいつまでにどの様な工程を経て実現されるのか、課題は何か、ご説明願いたい。

【回答5-③】

 死亡届及び死亡診断書(死体検案書)の提出をオンラインで完結する仕組みの構築に向けては,現在,デジタル庁及び厚生労働省とともに取り組んでいるところである。当省としては,市区町村長が死亡診断書の内容を確認することが可能な場合には,死亡の届書に死亡診断書の添付を省略することができる旨の戸籍法施行規則の改正を本年4月に実施したところである。

 電子死亡診断書を市区町村に送付する運用の実施に当たっての主な課題としては,HPKI(保健医療福祉分野の公開鍵基盤)カード電子署名や医療関係データの送付の仕組みの普及などがあると承知している。現在,関係府省の間で,添付省略の取扱いの実証的運用について,本年度中に実施する方向で調整中である。

【論点5-④】

 死亡届以外も、例えば出生届及び出生証明書のデジタル化や、離婚届と調停調書のデジタル化など、関係府省等と連携して、国主導でオンライン化・デジタル化の検討を進めることが、国民の利便性向上につながると考える。

 法務省としてデジタル化に向けた取組みに率先して取り組むことが必要と考えるが、法務省としての見解をお示し願いたい。

【回答5-④】

 戸籍届書の添付書類の電子化は,手続をデジタルで完結させるために必要な課題であり,重要な取組であると認識している。今後とも引き続き,添付書類の電子化について関係府省等と取り組んでまいりたい。

デジタル署名検証ガイドライン第 1.0 版

デジタル署名検証ガイドライン第 1.0 版 2021年3月31日

NPO 法人日本ネットワークセキュリティ協会電子署名ワーキンググループ

https://www.jnsa.org/result/e-signature/2021/index.html

加工

目次

1はじめに …………….. – 1

-1.1 背景と目的 ……………………………………………………………………………… – 1

-1.2 スコープ …………………………………………………………….. – 1

-1.3 本書の位置付けと構成 ………………………………………… – 1

 -2 参照文献 ……………………………………………………………………………………. – 3 –

2.1 引用規格 …………………………………………………………………………………… – 3 -2.2参考文献………………………………………… …………… – 4

 -3 用語定義と略語 …………………………………………………………………………… – 5

-3.1 用語 …………………………………………………………………………………… – 5

 -3.2 略語 …………………………………………………… – 8

-4 デジタル署名 ………………………………………………………………………………… – 9

 -4.1 デジタル署名の概念モデル …………………………………………………….. – 9 –

4.1.1 デジタル署名の基本原理 ………………………………………………………… – 9 –

4.1.2 電子証明書と認証局、公開鍵基盤(PKI) ……………………………………….. – 9 –

4.1.3 デジタル署名のメカニズムと基本要件 ……………………………………… – 11 –

4.1.4 署名データの形式 ……………………………………………………………. – 13 –

4.2 時刻の保証と長期署名フォーマット …………………… – 15 –

4.2.1 時刻情報とタイムスタンプ局 …………………………………………… – 15 –

4.2.2 長期的な署名の担保と署名の延長 ………………………………………… – 15

4.2.3 AdESフォーマット ……………………….. – 18 –

5 デジタル署名の検証 ………………………………………… – 21 –

5.1 署名検証の概念モデル ………………………………… – 21 –

5.1.1 署名検証の基本要件 ……………………………. – 21 –

5.1.2 検証のアプリケーションモデル ………………………………….. – 22 –

5.1.3 署名判定結果の概念モデル ……………………………………………….. – 23 –

5.1.4 要求レベル(必須とオプション)の考え方 ………………………. – 24 –

5.2 検証プロセス …………………………………………. – 25 –

5.2.1 検証プロセスの考え方 ……………………………………………………… – 25 –

5.2.2 トラストアンカー ………………………………………………………. – 26 –

5.2.3 証明書 …………………………………………….. – 26 –

5.2.4 失効情報 ………………………………………………………….. – 26 –

5.2.5 暗号アルゴリズムの脆弱性に関する情報 …………………… – 27 –

5.2.6 タイムスタンプ …………………………………………. – 27 –

5.2.7 検証基準時刻(validation reference time)…………………….. – 27 –

5.2.8 署名要素に対する制約 …………………………………….. – 28 –

5.3 検証データの全体構造 ………………………………………. – 29 –

5.3.1 署名者による署名(AdES-BES) …………………………………………. – 29 –

5.3.2 署名タイムスタンプ付き署名(AdES-T) ……………… – 30 –

5.3.3 検証情報付き署名(AdES-X-Long) …………………………………….. – 31 –

5.3.4 アーカイブ付き署名(AdES-A) ……………………………. – 32 –

5.4 検証基準時刻と検証の観点 ………………………….. – 33 –

5.4.1 AdES-BES検証における検証基準時刻と検証の観点 ………… – 33 –

5.4.2 AdES-T検証における検証基準時刻と検証の観点…………… – 34 –

5.4.3 AdES-X-Long検証における検証基準時刻と検証の観点 ………………. – 37 –

5.4.4 AdES-A検証における検証基準時刻と検証の観点…………. – 40 –

5.5 署名の検証要件 …………………………………. – 46 –

5.5.1 アルゴリズムの有効性の確認 ……………………. – 46 –

5.5.2 CAdESの検証要件 ………………………………. – 46 –

5.5.3 XAdESの検証要件 …………………………. – 51 –

5.5.4 PAdESの検証要件 ………………………. – 58 –

5.6 タイムスタンプの検証要件 ……………………… – 66 –

5.6.1 タイムスタンプ ……………………. – 66 –

5.6.2 署名タイムスタンプ …………………… – 70 –

5.6.3 アーカイブタイムスタンプ …………………… – 71

5.6.4 ドキュメントタイムスタンプ ……………………….. – 75 –

5.7 証明書の検証要件 ……………………………………………. – 77 –

5.7.1 AdES-BESにおける証明書 …………………………………………. – 77

 -5.7.2 AdES-Tにおける証明書 …………………………………… – 81

 -5.7.3 AdES-Aにおける証明書 ……………………. – 84

 -付属書 A (規定):供給者適合宣言書及び供給者適合宣言書の別紙 . – 86 –

A.1 序文 ……

A.2 供給者適合宣言書の様式 ………………………. – 86 –

A.3 供給者適合宣言書の別紙の様式 ………………………. – 86 –

A.4 検証手順 ……………………………. – 87 –

A.4.1 共通 ………………………………………… – 87 –

A.4.2 CAdES 検証 …………………………………………………… – 88 –

A.4.3 XAdES 検証 ………………………. – 89 –

A.4.4 PAdES 検証 ……………………………………….. – 90 –

A.5 データ …………………………………………. – 91 –

A.5.1 タイムスタンプトークンデータ要素 ………………… – 91 –

A.5.2 CAdES データ要素 ……………………………………… – 93 –

A.5.3 XAdES 構文のXML要素 …………………….. – 94 –

A.5.4 PAdESのデータ要素 ………………………… – 95 –

A.6 X.509 証明書 …………………………………. – 97 –

A.6.1 X.509 証明書パス検証 ……………………………………………….. – 97 –

A.6.2 署名者証明書のX.509証明書パス検証 …………………. – 98 –

A.6.3 TSA証明書のX.509 証明書パス検証 …………………. – 98 –

付属書

B (参考): PAdES関連情報 …………………………… – 99 –

B.1 PAdES署名レベル判定 …………………………….. – 99 –

B.2 PAdES複数署名 …………………………………………. – 100 –

B.3 PAdES署名後の増分更新 ……………………………… – 101 –

B.4 PAdES署名とPDF暗号化仕様 ……………………………. – 102 –

B.5 PAdES署名のAcrobat Readerによる検証 ………………… – 103

-付属書 C (参考): 暗号アルゴリズム ……………… – 104 –

C.1 暗号アルゴリズムや鍵長の安全性確認の困難さについて …… – 104 –

C.2 AdES署名検証の暗号アルゴリズム及び鍵長の安全性判断基準の一例. – 108 –

– 1 -1 はじめに

1.1 背景と目的

 デジタル化とネットワーク化の進展に伴い、デジタルデータの保証と取り扱う人やサービスの信頼性が、これまで以上に必要とされるようになっている。中でもデータの作成責任とその真正性は、アナログ時代においては「署名」や「押印」によって担保されてきた。デジタル時代においては、それに相当する技術として「電子署名」がある。署名は文書等にそれが付与され、受領者が署名を確認することで文書等の真偽や価値の判断材料となる。しかし、可視データであるアナログの「署名」や「押印」と違い、「電子署名」は機械処理としての「署名検証」が必要であり、検証ツール(ソフトウェア)に依存することになる。さらに、電子署名は様々な要素から構成されており、その判定は注意を要する。その判定基準が検証ツールによって異なると、同じデータに対する判定が異なる結果となり、デジタル化の阻害要因となりかねない。それを防ぐため、次世代電子商取引推進協議会(ECOM)平成18 年度成果「電子文書長期保存ハンドブック」など、署名検証の判定基準について検討されてきた。本書は、電子署名のうち公開鍵暗号技術に基づくデジタル署名について検証のガイドラインを示すため、タイムビジネス協議会(TBF)2013 年作成の「電子署名検証ガイドライン」を引き継いで更新したものである。

1.2 スコープ

 電子署名とは、電磁的記録(電子文書)に関連付けられ、検証により確認可能な、電子的措置であり、その効力を持たせるために様々な方式がある。欧米では電子署名(electronicsignature)とデジタル署名(digital signature)を区別し、電子署名は広い意味で、本人と電子文書との関係を示すために本人が作成した電子データを指し、デジタル署名は、署名者の身元とデータが改ざんされていないことを、公開鍵暗号技術を使って検証できる技術を指す。本書では、デジタル署名の中でも特に規格が整備され、相互運用性、国際流通性に優れた先進電子署名(AdES)を取り上げ、以後、電子署名(又は単に署名)と記した場合はこれを指すものとする。特に規約部分では、国際標準として規定された CAdES、XAdES、PAdES のプロファイルを対象として検証の処理を示す。なお、本書では技術的な判定基準について述べるが、法的有効性に関してはスコープ外とする。

1.3 本書の位置付けと構成

 本書は、先進電子署名(AdES)の検証処理に関するガイドライン(規約部分を含む)を定めるものである。・ 規約には技術的有効性を確認するための要件を定義する。- 署名検証の共通要件と CAdES、XAdES、PAdES の固有要件とを定義する。

 規約には、技術的な安全性確保を優先して決定した値を規定する(規定値と呼ぶ)こととし、各国の法規制等に依存する要素や適用領域の事情に依存する要素は極力排除することとする。

・ アプリケーションの提供者が各実装における規定値との差分を明示するための供給者による適合宣言書の書式を提供する。

対象読者:・ 署名検証システムあるいはサービスの利用者。

・ 署名検証システムあるいはサービスの調達者。

・ 署名検証システムあるいはサービスの開発者(設計者及び実装者)。

構成:・ 1 章:本章。本書のスコープ、対象読者、構成、使い方を記す。

・ 2 章:本書が準拠すべき規格(引用規格)と参考となる文献(参考文献)を記す。

・ 3 章:用語定義と略語を記す。

・ 4 章:署名の基本概念とデータ形式を記す。

・ 5 章:署名検証の概念モデルと検証の詳細要件(規約部分)を記す。

・ 付属書:供給者適合宣言書の書式及び実装に関わる参考情報等を記す。

推奨する参照範囲:

・ 利用者は 3 章を参照し、4 章、5.1 節を読むことを推奨する。

・ 調達者は 3 章を参照し、4 章、5 章を読むことを推奨する。

・ 開発者は 2 章及び 3 章を参照し、4 章、5 章、付属書を読むことを推奨する。

2 参照文献

2.1 引用規格

[1] ISO 14533-1:2014:「商取引、産業におけるプロセス、データ要素、およびドキュメントおよび管理-長期署名プロファイル-パート1:長期署名CMS高度電子署名(CAdES)のプロファイル」

[2] ISO 14533-2:2012:「商取引、産業におけるプロセス、データ要素、およびドキュメントおよび管理-長期署名プロファイル-パート2:長期署名XML高度電子署名(XAdES)のプロファイル」

[3] ISO 14533-3:2017:「商取引、産業におけるプロセス、データ要素、およびドキュメントおよび管理-長期署名プロファイル-パート3:長期署名PDF高度電子署名(PAdES)のプロファイル」

[4] ISO 32000-2:2017:「ドキュメント管理-ポータブルドキュメントフォーマット-パート2:PDF 2.0 “

[5] EN 319 122-1:「CAdESデジタル署名。パート1:ビルディングブロックとCAdESベースライン署名」

[6] EN 319 122-2:「CAdESデジタル署名。パート2:拡張CAdES署名」

[7] EN 319 132-1:「XAdESデジタル署名。パート1:ビルディングブロックとXAdESベースライン署名」

[8] EN 319 132-2:「XAdESデジタル署名。パート2:拡張XAdES署名」

[9] EN 319 142-1:「PAdESデジタル署名。パート1:ビルディングブロックとPAdESベースライン署名」

[10] EN 319 142-2:「PAdESデジタル署名。パート2:追加のPAdES署名プロファイル」

[11] IETF RFC 5280:「インターネットX.509公開鍵インフラストラクチャ証明書と証明書失効リスト(CRL)プロファイル」。

[12] IETF RFC 6818:「インターネットX.509公開鍵インフラストラクチャの更新証明書および証明書失効リスト(CRL)プロファイル」

[13] IETF RFC 8398:「X.509証明書の国際化された電子メールアドレス」

[14] IETF RFC 8399:「RFC5280の国際化アップデート」

[15] ISO / IEC 9594-8:2017:「情報技術-オープンシステム相互接続-ディレクトリ–パート8:公開鍵および属性証明書フレームワーク」。

[16] W3C勧告:「XMLSignature構文および処理バージョン2.0」、2015年

[17] IETF RFC 3161:「インターネットX.509公開鍵インフラストラクチャ;タイムスタンププロトコル(TSP)」。

[18] IETF RFC 5816:「RFC3161のESSCertIDv2アップデート」

[19] IETF RFC 5652:「暗号化メッセージ構文(CMS)」。

[20] IETF RFC 8933:「アルゴリズムの暗号化メッセージ構文(CMS)の更新識別子の保護」

[21] IETF RFC 4998:「エビデンスレコード構文(ERS)」。

[22] IETF RFC 6283:「ExtensibleMarkup Language Evidence RecordSyntax(XMLERS)」

2.2参考文献

[i.1] IETF RFC 4158:「インターネットX.509公開鍵インフラストラクチャ:認証パス建物”。

[i.2] TS 119 172-1:「署名ポリシー;パート1:ビルディングブロックと目次人間が読める署名ポリシー文書の場合」

[i.3] TS 119 172-2:「署名ポリシー;パート2:署名ポリシーのXML形式」

[i.4] TS 119 172-3:「署名ポリシー;パート3:署名ポリシーのASN.1形式」

[i.5] TS 119 172-4:「署名ポリシー;パート4:の署名検証ポリシー信頼できるリストを使用したヨーロッパの資格のある電子署名/シール」

[i.6] IETF RFC 6960:「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」。

[i.7] EN 319 102-1&TS 119 102-1:「AdESの作成と検証の手順デジタル署名; パート1:作成と検証」

[i.8] TS 119 102-2:「AdESデジタルの作成と検証の手順署名; パート2:署名検証レポート」

[i.9] IETF RFC 5698:暗号化のセキュリティ適合性のためのデータ構造アルゴリズム(DSSC)

[i.10] 電子文書長期保存ハンドブック:次世代電子商取引推進協議会,2007.3https://www.jipdec.or.jp/archives/publications/J0004262[i.11] 電子署名検証ガイドライン V1.0.0:タイムビジネス協議会 調査研究 WG, 2013.6.5

3 用語定義と略語

3.1 用語用語は一般的なものを除き、ISO、IETF RFC、JIS、ETSI などの規格に基づく。引用規格(normative references):本書が参照する規格。

 ベース仕様(base specification):プロファイルのベースとなる仕様。例えば PAdES であれば、ベース仕様は PDF の ISO 32000-2 となり、プロファイルは ISO 14533-3 となる。

 プロファイル(profile):標準化においてプロファイルとは、ベースとなる仕様(引用規格)の部分集合(サブセット)となる。先進電子署名においては、ISO 14533 シリーズで定義された ISOプロファイルと、欧州のEN としての Baseline 署名(プロファイルと呼んでいないが事実上はプロファイル)がある。

先進電子署名(Advanced Electronic Signature (AdES)):次の要件を満たす電子署名。

1) 署名者とユニークに関係付けられている

2) 署名者を特定することができる

3) 署名者単独の制御下にある手段で生成される4) その後データが改ざんされたことを発見できるような方法でデータと関連付けられている注:以降、本書では先進電子署名を「署名」と略して用いる。

【コラム1】■AdES という呼称の経緯

 1999 年に発行された EU 電子署名指令(Directive 1999/93/EC)で”Advanced ElectronicSignature”が定義されている。”Advanced Electronic Signature”は日本では「先進電子署名」あるいは「高度電子署名」と訳される。ただし、略称となる”AdES”は用いられていない。初期 ETSI の電子署名に関する規格(例えば”ETSI TS 101 733 V1.2.2 (2000-12);Electronic signature formats”)でこの定義を参照しているが、”Advanced ElectronicSignature”の略称として”AdES”を当ててはいない。

 最初に”AdES”の略称を用いたのは”ETSI TS 101 903 V1.1.1 (2002-02); XML AdvancedElectronic Signatures (XAdES)”であり、その後、CMS の電子署名規格(ETSI TS 101 733V1.6.3 (2005-09); CMS Advanced Electronic Signatures (CAdES))でも”AdES”(実際には”CAdES”であるが)が用いられるようになった。2014 年に成立したEU のeIDAS 規則(eIDAS Regulation)でも電子署名指令の定義は引き継がれており、”Advanced Electronic Signature”に対して電子署名指令とほぼ同等の定義が与えられているが、略称”AdES”が用いられていないのは電子署名指令と同様である。またeIDAS 規則では自然人が生成する電子署名(Electronic Signature)に加え、法人が生成する e シール(Electronic Seal)の概念を導入し、”Advanced Electronic Seal”の要件を定義している。その後、ETSI では”ETSI TS 119 122-1 V1.0.1 (2015-07)”や”ETSI TS 119 102-1 V1.0.1(2015-07)”などの規格から、”AdES”を略称ではなく固有名詞として扱い、CMS、XML、PDF それぞれに対する署名として”CAdES Digital Signature”、”XAdES Digital Signature”、”PAdESDigital Signature”を、又その総称として”AdES Digital Signature”を用いるようになった。

“AdES”が”Advanced Electronic Signature”あるいは”Advanced Electronic Seal”のどちらの略称であるかが区別できないこと、両者の要件を満たす共通技術としてデジタル署名(Digital Signature)が想定されていること、ETSI が制定する規格がデジタル署名を対象としていることなどからそのような対応となったと考えられる。

 署名レベル(signature level):先進電子署名において、プロファイル定義されている 4 つの署名のレベル(生成段階)を示す。

 証明書の認証パス検証(certification path validation):証明書チェーンの有効性を確認する処理。

 (署名検証)制約(constraints)/検証制約(validation constraint):先進電子署名の有効性を検証するときに署名検証アプリケーション(SVA)が照合する、規則、値、範囲、計算結果の抽象的に定式化したもの。形式的な署名ポリシー、設定ファイル、あるいは SVA の処理に組み込まれたものとして定義できる。

 署名対象データ(data to be signed):署名されるデータ(例えば、文書や文書の部分)。注:署名対象データは、公開鍵暗号技術による署名処理の入力となる。署名対象データと署名属性を入力として与える方法の仕様は、署名フォーマットごとに標準規格で定義される。

 駆動アプリケーション(Driving Application (DA)):SVA と呼ばれる電子署名検証のためのアプリケーションに対して検証対象や制約情報を与えて検証を依頼するアプリケーション。SVA は DA に対して検証結果を返す。

 署名ポリシー(signature policy):署名の生成や検証のための規則の集合。これに基づいて、特定のトランザクションの文脈における署名の有効性が決定する。

 署名検証(signature verification):検証対象のデータに対して公開鍵暗号技術により、改ざんがないことを確認する処理。

 署名有効性検証(signature validation):署名の有効性を確認する処理。証明書の有効性検証や、署名検証を含め、署名がローカルなあるいは共通の署名ポリシーが要求することに従っているかどうかを総合的に確認することを含む処理。注:verification と validation の違い

・verification:正しいこと/事実であることを確かめる/実証する/検証すること

・validation:有効であること/妥当であることを認める/確認する/認証すること

 署名検証アプリケーション(Signature Validation Application (SVA)):本書に定義された署名有効性検証処理を実装したアプリケーション。注:署名有効性検証アプリケーションは、駆動アプリケーション(DA)との間で検証結果をやり取りする。

 検証情報(validation data):署名者や検証者によって収集された、署名の有効性検証に必要なデータ。注:証明書、失効情報(CRL や OCSP Response)、タイムスタンプなどを含む。

 検証者(verifier):署名の有効性検証や検証を行うエンティティ。

3.2 略語

BES 基本的な電子署名それ認証局

CRL 証明書失効リスト

DA 運転アプリケーション

EPES 明示的なポリシーベースの電子署名

LT 長期からアーカイブタイムスタンプ付きの長期

LTV 長期検証OCSPオンライン証明書ステータスプロトコル

OID オブジェクト識別子

PKIX Public Key Infrastructure using X. 509、IETF PKIX ワーキンググループ

RSA Rivest,Shamir,Adleman による公開鍵暗号方式全て署名検証アプリケーション

TSA タイムスタンプ機関

TSTタイムスタンプトークン

URI ユニフォームリソース識別子

4 デジタル署名

4.1 デジタル署名の概念モデル

4.1.1 デジタル署名の基本原理

 紙文書や物理的な媒体における署名(サイン)や押印は、署名対象の作成者を示すとともに、署名対象が真正であることを示すためのものである。電子文書など電子データにおいても、その作成者(文責)と非改ざん性を証明するために、様々な電子署名方式が考案されている。中でも公開鍵暗号を用いたデジタル署名は、技術の整備と標準化が進み、最も普及している署名方式と言える。デジタル署名では、公開鍵暗号の署名鍵で生成した署名は、対となる検証鍵でのみ有効性を検証できる。また署名鍵を署名者のみが保有する秘密鍵(Private key:私有鍵とも呼ばれる)とすることで、他人が同じ鍵を生成できず、検証鍵を公開して公開鍵(Public key)とすることで、誰でも検証可能となる。つまり、秘密鍵を保有する人が署名したことと、検証結果により元のデータの改ざん有無が分かる。

図 4.1.1-1 公開鍵暗号による署名・検証なお、公開鍵暗号の一種である RSA 暗号の場合、署名処理として暗号化、検証処理として復号が行われる。

4.1.2 電子証明書と認証局、公開鍵基盤(PKI)

署名の本人性を確保する上での前提事項は以下の2点である。

1 署名者本人以外が秘密鍵を使用できないこと

2公開鍵が、署名者の所有する秘密鍵とペアとなるものであることが担保できること

 本人以外が使用できないことについては、一般的にはIC カードなどに格納して本人が適切に管理することにより実現される。その上で署名の本人性を担保するには、公開鍵が誰のものであるかを保証することが重要となる。“信頼できる第三者機関”(Trusted Third Party、以下 TTP)が公開鍵の所有者(ペアとなる秘密鍵の所有者)を保証するモデルが認証局モデルである。認証局(CA)は利用者(秘密鍵の所有者)の本人確認を実施した上で公開鍵の所有名義人であることを証明する公開鍵証明書の発行を行い、利用者と公開鍵の紐付けを保証する。公開鍵証明書には発行元の認証局のデジタル署名が付与され、一般的には電子証明書とも呼ばれる(本書では以下、証明書と記す)。

 本人確認等を行い、利用者と鍵の紐付けを担う機能を取り出して登録局(RA)と呼ぶことがある。

図 4.1.2-1 認証局と公開鍵証明書

【コラム2】■電子署名の法的定義電子署名法(電子署名及び認証業務に関する法律(平成 12 年 5 月 31 日法律第百二号))2 条 1 項にて、「電子署名」は、以下のとおり規定されている。

―――「電子署名」とは、電磁的記録に記録することができる情報について行われる措置であって、次の要件のいずれにも該当するものをいう。

一 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。

二 当該情報について改変が行われていないかどうかを確認することができるものであること。(一部省略)―――

つ まり、本人性が確認できること、及び、改ざん検知ができることが電子署名の要件となっている。従って、電子署名の有効性を検証する場合は、「本人性の確認」、「署名対象データの非改ざん性の確認」の2点を実施する必要がある。また、同法は、自然人を対象としており、電子署名に法的有効性を与えている(同 3 条)。

 なお、同法による認定を受けた特定認証業務(認定認証業務とも呼ばれる)では証明書の有効期間は5年を超えないもの(同法、施行規則第6条)とされており、認定以外の認証業務においても、署名に用いる証明書の有効期間の基準とされている。なお、認証局同士が連携して信用関係を構築することがある。階層型の信用関係の場合、上位の認証局が下位の認証局の証明書を発行し、最上位の認証局(ルートCA)は自分で自分を証明する自己署名証明書を発行する。上位の認証局に証明される認証局は中間CA(IntermediateCA)と呼ばれる。

 また、署名者は秘密鍵を安全に管理する必要があるが、秘密鍵の紛失や、秘密鍵の活性化に用いるパスワードの漏洩などにより、秘密鍵が危殆化(本人性の証明に使えなくなる状態)する可能性がある。その場合、署名者は認証局に失効申請を行い、これを受けた認証局は無効となった証明書のシリアル番号を記載した失効情報に認証局の電子署名を付与して開示する。この失効情報は証明書失効リスト(CRL:Certificate Revocation List)と呼ばれ、その更新頻度は失効した証明書の追加に合わせて実施される不定期な更新と、定期更新がある。

図 4.1.2-2 認証局の階層構造と公開鍵証明書

4.1.3 デジタル署名のメカニズムと基本要件

 デジタル署名の署名データは、署名対象文書に対して、署名鍵を用いて署名アルゴリズムによる所定の署名処理を施したものである。RSA 署名の場合、署名対象文書に対して、ハッシュ関数にて演算実施、得られたハッシュ値を公開鍵暗号方式により署名者の秘密鍵を用いて暗号化したものとなる。

 署名の有効性を検証する際は、署名データを署名者の公開鍵で検証処理を行う。RSA 署名の場合、公開鍵で復号して得られたハッシュ値と、署名対象文書からハッシュ演算をして得られるハッシュ値を比較し、双方のハッシュ値の一致を確認することにより、公開鍵と秘密鍵の紐付け、及び、署名対象文書が改ざんされていないことが確認できる。図 4.1.3-1 署名と署名検証(RSA 署名の場合)に RSA 署名のメカニズムを示す。

図 4.1.3-1 署名と署名検証(RSA 署名の場合)

 また、署名を実施する際には、その目的に応じ、以下の要件に留意する必要がある。

(1)署名文書の利用用途に応じた適切な証明書を用いること

 目的に応じて利用できる証明書の範囲(例、認定認証業務など)が示されている場合それに従うこと。認証局が開示する「証明書ポリシー」(Certificate Policy、以下 CP)に発行基準や用途が規定されているので、該当する認証局から署名者本人に対して発行された正当な証明書を利用する必要がある。

(2) 署名を実施する際に証明書の有効期間を越えていないこと

 証明書の有効期間は発行時点に設定されているが、電子署名を実施する時点においてこの有効期間を越えていないことが必要となる。

(3) 失効していない証明書を用いること

署名時点で失効していない証明書の秘密鍵を用いる必要がある。

(4) 署名文書の利用期間を通じて、署名の正当性が確認可能であること。

 法定保存期間等、署名文書の真正性の維持継続が必要な期間、署名の検証を可能とする必要がある(証明書の有効期間を越えて署名検証を行う場合は、後述の AdESフォーマットなどを採用する必要がある。)。

 なお、署名に用いられるハッシュ関数や暗号アルゴリズムは、計算機関連の技術進化とともに解読のリスクが高まるため、署名の正当性確認を可能とするためには、より長い鍵、より強度の高いアルゴリズムに移行していかなければならない。

【コラム3】■署名の基本要件(4)の規定例

 国税関係書類においては、電子帳簿保存法施行規則(第 3 条第 5 項第 2 号ロ(3))にて定められ、同法取扱通達 4-26 にてその方法について解説されている。また、医療関係書類では、厚生労働省の「医療情報システムの安全管理に関するガイドライン第 5.1 版」6.12 節にて定められ、法定保存期間等の一定の期間、電子署名の検証が継続できる必要があるとされている。

4.1.4 署名データの形式

 署名データは標準規格により、署名対象のデータとそのハッシュ値を暗号化した署名値及び各種パラメータ(属性)を含めて、下図の論理構成として規定されている。

図 4.1.4-1 署名データの論理構成

 署名対象データと署名データは 1 つのファイルに統合して作成することもできるが、独立した 2 つのファイルとして作成することもできる。署名対象データと署名データの形式には、図4.1.4-2 に示されるように、以下の 3 つに大別でき、利用形態に応じて選択することができる。

図 4.1.4-2 署名対象データと署名データの形式

それぞれ、以下のような特徴がある。

(1)分離形式(Detached 型)署名対象データとは独立して、署名データを作成する形式。署名対象データの種別は問わず、あらゆるファイル形式に対して署名データが作成できる。既存アプリケーションで署名対象データを取り扱っている場合など、アプリケーション側への影響が少なくて済む。一方、署名対象データと署名データを紐付けて管理する必要がある。

(2) 包含形式(Enveloped 型)署名データの中に署名対象データを格納(内包)して作成する形式。署名対象ファイルと署名データが 1 つのファイルとなるので扱いやすい。一方、アプリケーションなどで署名対象データを利用する場合、署名データから、署名対象データを取り出す必要がある。

(3)付属フォーム(エンベロープタイプ)

 署名データが署名対象データの中に含まれる(包含)形で作成する形式。(2)と同様に 1 つのファイルを管理すればよいので扱いが容易。一方で、署名対象データのファイル形式が、電子署名をサポートしていることが必要となり、作成できるファイル形式には制限がある(例:PDFやXML など。)。

4.2 時刻の保証と長期署名フォーマット

4.2.1 時刻情報とタイムスタンプ局

 署名の要件として、署名時点での証明書の有効性が問われることとなるが、そのためには署名時刻等を保証する客観的な時刻情報が必要となる。署名を生成するコンピュータの時刻情報を使用すると、故意か否かに関わらず、正確性が保証されない。この役割を担う信頼できる第三者機関(TTP)がタイムスタンプ局(Time Stamp Authority:TSA)である。電子文書に正確な時刻情報を含むタイムスタンプトークン(TST)を付与することにより、タイムスタンプ時刻以前からその電子文書が存在していたことと、それ以降、改ざんされていないことが証明可能となる。

図 4.2.1-1 タイムスタンプ局の概要(デジタル署名方式(RFC3161)の場合)

4.2.2 長期的な署名の担保と署名の延長

 鍵や証明書には有効期間があり、法定保存期間が定められた文書を保存する場合など、有効期間を越えて、署名検証が可能であることが必要となる。その際、特に「証明書検証の継続性」に対して留意する必要がある。また通常、認証局は証明書の有効期間を越えて失効情報を公開しないことが多い。すなわち、失効情報には失効した証明書のシリアル番号が記載されているが、多くの認証局では失効情報の肥大化をさけるため、失効した証明書の有効期間が過ぎるとそれらのシリアル番号は失効情報から消去される。従って、証明書の有効期間を越えて証明書の有効性の確認ができないことがある。従って、署名検証を継続する必要がある場合は、失効情報を確保しておく必要がある。このような問題を解決するために、電子署名の有効性を証明書の有効期間や失効、さらに、署名に用いた暗号アルゴリズムが脆弱化した後も維持できる署名規格として、AdES (先進電子署名)がある。このフォーマットに示されるように、証明書検証に必要な失効情報等のデータを合わせて保存し、タイムスタンプを付与することが有効である。その手順の概要は、以下となる。

(1) 署名対象データ全体に対して電子署名を付与

(2) 署名直後にタイムスタンプ(署名タイムスタンプ)を付与し、署名時刻を特定しておく

(3) 証明書検証に必要となる、以下の検証情報を収集格納する。なお、証明書チェーン上の認証局は、署名者の証明書を発行する認証局とタイムスタンプ局に証明書を発行する認証局の 2 つの認証ドメインにおける全ての認証局となることに留意されたい。

・タイムスタンプ局の証明書・署名者の証明書

証明書チェーン上の認証局の証明書

・上記全ての認証局の失効情報

(4) 上記の署名対象文書や署名値、検証情報全体に対してタイムスタンプ(アーカイブタイムスタンプ)を付与

図 4.2.2-1 長期署名フォーマットによる署名延長に上記手順のフローイメージを示す。ここで、各タイムスタンプの役割は、以下である。

・ 署名タイムスタンプ

署名が存在した時刻を特定可能にするために、署名値に付与されるタイムスタンプ

・ アーカイブタイムスタンプ

 暗号アルゴリズムの危殆化、認証局の変更、証明書の期限切れや失効があったとしても将来検証できるように、署名対象及び検証情報を包括的に保護するためのタイムスタンプ。署名の検証可能な期間を延長するために使用する。

・ コンテントタイムスタンプ(オプション)

 署名対象データそのものに対して、オプションで付与可能なタイムスタンプ。署名タイムスタンプは、署名時点以降の署名対象データの存在証明となるが、コンテントタイムスタンプは署名タイムスタンプより前に行い、署名対象データが「いつから」存在したのかを示すことができる。

・ ドキュメントタイムスタンプ

 PAdES に用いることができる DocTimeStamp で指定される汎用的なタイムスタンプのための PDF フィールドであり、PDF 文書に対してデジタル署名をせずに直接行うタイムスタンプ、署名タイムスタンプ、アーカイブタイムスタンプの 3 つの用途に用いることができる。どの用途であるかは、データのコンテキストで判断する必要がある。PAdES では、署名と署名タイムスタンプを CAdES-T 形式でも与えることができ、その場合は、署名タイムスタンプ用途のドキュメントタイムスタンプは使用しない。

図 4.2.2-1 長期署名フォーマットによる署名延長

 署名検証に必要となる情報には、署名対象データと署名値以外に、関連する証明書や失効情報、また、署名文書の利用目的に応じたトラストアンカーの制限や暗号アルゴリズムの有効性に関する情報などの様々な情報が必要となる。これら、署名検証に必要となる前提条件のことを、検証制約(Validation constraints)と呼び、以下のようなものが挙げられる(5.2 参照)。

・ 署名文書の利用目的に合致した証明書を発行する認証局のトラストアンカー

・ 証明書パスに含まれる全ての証明書、証明書の利用用途などの制約

・ 失効情報

・ タイムスタンプ

・ 検証基準時刻

・ 有効と認められる暗号アルゴリズムの制約

・ 署名データを構成する要素に対する制約

4.2.3 AdES フォーマット

 AdES では前述のとおり、署名の後、署名時刻を確定するため署名タイムスタンプを付し、その後、署名及びタイムスタンプが失効していないことを示す検証情報を付加し、期限切れ等で失効する前にアーカイブ用のタイムスタンプを付す。さらに期限切れ等が発生する前に、検証情報を付加してアーカイブタイムスタンプを重ねるライフサイクルとなる。

図 4.2.3-1 署名データのライフサイクル

各フェーズにおけるデータフォーマットの論理的な構成は以下のとおりである。

  • 署名者による署名を付した署名データ(AdES-BES)

図 4.2.3-2 署名者による署名(AdES-BES)

(2)署名タイムスタンプを付した署名データ(AdES-T)

図 4.2.3-3 署名タイムスタンプ付き署名(AdES-T)

(3)検証情報を付加した署名データ(AdES-X-Long)

図 4.2.3-4 検証情報付き署名(AdES-X-Long)

 AdES-X-Long はアーカイブタイムスタンプを付与する前段として、必要な検証情報が付与された状態である。ここでAdES-X-Long の検証情報は、タイムスタンプを付していないデータのため、改ざんの危険性がある。通常は、速やかにアーカイブタイムスタンプを付与するか、用途に従った処理を行うことになる。

【コラム4】■電子処方箋における AdES-X-Long の利用

2 018 年 7 月に厚労省から公開された「電子処方箋 CDA 記述仕様 第1版(平成 30 年7 月)」に基づき、JAHIS(一般社団法人保健医療福祉情報システム工業会)では電子処方箋実装ガイドを定めている。その規約においては、処方を行った医師が電子処方箋に署名を付与した後、処方箋と医師の署名の両者を署名対象に含めた文書全体に対して調剤を行った薬剤師が署名を付与することとしている。この際、医師の署名を XAdES-X-Long の形式とした上で薬剤師が署名を付すことにより、医師の署名の検証情報を保存可能としている。

(4) アーカイブ用のタイムスタンプを付した署名データ(AdES-A)

(5) 2 回目のアーカイブ用タイムスタンプを付した署名データ(AdES-A)

また、AdES フォーマットは、署名対象ファイル種別に応じて以下の種類が規定されている。

■CadES

 汎用的な署名ファイル形式であるCMS(Cryptographic Message Syntax)をベースとしたAdES。署名対象データのファイルの形式は限定されないため、広く様々なファイルへ電子署名を付与できる。分離形式、内包形式の電子署名に用いられる。

■XAdESXML

 ファイルを対象とした電子署名形式であるXML署名をベースとするAdES。分離形式、内包形式、包含形式の全てに用いることができる。

■PAdESPDF

  ファイルの内部構造の中へ署名データを埋め込む包含形式のAdES。署名対象ファイルはPDF 形式に限定されるが、署名された PDF ファイルを単独で扱うことができ、Adobe®Reader®でも検証できる利点がある。

5 デジタル署名の検証

5.1 署名検証の概念モデル

5.1.1 署名検証の基本要件

 署名検証の基本要件は、署名の基本要件に対応して、署名の本人性と非改ざん性を確認することとなる。前者は「証明書検証」、後者は「署名値の検証」と定義され、前者は署名の基本要件である(1)~(4)を適切に確認し、後者は署名対象データの署名値を公開鍵で検証処理することで確認する。ここで署名検証はデジタル署名を付与し、一定期間経過した後に行われる行為であることに着目してみると、いつ時点における署名の有効性を確認するのかその時刻の設定によっては、証明書の失効や暗号アルゴリズムの脆弱化などの要因により、検証結果に影響を及ぼすことが考えられる。

 いつ時点における署名の有効性を検証するのか、本書ではその時刻を「検証基準時刻(validation reference time)」と定義している(5.2.7 参照)。例えば本来の署名検証の目的は署名時点における電子署名の有効性を確認することにあるので、検証基準時刻は“署名を付与した時点”とすることが理想であるが、通常、署名を付与した時刻を客観的に証明することができない。そこで、検証基準時刻はタイムスタンプを併用するなどによる客観的な署名の時刻となり、それが確認できない場合は、署名検証を実施する現在時刻となる。

証明書検証に際しては電子署名の基本要件で述べた以下の 4 点を確認することになる。

(1) 署名文書の利用用途に応じた適切な証明書を用いていたこと

(2) 署名当時に証明書の有効期間が切れていなかったこと

(3) 失効していない証明書を用いて署名していたこと

(4) 署名文書の利用期間を通じて、上記(1)~(3)が確認可能であること。図 5.1.1-1 では、(1)から(3)を図示しているが、(1)及び、(2)に関して、署名時刻がいつであったのか客観的に示すためにタイムスタンプが利用されること、また署名時点での証明書の有効性を確認するために失効情報が保管されることが必要である。

5.1.2 検証のアプリケーションモデル

 署名データの検証処理の実装には、PCやデバイス等で実行されるグラフィカルユーザインタフェースを備えたソフトウェアや、コマンドラインツール、他のアプリケーションに組み込まれるライブラリやミドルウェア、WebアプリケーションやWeb サービスなど様々な方法が考えられる。そのような様々な実装を概念的なモデルとして表現するために、この規格では駆動アプリケーション(DA:Driving Application)と署名検証アプリケーション(SVA:SignatureValidation Application)に分けて考える(図 5.1.2-1)。

 署名検証アプリケーションとは、入力された署名データの検証を行い、署名データの判定結果やレポート内容を出力するモジュールのことを言う。署名検証アプリケーションは、駆動アプリケーションから入力された署名データを検証し、検証レポートを駆動アプリケーションに返す。駆動アプリケーションは検証レポートに基づいて検証者に検証結果の表示を行う。ソフトウェアの構成によっては駆動アプリケーションと署名検証アプリケーションが一体となっている場合もある。本書では署名検証アプリケーションが実行すべき署名データの検証項目に関する要件を定めるものとする。

図 5.1.2-1 署名検証アプリケーションの概念モデル

 検証レポートには署名データの判定結果や詳細なレポート内容が含まれる。検証制約は署名検証アプリケーションが署名データの有効性を判断するときの条件を示すものである。検証制約には、例えば、検証者が信頼するトラストアンカー、証明書の検証情報(中間CA証明書や失効情報)、証明書ポリシーや暗号制約などがある。検証制約は駆動アプリケーションを介して検証者が設定できる場合や、署名ポリシー等の記述に従い駆動アプリケーションが署名検証アプリケーションに入力する場合や、署名検証アプリケーションや駆動アプリケーションのコードに組み込まれている場合もある。証明書の検証情報については検証処理の実行時にオンラインで取得する場合もある。

5.1.3 署名判定結果の概念モデル

署名データの判定結果には以下の種類がある。

● VALID (有効)

 署名者による署名やタイムスタンプの対象となったデータの改ざんがなく、かつ、署名者やタイムスタンプを発行したタイムスタンプ局の身元が信頼できると判断された状態。検証すべき項目の全てがVALID であるとき、署名データ全体をVALID と判定する。VALID である署名データは少なくとも以下の全ての内容を満たしている。

➢ 署名者による署名やタイムスタンプのハッシュ値や署名値が正しく検証できること。

➢ 署名者の証明書やタイムスタンプ局の証明書が信頼できること。例えば、信頼する認証局から発行されていることや、有効期間内にあること、失効されていないこと等。

● INVALID (無効)

 検証すべき項目のうち少なくとも1 つが INVALID と判断された場合、署名データ全体をINVALID と判定する。

● INDETERMINATE (未確定)

 入手された情報による設定では VALID もしくはINVALIDと判定するには不十分である。例えば、署名検証アプリケーションの実行時に検証に必要な失効情報を入手できず、証明書の失効状態を確認することができなかった場合には、INDETERMINATE として判定される。INDETERMINATE と判定された署名データは、他の証拠となる情報と照らし合わせた場合に、VALID もしくは INVALID として判定することもできる。

 なお、検証すべき項目に1つでも INVALID があれば、全体として INVALIDであり、処理を終了できる。しかし、他にも INVALIDの項目が存在する可能性があり、どこに問題があったかを知ることは検証として有用なことがあるため、検証処理を継続することは意味がある。逆にINVALID の結果からは、他にINVALID の項目がなかったのか、処理を打ち切ったかが分からないため、どちらの実装であるかを供給者の適合宣言書に記して、明確にすべきである。

5.1.4 要求レベル(必須とオプション)の考え方

 本書における検証要件のレベルを以下のように定める。検証要件には、電子署名としてセキュリティを担保するために制約条件の違いなどに依存せず最低限実行しなければならないもの、用途に依存するがセキュリティを担保するためには意味があるもの、用途に依存して実行要否を決定するものに分けられ、それぞれのフィールドを、必須、存在時必須、オプションと規定する。各々の処理方法は以下とする。

・ 必須[M(Mandatory)]

 この検証項目は必ず実行しなければならない。この検証項目に必要なフィールドが署名データに存在しない場合には INVALID と判定する。

・存在時必須[E(存在する場合は必須)]の場合に存在する必要があります該当するフィールドが署名データに存在する場合には、この検証項目は必ず実行しなければならない。該当するフィールドが存在しない場合には、この検証項目をスキップしてよい。

・オプション [O(Optional)]

 この検証項目を実行するか否かはアプリケーションの要件に依存する。なお、後述の署名データの構成要素におけるM(Mandatory)/O(Optional)は、署名生成時の選択基準である(PAdES の場合は、禁止[P(Prohibited)]もある)。

 また、本書の規定を基にして、さらに用途を限定したプロファイルを策定する場合、[Optional]の検証項目を[Mandatory if Exists] 又は[Mandatory]に、[Mandatory if Exists]の検証項目を[Mandatory]に再定義することは可能とする。しかし、[Mandatory]もしくは[Mandatory if Exists]の項目はセキュリティを担保するために必要な項目であり、これらを検証しない実装は供給者の適合宣言書に記して、その制約を明確にする必要がある。

5.2 検証プロセス

5.2.1 検証プロセスの考え方

 検証は、前述のとおり、署名の検証(非改ざん性の確認)、証明書の検証(本人性の確認)、及びそれらが署名生成されてからの使用期間中、有効であったことの確認をすることである。署名の延長を考慮すると、AdESの各フォーマットに対応する必要がある。フォーマットの詳細と準拠する規約を5.3 に示す。署名を延長した場合は、検証の基準となる時刻が重要であり、各フォーマットにおける検証基準時刻の考え方を5.4に示す。検証にあたっては、署名データの要素として、署名、タイムスタンプ、証明書を検証することになる。署名について5.5 に、タイムスタンプについて5.6に、証明書について5.7に示す。

図 5.2.1-1 署名検証プロセス

 なお、実際の利用用途に応じて、署名の使い方や扱いに制約を加えることがあり、検証もその制約に対応して行う必要がある。その場合、署名検証アプリケーションには、検証対象となる署名データ(署名対象のコンテンツを含む)だけでなく、外部からの情報を参照する必要がある場合がある。また、署名利用分野の必要に応じて検証結果を規約で定める規定値と異なる値としたい場合、差分を制約条件として与えることが考えられる。これらの情報を総称して検証制約と呼ぶ。検証制約の与え方としては次の方法が考えられる。

– 署名ポリシー([i.2][i.3][i.4]準拠)

– 設定ファイル(独自形式)

– 実装ロジックへの埋め込み

次項以降に検証制約とその関連情報を示す。

5.2.2 トラストアンカー署名

 データに検証情報としてルート証明書が含まれる場合がある。ところが、署名データに含まれていることを根拠にルート証明書を署名(タイムスタンプ、失効情報を含む)検証時に信頼できると、あるいは過去の署名生成時に信頼していたと判断することはできない。従って、信頼点については現在のもの/過去のものを問わず、検証処理に外部から与える必要がある。なお、欧州では認証局や各種サービスの情報を公的に一覧として整備し、確認できるようにした Trusted List がある。

5.2.3 証明書

 署名データにトラストアンカーにいたる認証パス上の証明書のセットが含まれる場合とそうでない場合がある。含まれない場合、署名検証アプリケーションに外部から与える必要がある。認証パスが複数存在する場合、通るべきパスに制限を加える必要がある場合がある。このような場合、検証処理に外部から制約条件を与える必要がある。また、証明書内の要素に対して既定値ではオプショナルなものを検証する必要がある場合や、その要素の値がある条件を満たす必要がある場合がある。このような場合も、それらの条件を検証処理に外部から制約として与える必要がある。

5.2.4 失効情報

 有効期限が切れていない証明書の失効状態を確認するために、失効情報を署名検証アプリケーションに外部から与える必要がある。署名データ(タイムスタンプ含む)に検証情報として失効情報が含まれる場合があり、それが対象となる署名データ(タイムスタンプ含む)の失効情報として適切なとき(検証基準時刻の観点から適切なタイミングに発行されているとき)にはそれを利用することができる。適切な(すなわち、検証に利用が許容される)タイミングとしては、署名やタイムスタンプ生成後、猶予期間を経ていること、次のタイムスタンプ付与又は検証の時点で、失効情報の発行周期以内で最も新しい(鮮度が高い)ものであることが求められる(詳細は 5.4 を参照)。なお、実際には、ルートCA や中間CAの失効情報、OCSPのタイミングなど、状況に応じて考慮が必要となる。

5.2.5 暗号アルゴリズムの脆弱性に関する情報

 署名データ(証明書、失効情報、タイムスタンプ等を含む)の生成には各種暗号アルゴリズムが用いられ、その種別はOID等で署名データに含まれる。ところが、各暗号アルゴリズムが利用された時点で脆弱でなかったことを示す根拠は署名データには含まれない。従って、各暗号アルゴリズムが利用された時点で脆弱でなかったことを確認するためには外部の情報を参照する必要がある。実際には、暗号アルゴリズムの利用箇所は多岐にわたるとともに、その安全性の基準等が明確でないため、何らかの制約を設けない限り確認は困難となる。その課題と解決策案は「付属書 C」に述べる。

5.2.6 タイムスタンプ

 適用領域や法制度の要請等により、信頼すべきタイムスタンプを選別する必要がある場合がある。信頼すべきタイムスタンプであるか否かを判断するために、タイムスタンプトークンに含まれるタイムスタンプポリシー、発行者、信頼点、精度等の要素に関する制約を外部から与える必要がある場合がある。

5.2.7 検証基準時刻(validation reference time)

 証明書の有効性や暗号アルゴリズムの非脆弱性を判断する際に基準とする時刻(検証基準時刻と呼ぶ)は検証対象により適切に選ぶ必要がある。対象となる証明書についての検証基準時刻は、その証明書をタイムスタンプ対象(MessageImprint)の計算対象に含む有効なタイムスタンプトークンのうち、最も古いものの示す時刻であり、該当するタイムスタンプがない場合、検証処理を実行する時刻となり、検証処理に外部から与える必要がある。また、暗号アルゴリズムについての検証基準時刻は、対象となる暗号アルゴリズムにより計算された結果を MessageImprint の計算対象に含む有効なタイムスタンプトークンのうち、最も古いものの示す時刻であり、該当するタイムスタンプがない場合、検証処理を実行する時刻となり、検証処理に外部から与える必要がある。検証基準時刻における検証の考え方を整理すると、以下となる。

• 署名、コンテントタイムスタンプ

・ 署名タイムスタンプがなければ現在時刻で検証

・ 署名タイムスタンプがあればその時刻で検証

• 署名タイムスタンプ

・ アーカイブタイムスタンプがなければ現在時刻で検証

・ アーカイブタイムスタンプがあれば最も古いアーカイブタイムスタンプの時刻で検証• アーカイブタイムスタンプ群・ 自分より新しいアーカイブタイムスタンプがなければ、現在時刻でそのアーカイブタイムスタンプを検証

・自分より新しいアーカイブタイムスタンプがあれば、その直後のアーカイブタイムスタンプの時刻で検証

5.2.8 署名要素に対する制約

 適用領域や法制度等の要請により、署名データを構成する各種要素について、規約において検証必須として規定されている要素の検証を不要としたり、逆に検証オプションとして規定されている要素の検証を必須としたりする場合がある。このようなときに外部より検証制約としてそれらの条件を指定することができる。ただし、本書で必須と規定している要素の検証を不要とすることは、安全性の観点から望ましくない。

5.3 検証データの全体構造

 この節では署名データの各形式における論理的な構成と各要素の検証方法が記述された節への参照関係について述べる。

5.3.1署名者による署名(AdES-BES)

 署名者による署名(AdES-BES)は署名者による署名のみが付与された基本的な形式である。AdES-BES の論理的な構造と、検証要件の各節との関係を図 5.3.1-1 に示す。AdES-BES の仕様が記述された各規格の一覧を表 5.3.1-1 に示す。

5.3.2 署名タイムスタンプ付き署名(AdES-T)

 署名タイムスタンプ付き署名(AdES-T)は署名者による署名(AdES-BES) とともに署名タイムスタンプを付与した形式である。AdES-T の論理的な構造と、検証要件の各節との関係を図5.3.2-1に示す。AdES-T の仕様が記述された各規格の一覧を表5.3.2-1に示す。

5.3.3 検証情報付き署名(AdES-X-Long)

 検証情報付き署名(AdES-X-Long)は、署名タイムスタンプ付き署名(AdES-T)に検証情報を格納した形式である。検証情報(証明書チェーン、OCSP レスポンス及びCRL 等)を格納することにより、認証局が存在しなくなったとしても検証情報付き署名単独で署名や署名タイムスタンプの検証を行うことができる。AdES-X-Long 論理的な構造と、検証要件の各節との関係を図5.3.3-1 に示す。AdES-X-Longの仕様が記述された各規格の一覧を表5.3.3-1に示す。

5.3.4 アーカイブ付き署名(AdES-A)

 アーカイブ付き署名(AdES-A)は検証情報付き署名(AdES-X-Long)にアーカイブ用のタイムスタンプ(アーカイブタイムスタンプ、LongTermValidation タイムスタンプ、ドキュメントタイムスタンプ)を格納した形式である。AdES-A の論理的な構造と、検証要件の各節との関係を図5.3.4-1 に示す。AdES-A の仕様が記述された各規格の一覧を表5.3.4-1 に示す。

5.4 検証基準時刻と検証の観点

 署名データの有効性を判断する場合、署名やタイムスタンプ、証明書などの有効性を確認するときの基準となる時刻(検証基準時刻)が重要である。特に、長期保存の場合には複数のタイムスタンプが用いられていることで時刻の関係が複雑となり、不適切な検証基準時刻での検証を行った場合には、不正に生成された署名データを受け入れてしまう危険性もある。この節では、検証対象と検証基準時刻の関係を示す。

5.4.1 AdES-BES 検証における検証基準時刻と検証の観点

 AdES-BES の生成プロセスと検証プロセスの関係を図5.4.1-1図5.4.1-1 に示す。図 5.4.1-1の時間軸に沿って生成プロセスと生成されるデータ、検証プロセスを示している。AdES-BESでは署名生成時刻が保証されないため、検証者が検証を行う時刻に基づき有効性を判断する。AdES-BES 検証における検証基準時刻の考え方と有効性を判断すべき項目を表5.4.1-1に示す。

5.4.2 AdES-T 検証における検証基準時刻と検証の観点

 AdES-T の生成プロセスと検証プロセスの関係を図 5.4.2-1 に示す。図 5.4.2-1 の時間軸に沿って生成プロセスと生成されるデータ、検証プロセスを示している。AdES-T 検証における検証基準時刻の考え方と有効性を判断すべき項目を表 5.4.2-1 に示す。

5.4.3 AdES-X-Long 検証における検証基準時刻と検証の観点

 AdES-X-Long の生成プロセスと検証プロセスの関係を図 5.4.2-1 に示す。図 5.4.2-1 の時間軸に沿って生成プロセスと生成されるデータ、検証プロセスを示している。AdES-X-Long 検証における検証基準時刻の考え方と有効性を判断すべき項目を表 5.4.2-1 に示す。AdES-X-Long は署名データ内に格納された証明書や失効情報を用いて検証を行うことができる。AdES-X-Long は署名タイムスタンプ付き署名(AdES-T)の検証基準時刻と同様に考える。なお、生成から時間が経過し、格納された検証情報の改ざんの危険性がある場合にはこれをアーカイブ付き署名等に利用することはできない。

5.4.4 AdES-A検証における検証基準時刻と検証の観点

5.5 署名の検証要件

 もしES がアーカイブ情報を有している場合には、検証基準時刻として最も古いタイムスタンプ時刻を利用する。それ以外の場合には、検証基準時刻として有効な検証時刻又は現在時刻を利用する。詳しくは 5.4 を参照。

5.5.1 アルゴリズムの有効性の確認

 検証制約により、検証基準時刻において利用している暗号アルゴリズムの脆弱性が見つかっておらず有効であることを確認する。

5.5.2 CAdES の検証要件

CAdES 署名は、検証基準時刻において次の検証要件に従い検証する。

5.5.3 XAdES の検証要件

XAdES 署名は、検証基準時刻において次の検証要件に従い検証する。

【コラム5】■XAdES バージョン定義と規格

 XAdESのバージョンは XML 名前空間(namespace)で指定され、その定義は ETSI TS 101903 となる。2002 年 2 月に ETSI TS 101 903 V1.1.1が公開された後で、V1.2.2、V1.3.2、V1.4.1 と合計 4 つのバージョンがある。このうちV1.1.1とV1.2.2は、V1.3.2 以降との互換性が無い為に利用してはいけない。V1.4.1は V1.3.2 がベースとなり、追加要素を加えたものである。その為に V1.4.1を利用する場合に正確にはV1.4.1+V1.3.2の要素が必要となる。ETSI TS101903 以外の規格ではどのXAdES バージョンを利用しているかをよく理解して利用する必要がある。特にW3C NoteはV1.1.1のままであり使ってはいけない。ETSI EN319 132-1 V1.1.0 (2016-04) がETSI 最新の仕様ではあるが、XAdES バージョンとしてはV1.4.1である。

【コラム6】■XAdESのSigningCertificate要素とSigningCertificateV2 要素

 XAdESのSigningCertificateV2 要素は ETSI EN 319 132-1 V1.1.0 (2016-04) から追加された新しい要素であるが名前空間は V1.3.2 となっている。これは SigningCertificateV2要素が、ETSI TS 101 903 V1.3.2 (2006-03) で定義されていた SigningCertificate 要素をそのまま置き換える目的の為に追加された要素であるからである。従来の IssuerSerial 要素下の X509IssuerName 要素では、署名証明書(X.509バイナリ)のIssuer 部からテキスト形式(RFC 2253 準拠)に変換した識別名を利用していた。しかしながら色々な事情がありこの識別名が一意にならない問題があった。この為にSigningCertificate/IssuerSerial/X509IssuerName を使った検証を行わない検証器がほとんどであった。SigningCertificateV2 要素では新たに IssuerSerialV2 要素として、Issuer と Serial を、署名証明書(X.509 バイナリ)からバイナリ(ASN.1/DER)のまま抜き出して結合する方式となった。これにより SigningCertificateV2 要素を使うことで Issuer(発行者)名が一意となるので間違いなく検証が出来るようになった。以上から過去互換性の為に SigningCertificate 要素を使い続けることに問題は無いが、新しく実装する場合には SigningCertificateV2 要素が推奨される。

【コラム7】■PDF バージョンと電子署名

 PDFのバージョンは現在1.0~2.0までが存在する。1.0~1.7までは Adobe 社が策定して仕様公開していたがその後 ISO に移管され、ISO 32000-1 で PDF1.7が正式仕様となり、ISO32000-2でPDF2.0が正式仕様となった。なお PDF 電子署名の仕様は PDF1.3 で追加された。PDF ファイルではファイルの先頭に PDF バージョンが埋め込まれているが、残念ながらファイル本体の仕様と一致しない場合が多い。PAdES 仕様は PDF2.0(ISO 32000-2)で追加されたが、ファイルの先頭で宣言されるバージョンは PDF1.7 以前の場合もあるが、これは検証エラーの対象とはならない。PAdES 仕様が ETSI で定義された時には、PDF1.7(ISO 32000-1)をベースとして PAdES 用の新しい仕様を追加したものとなっている。ETSI TS 102 778-1 V1.1.1 と ETSI EN 319142-1 V1.1.1 はいずれもPDF1.7プラス PAdES 仕様となっている。その後 PDF2.0(ISO 32000-2)が発行された時に PAdES 仕様も PDF2.0 として吸収された。

5.6 タイムスタンプの検証要件

5.6.1 タイムスタンプ

 タイムスタンプは、次の検証要件に従い検証する。ここに示す検証要件は、RFC 5280 X.509証明書インターネットプロファイル、RFC 5652 CMS、RFC 3161 タイムスタンププロトコルに準じた検証内容であり、本書に固有の検証要件はない。

5.6.2 署名タイムスタンプ

(1) 署名タイムスタンプの検証基準時刻

 もし電子署名がアーカイブ情報を有している場合には、検証基準時刻として最も古いタイムスタンプ時刻を利用する。それ以外の場合には、検証基準時刻として有効な検証時刻又は現在時刻を利用する。詳しくは 5.4 を参照。

  • 署名タイムスタンプの検証要件

署名タイムスタンプを、検証基準時刻において次の検証要件に従い検証する。

5.6.4 ドキュメントタイムスタンプ

 ドキュメントタイムスタンプは PDF のようなドキュメントに対してタイムスタンプのみを署名とは別に付与する方式のタイムスタンプである。執筆時点においてはPAdESの DocTimeStamp(PAdES-DT)仕様のみとなる。PAdES の DocTimeStamp は、PAdES-T や PAdES-A では署名タイムスタンプ的にもアーカイブタイムスタンプ的としても利用が可能である。ここでは署名抜きでドキュメントタイムスタンプを利用する PAdES-DT 仕様(ISO 14533-3 Annex B.2)について解説する。PAdES-DT 仕様も長期署名化(LTA 化)による有効期限の延長が可能となっている。CAdES 署名の代わりに DocTimeStamp のみを指定した後で、DSS/VRI 辞書とアーカイブタイムスタンプとしての DocTimeStamp を追加することで長期署名化が可能となる。DocTimeStamp 署名辞書とDSS/VRI 辞書に関しては「5.5.4 PAdES の検証要件」を参照。

5.7 証明書の検証要件

 署名やタイムスタンプの検証では署名値の検証で利用する証明書の検証を行う必要がある。証明書を検証するには、トラストアンカーとなるルート証明書までの証明書パスを辿り、有効期限、失効確認、証明書や CRL の拡張領域などを確認する必要がある。また、それらを確認するときに利用する検証基準時刻は署名フォーマット形式(AdES-BES、AdES-T、AdES-A)ごとに異なり、署名者証明書、TSA 証明書それぞれにおける検証要件も異なる。なお、署名者証明書及び TSA 証明書の検証で利用する情報は次のとおりである。

・ 署名者証明書もしくはTSA証明書

・トラストアンカーを含む証明書及び失効情報のセット

・制約条件

以下に、証明書検証の検証要件及び検証基準時刻について署名フォーマット形式ごとに解説する。本節で用いる記号の意味は以下のとおりである。

Tv:検証処理を実行した時刻

Ts:署名タイムスタンプの時刻

Ta(k):第 k 世代のアーカイブ(ドキュメント)タイムスタンプの時刻

5.7.1 AdES-BES における証明書

日司連公的個人認証有効性確認システムを使ってみました。

PDF文書に、Acrobat DC / Acrobat Reader DCを利用してマイナンバーカードで電子署名をしてみました。

2021年(令和03年)02月15日、日司連公的個人認証有効確認システムが構築されたようなので、試しに利用してみました。

下の事が出来るようです。

・司法書士が依頼者のマイナンバーカードの有効性を確認できる。

・登記申請の際の添付情報等に付された電子証明書が,依頼者のマイナンバーカードの電子証明書と一致しているか即時に司法書士が確認できる。

ログイン画面

https://www.nkys.nisshiren.jp/

まずは、個人会員ログインをしてみます。

・個人会員ログインをクリック

・ID・初期パスワード・メールアドレスを登録すると、次のメールが送られてきます。

・「こちらからアクセスしてください」をクリックして、パスワードを自身で再設定。

・「暗証番号を送信」をクリック。

・暗証番号を入力してログイン。

・マイナンバーカードの有効性確認と、情報に付された電子証明書が,マイナンバーカードの電子証明書と一致しているか確認出来る画面に切り替わりました。

一旦、日司連公的個人認証有効性確認システムの画面に戻って、スマートフォンからマイナンバーカードの電子証明書を読み取ります。

・QRコードを読み込みます。

・スマートフォンアプリケーションが表示されたので、マイナンバーカードの読み取りをします。

ここで私が何度も間違ったこと。マイナンバーカードをアプリケーションに認識させた後、署名用パスワードを入力するのですが、3回も4回も「PINコードが違います」のエラー表示が出てきます。ヘルプデスクに問い合わせました。

最初は、アプリケーションを再インストール(削除して,再度入れなおす)すると改善する可能性があります。とのメールが届きました。

 アプリケーションを再インストールしても、「PINコードが違います」のエラー表示が出てきます。そこでヘルプデスクさんが教えてくれたのが、総務省のページです。

「パスワード入力から読み取り完了までスマートフォンとマイナンバーカードをピッタリあて続けてください」。これをしていなかったのです。私は、スマートフォンがマイナンバーカードを認識した後、マイナンバーカードを外して署名用パスワードを入力していました。「ピッタリ」あて続けた結果、読み取りが完了しました。

マイナンバーカードの有効性を確認してみます。

次は、PDFファイルの文書に、マイナンバーカードを利用してPDF文書に、Acrobat DC / Acrobat Reader DCを利用してマイナンバーカードで電子署名をしてみます。

参考

PDF ファイルで電子署名を利用する方法

https://helpx.adobe.com/jp/acrobat/kb/cq07131410.html

・ファイル/その他の形式で保存/証明済み PDF を選択。

・ツール/証明書/電子署名 を選択。

・署名フィールドをクリック。

・署名に使用するデジタル ID の設定

・署名のプロパティを表示。

公的個人認証サービス  ポータルサイト

署名用認証局の運営に関する情報

https://www.jpki.go.jp/ca/ca_rules3.html

隂山克典「司法書士実務における電子署名の留意点」

 月報司法書士[1]の記事からです。電子化の流れに付いていけるように、考えてみたいと思います。

電子署名の類型

当事者署名型電子署名

 「当事者署名型」がマイナンバーカードや電子ファイルを利用して署名するもの、ということは知っていましたが、何で当事者署名型、と呼ばれているのでしょうか。法令では、当事者署名型という用語を探すことは出来ませんでした。いつから使われるようになったのかも私には探すことが出来ませんでした。おそらく事業者署名型電子署名のサービスが登場するときに当事者署名型電子署名という用語が作られたのではないでしょうか。

下の法令を読むと、当事者署名型電子署名が原則だと考えられます。

・電子署名をする人(個人、法人の代表者)がいる。

・電子署名をした情報については、変更できないように設定され、それが確認出来るようになっていること。

電子署名及び認証業務に関する法律

(定義)

第二条 この法律において「電子署名」とは、電磁的記録(電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られる記録であって、電子計算機による情報処理の用に供されるものをいう。以下同じ。)に記録することができる情報について行われる措置であって、次の要件のいずれにも該当するものをいう。

一 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。

二 当該情報について改変が行われていないかどうかを確認することができるものであること。

電子署名及び認証業務に関する法律施行規則

(利用者の真偽の確認の方法)

第五条 法第六条第一項第二号の主務省令で定める方法は、次に掲げる方法とする。

一 認証業務の利用の申込みをする者(以下「利用申込者」という。)に対し、住民基本台帳法(昭和四十二年法律第八十一号)第十二条第一項に規定する住民票の写し若しくは住民票記載事項証明書、戸籍の謄本若しくは抄本(現住所の記載がある証明書の提示又は提出を求める場合に限る。)若しくは領事官(領事官の職務を行う大使館若しくは公使館の長又はその事務を代理する者を含む。)の在留証明又はこれらに準ずるものとして主務大臣が告示で定める書類の提出を求め、かつ、次に掲げる方法のうちいずれか一以上のものにより、当該利用申込者の真偽の確認を行う方法。ただし、認証業務の利用の申込み又はハに規定する申込みの事実の有無を照会する文書の受取りを代理人が行うことを認めた認証業務を実施する場合においては、当該代理人に対し、その権限を証する利用申込者本人の署名及び押印(押印した印鑑に係る印鑑登録証明書が添付されている場合に限る。)がある委任状(利用申込者本人が国外に居住する場合においては、これに準ずるもの)の提出を求め、かつ、次に掲げる方法のうちいずれか一以上のものにより、当該代理人の真偽の確認を行うものとする。

参考

・本人確認の意味とリスクの高低による本人確認方法。身元確認と当人認証の違い。司法書士にとって、リスクが低いのは金融機関が設定した担保権の抹消登記申請の業務などでしょうか。一部業務を除くと、司法書士が行う業務は全てリスクが高いと考えられます。

オンラインサービスにおける身元確認手法の整理に関する検討報告書(概要版)

2020年4月17日

https://www.meti.go.jp/press/2020/04/20200417002/20200417002.html

事業者署名型電子署名

まずは、2020年に公表されたQ&Aです。

利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A(電子署名法2条1項に関するQ&A)

令和2年7月 17 日

総務省 法務省 経済産業省

https://www.meti.go.jp/covid-19/denshishomei_qa.html

https://www.meti.go.jp/covid-19/pdf/denshishomei_qa.pdf

利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A(電子署名法3条に関するQ&A)

令和2年9月4日

総務省  法務省  経済産業省

https://www.meti.go.jp/covid-19/denshishomei3_qa.html

 私がよく聞くのは、クラウド型電子署名です。要件の一つとして、サービス提供事業者の意思が介在する余地がなく、利用者の意思のみに基づいて機械的に暗号化されたもの、があります。立会人として電子情報の存在を確認した、というのは意思の介在が観念できるか、という問いが立てられています。事業者は電子情報(と電子署名)の存在を確認しないと仕事が完成しないので、その過程を意思の介在と捉えられると、事業者署名型電子署名という業務は成立しないのかなと感じます。Q&Aにも、「電子文書について行われた当該措置が利用者の意思に基づいていることが明らかになる場合には、これらを全体として1つの措置と捉え直すことにより」と記載されており、利用者の意思のみにより事業者によって電子署名が行われれば、これらの過程を1つの措置として捉え直すとされています。

参考

オンラインによる本人確認

平成30年改正犯罪収益移転防止法施行規則(平成30年11月30日公布)に関する資料

https://www.npa.go.jp/sosikihanzai/jafic/hourei/law_com_24.htm

電子署名の検証

司法書士が依頼者の電子署名の検証を行う場合・・・日司連公的個人認証有効性確認システム

https://www.nkys.nisshiren.jp/login/individual

本人性の確認・・・電子署名が付与されたとき、付与された情報を受け取ったときに検証。

・電子証明書の発行主体が正当な認証局

・有効期間が切れていない

・失効していない

署名値の検証

・「【氏名】によって押印されました」

・署名パネルの表示確認

電子署名の有効性検証の継続

 たとえば、電子署名が付与された情報を受け取って登記申請までに期間がある場合。

電子契約システム活用の際の留意点は、私が気付かないことばかりでした。

長期署名対応、認定タイムスタンプ局、アーカイブスタンプ、種類の違う電子署名付与の順序、国際規格への対応などです。


[1] 2021.2 №588 P38~