お詫び：この記事は３月に書き始め、５月に大方できていたのですが、なんかボリューム満点な割に、落とし所がなくなってしまい、辛くなって放置していました。これが終わらないせいで、他の記事も何となく書くのが億劫になっていました。やっと８月末の今日、少し書き足して生煮え記事として供養させてくださいm(_ _)m。ただここで言いたいのは
(電子証明書方式の)電子委任状は、お役所への申請だけでなく、企業間の電子契約でも、前より格段に使いやすい証明書なので「ちゃんと普及してください！！！」
ってことだけです。
今日は正確には証明書ハンターネタとは言えないんですが、今後おもしろそうな、「電子委任状」という証明書が出てきそうってことで紹介したいと思います。ちょっと長いです。ご容赦ください。
もくじ
1. 電子委任状とは
2. 証明書の識別名の構造(おさらい)
3. デジタル証明書形式の電子委任状のサンプル発行
4. 汎用の証明書ビューアーで主体者別名の表示は問題ないか
4.1. Windowsの表示
4.2. macOSの表示
4.3. Firefoxの表示
4.4. Adobe Acrobat Reader DCの表示
4.5. Java JCE SUNプロバイダの表示
4.6. Java JCE BouncyCastle BCプロバイダの表示
4.7. OpenSSLのx509 -textコマンドによる表示
4.8. 表示結果サマリ
5. 電子委任状の識別名に関する考察
5.1. 属性タイプについて
5.2. organizationIdentifier属性タイプについて
5.3. description属性タイプについて
5.4. OUを使う事の是非について
5.5. ではどの属性タイプを使うのが良かったのか
5.6. 似た日本語文字の問題
5.7. その他、記載例における細かい課題
1. 電子委任状とは
既にご覧になっている方もいるかもしれませんが、 2018年1月から「電子委任状の普及の促進に関する法律（電子委任状法）」が施行されました。
ある程度の規模以上の会社になってくると、契約や行政手続きなどで、社長さん自らそのような事務処理をすることは少ないと思いますが、ICカード使って電子署名するとか言うと本人しか暗証番号知らないはずなので困っちゃうんですよね。パソコン苦手な社長さんだと、ICカードと暗証番号毎渡しちゃって処理をお願いしたりしてね。
そこで、社長さんが決めた代理の人に対して、電子委任状なるデータを与えることによって、そのような契約や申請手続きをオフィシャルに社長の代理でできるようにして、電子化を促進しようという法律なのだそうです。
ICカードと暗証番号は、本人しか使えないように管理しなければならないというのが利用の原則なんですが、電子委任状によって、ちゃんと申請や契約する本人(=代理人)が管理するICカードができるようになるというのがミソかと思います。
そういえば先日、5月23日に日本ネットワークセキュリティ協会(JNSA)の電子署名WG春祭り「電子署名の世界(SIGN WORLD)」があり、弁護士の宮内宏先生が「個人の電子証明書と法人役職者の電子証明書 〜意外と使える電子委任状法〜」というタイトルでお話ししてくださいました。 電子委任状については、一番良い解説スライドだと思うのでみなさん見て欲しいんですが、 一番ストンと腑落ちしたのがこの電子証明書の比較に関するスライドで、マイナンバーカードも、認定認証業務の証明書も、特定認証業務の証明書も、商業登記の証明書しかり、日本の電子署名法で使える証明書は
- 基本的には会社の代表者(会長さん、社長さん)向けの証明書か、
- 個人の氏名と住所情報が入っている証明書
電子委任状の発行は、誰でも発行できるわけでなく、役所がするわけでもなく、電子委任状取扱業務の資格を持つ第三者のサービスがそれを行うことになるそうで、申請確認プロセスが同じなので、国内の証明書発行サービスが担うようになりそうとの事。電子委任状は普通のPDF(署名)文書のような形式もあるそうですが、X.509デジタル証明書による形式もあるそうです。(ココ、食いつき所ですよっ！！！)
デジタル証明書形式の電子委任状について、どのような項目を記載するか、いわゆる証明書プロファイルについては、総務省が発行している指針の解説書の25ページに記載例があります。この記載例を作る時に、総務省、日本電子認証局会議、日本ネットワークセキュリティ協会(JNSA) 電子署名WGが議論する会合がありまして、私もたまたま声をかけて頂けました。
この記載例には、幾つか課題もあるように思いますが、そこはスルーして、電子証明書方式の電子委任状のポイントは以下かと思います。
- 社長さんなど委任する側の人(委任者)と委任される人(受任者)の情報はsubjectAltName(SAN)に、 directoryNameとして記載される。
- (SAN)のdirectoryNameの属性タイプは、 O、OU、CN、ST(stateOrProvince)、L(Locality)、T(title)、description、organizationIdentifierが使われる。
- 記載内容の詳細については、定められたプリフィクスも含めて、ディレクトリ属性値に設定している。例えば、社長さんなど組織の代表者には「組織代表者名：」というプリフィクスを使って 「組織代表者名：山田太郎」のように設定している。
2. 証明書の識別名の構造(おさらい)
証明書の識別名は
属性1タイプ1=属性値1, 属性1タイプ2=属性値2, 属性1タイプ3=属性値3 ...の構造になっています。属性タイプはオブジェクト識別子(OID)で、2.5.4.10みたいなやつ、属性値はASN.1の文字列タイプ(DirectoryStringType)になります。
3. デジタル証明書形式の電子委任状のサンプル発行
趣味でjsrsasign
という、JavaScriptベースの暗号/PKIライブラリを公開していますが、
今回の調査に合わせて、この電子委任状に必要な全属性タイプのサポートを追加しましたので、
サンプルのCAページ
を使えば簡単に電子委任状もどきの証明書を生成し、証明書の表示確認などに
使うことができます。
電子委任状では主体者別名(subjectAltName)に特徴があるので、
確認ではこれのみを設定すればよく、
タイプを「DN」にし、値に以下をペーストし、
/organizationIdentifier=JCN1111111111111/O=株式会社アイツー/description=組織所在地：東京都渋谷区神宮前３−３/description=組織代表者肩書き：代表取締役社長/description=組織代表者生年月日：1972/04/27/description=組織代表者名：鈴木花子/CN=山田太郎/T=購買部長/description=部門所在地：東京都新宿区西新宿５−５/description=代理権内容：日本国内の1億円以下の購買行為/description=代表権制限：1億円以下の発注購買気になるならば、主体者名(subject)を以下に設定します。
/CN=Taro Yamada/ST=Tokyo/L=Shinjuku-ku Nishi-Shinjuku 5-5「Issue Certificate(証明書発行)」ボタンを押せば、証明書データが生成れます。 上記の入力では、主体者別名の属性タイプを選択できるものは一般的なOUではなく、表示テストのために珍しいdescriptionを使っています。また、解説書では主体者名の都道府県でS=TokyoのようにstateOrProvinceは"S="を使っていますが、OpenSSLやjsrsasignでは"ST="を使います。
上記の主体者別名の例を見やすいように改行を入れると以下のようになります。
値は、自分の名前など、自由に変更して入力してもらえれば良いかと思います。/organizationIdentifier=JCN1111111111111 /O=株式会社アイツー /description=組織所在地：東京都渋谷区神宮前３−３ /description=組織代表者肩書き：代表取締役社長 /description=組織代表者生年月日：1972/04/27 /description=組織代表者名：鈴木花子 /CN=山田太郎 /T=購買部長 /description=部門所在地：東京都新宿区西新宿５−５ /description=代理権内容：日本国内の1億円以下の購買行為 /description=代表権制限：1億円以下の発注購買
4. 汎用の証明書ビューアーで主体者別名の表示は問題ないか
電子委任状でデジタル署名された申請文書やデータの表示には、専用アプリケーションが提供される可能性も高いですが、PDFやWordなど汎用アプリケーションのデータとして交換されることもあるかと思います。OSやブラウザに搭載されている証明書ビューアーで電子委任状用のデジタル証明書を表示させた場合、特に主体者別名の表示に問題がないか、ちょっと見てみましょう。
4.1. Windowsの表示
Windowsでは以下のような表示になり概ね問題なさそうです。スクロールさせなきゃいけないので画像は少し貼り付けしてます。
4.2. macOSの表示
macOSのキーチェーンをつかって、上記の方法で作成した電子委任状証明書サンプルの主体者別名を表示させると以下のようになります。
4.3. Firefoxの表示
Firefoxでは以下のような表示になり概ね問題なさそうです。スクロールさせなきゃいけないので画像は少し貼り付けしてます。
4.4. Adobe Acrobat Reader DCの表示
デジタル署名したPDFを作成し、Adobe Acrobat Reader DCで表示させると以下のようになります。こちらも概ね問題ありません。
4.5. Java JCE SUNプロバイダの表示
Java JCEで標準のSUNプロバイダを使って証明書を読み込みオブジェクトをprintln()で表示させた時の、主体者別名部分の表示は以下の通りです。こちらも特に問題はありません。
[4]: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ OID.2.5.4.13="代表権制限：1億円以下の発注購買 ", OID.2.5.4.13=代理権内容：日本国内の1億円以下の購買行為, OID.2.5.4.13=部門所在地：東京都新宿区西新宿５−５, T=購買部長, CN=山田太郎, OID.2.5.4.13=組織代表者名：鈴木花子, OID.2.5.4.13=組織代表者生年月日：1972/04/27, OID.2.5.4.13=組織代表者肩書き：代表取締役社長, OID.2.5.4.13=組織所在地：東京都渋谷区神宮前３−３, O=株式会社アイツー, OID.2.5.4.97=JCN1111111111111 ]
4.6. Java JCE BouncyCastle BCプロバイダの表示
Java JCEで、フリーで有名な暗号ライブラリ BouncyCastleのBCプロバイダを使って証明書を読み込みオブジェクトをprintln()で表示させた時の、主体者別名部分の表示は以下の通りです。ASN.1ダンプとして表示されるだけですが、こちらも特に問題はありません。
Tagged [4] DER Sequence DER Set DER Sequence ObjectIdentifier(2.5.4.97) UTF8String(JCN1111111111111) DER Set DER Sequence ObjectIdentifier(2.5.4.10) UTF8String(株式会社アイツー) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織所在地：東京都渋谷区神宮前３−３) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織代表者肩書き：代表取締役社長) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織代表者生年月日：1972/04/27) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織代表者名：鈴木花子) DER Set DER Sequence ObjectIdentifier(2.5.4.3) UTF8String(山田太郎) DER Set DER Sequence ObjectIdentifier(2.5.4.12) UTF8String(購買部長) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(部門所在地：東京都新宿区西新宿５−５) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(代理権内容：日本国内の1億円以下の購買行為) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(代表権制限：1億円以下の発注購買 )
4.7. OpenSSLのx509 -textコマンドによる表示
OpenSSLの以下のコマンドで証明書情報を表示させた場合、
% openssl x509 -in aaa.cer -noout -text結果は以下のようになります。
日本語部分は16進数表示されてしまいました。X509v3 Subject Alternative Name: DirName: /2.5.4.97=JCN1111111111111 /O=\\xE6\\xA0\\xAA\\xE5\\xBC\\x8F\\xE4\\xBC\\x9A\\xE7\\xA4\\xBE \\xE3\\x82\\xA2\\xE3\\x82\\xA4\\xE3\\x83\\x84\\xE3\\x83\\xBC
4.8. 表示結果サマリ
調査した複数の汎用アプリケーションにおいて、証明書ビューアーで電子委任状のデジタル証明書を表示した結果のまとめは以下のようになりました。問題のある箇所を赤系のセルにしています。
| macOS | Windows | Firefox | Acrobat | Java SUN | Java BC | OpenSSL | |
|---|---|---|---|---|---|---|---|
| 読み込み | 問題なし | 問題なし | 問題なし | 問題なし | 問題なし | 問題なし | 問題なし |
| 表示崩れ | なし | なし | なし | なし | なし | なし | あり(※1) |
| stateOrProvince(ST)属性表示 | 都道府県/州 | S=(※2) | ST= | st= | ST= | OIDまま | ST= |
| locality(L)属性表示 | 所在地 | L= | L= | l= | L= | OIDまま | L= |
| organization(O)属性表示 | 組織 | O= | O= | o= | O= | OIDまま | O= |
| organizationalUnit(OU)属性表示 | 部署 | OU= | OU= | ou= | OU= | OIDまま | OU= |
| commonName(CN)属性表示 | 通称 | CN= | CN= | cn= | CN= | OIDまま | CN= |
| description属性表示 | 説明 | Description= | OIDまま | OIDまま | OIDまま | OIDまま | description= |
| title(T)属性表示 | タイトル | T= | OIDまま | title= | T= | OIDまま | title= |
| organizationIdentifier属性表示 | その他名前(※9) | OIDまま(※3) | OIDまま(※4) | OIDまま(※5) | OIDまま(※6) | OIDまま(※7) | OIDまま(※8) |
|
※1：OpenSSLコマンドではSANの全てのRDNは表示されない。日本語属性値が16進数表記で可読性がない。 ※2：WiindowsのみstateOrProvinceを"S="のように省略表記する。 ※3：WindowsのOID表記例「OID.2.5.4.97=値」 ※4：FirefoxのOID表記例「Object Identifier (2 5 4 13) = 値」 ※5：Adobe Acrobat Reader DCのOID表記例「2.5.4.13=値」 ※6：Java JCE SUNプロバイダーのOID表記例「OID.2.5.4.97=値」 ※7：Java JCE BCプロバイダーのOID表記例「DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(値)」 ※8：OpenSSLのOID表記例「2.5.4.97=値」 ※9：macOSでは「その他名前」となり元OIDが何であったか情報が無くなる。 | |||||||
5. 電子委任状の識別名に関する考察
解説書に基いてサンプルの電子委任状を発行してみましたが、主体者名、主体者別名における課題について考察したいと思います。
5.1. 属性タイプについて
主体者名(subject)や主体者別名(subjectAltName)の識別名において、 属性タイプはITU-T X.509としては何でも構わないが、 標準的なものはITU-T X.520で定義されていて、 X.500 attirube typesの一覧はここでも見られます。 ただ、ITU-T X.520では、X.500ディレクトリやLDAPで使用可能な 属性タイプが全て含まれていて、例えばLDAPエントリとして、 ユーザーのパスワードを格納する id-at-userPassword属性や、 CA証明書を格納する id-at-cACertificate 属性が定義されていたとしても、 証明書でこの属性タイプを使うことは常識的にないでしょう。
そこで、インターネットで証明書を含むデータを交換する場合のために、 ITU-T X.509では、選択肢が広すぎて困っていたものを、 利用可能なオプションを制限するためのプロファイルを RFC 5280として 定義しています。
属性タイプに関する記述は、 4.1.2.4節 発行者(Issuer)の節に書かれており、 これと同じルールが主体者名、主体者別名にも適用されます。 ルートしては、実装が処理または受理できる属性タイプについて述べられています。
- C、O、OU、distinguishedNameQualifier、ST、CN、serialNumber、DCは受理できなければならない(MUST)。
- L、T、surname、givenName、initials、pseudonym、generationQualifierは受理できるべきである(SHOULD)。
5.2. organizationIdentifier属性タイプについて
organizationIdentifier属性タイプは、一般には企業や組織の番号を表すために用いられ、電子委任状では「国税庁が指定する法人番号」を記載するとしています。欧州の国民IDであるeIDAS規則の電子証明書でも、organizationIdentifierが使われており、徐々に浸透していくであろう属性ではありますが、
- 5.1節で述べた通り、RFC 5280には無い属性であり
- 4.8節の汎用証明書ビューアーでも表示されない属性タイプである
- 他のほとんどの属性では、「代理権内容：」のようなプリフィクスを使った表記にしている
5.3. description属性タイプについて
電子委任状の主体者別名(subjectAltName)に記載される多くの属性は、 description(2.5.4.13) もしくは organizationName(2.5.4.10)のいずれかの属性タイプを用い、 「代理権内容：」のようなプリフィックスを値に含めて記載することになっています。 私は、様々な変わったX.509証明書を収集するのが趣味で、 いろんな証明書をこれまで見てきましたが、識別名にdescription属性タイプを使用した 証明書を見たことがありません。 descriptionは一般には、LDAPなどのディレクトリにおいて、 あるエントリの補足情報や備考情報をメモ的に記載するために用いるのが 一般的な使用法かと思います。 相互運用性の観点から、あまり使用しない方が良かったのではないかと考えます。 海外のPKI有識者も「日本はヘンな事やっちゃってるなぁ、、、」と考えるんじゃないかと思います。
5.4. OUを使う事の是非について
前述のように電子委任状の多くの属性では、 その属性が本人に帰属するものか、 組織に帰属するものかに関わらず、 識別名の属性タイプがOUもしくはdescriptionの いずれかを使うことになっています。
一般に、OUは人事部、総務部、開発部、採用課といった 部署名を表すための属性ですので、 主体者に紐づく雑多な属性 を記載するためのふさわしい属性タイプではありません。 OUを使った場合に、特に違和感がある電子委任状の属性は、 以下のところかと思います。
- 委任者する側の法人の商業登記における本店所在地：(例)OU=組織所在地：本町３−３
- 委任者する側の法人代表者の肩書き：(例)OU=組織代表者肩書き：代表取締役社長
- 委任者する側の法人代表者名：(例)OU=組織代表者名：山田太郎
- 委任者する側が個人事業主の場合、その生年月日：(例)OU=組織代表者生年月日：1970/04/01
5.5. ではどの属性タイプを使うのが良かったのか
以上で示してきたように、
- description属性タイプの利用は、過去に使用例が見当たらず相互運用性の観点からも問題があるのではないか。
- OU属性タイプの利用は本来、部署名を表す属性であるため適切ではないのではないか。
EV証明書のように、個々の属性に対し、個別の属性タイプ、例えば「組織代表者生年月日」に対して「0.2.440.100145...23」を定義する方法もあったわけですが、そのような特殊な属性は汎用の証明書ビューワーでは表示されず視認性が悪いので、descriptionやOUを使い、「組織代表者生年月日：」のようなプリフィクスを用いて表記するのは、それほど悪くない方法だったのかなと考えています。
5.6. 似た日本語文字の問題
プリフィクスに「組織所在地：」のようにコロン「：」が使われていますが、 解説書のページでは全角文字を使う事になっているようです。表記の揺らぎがないように、プリフィクスはUTF-8でどのようなバイト列(オクテット列)になるのか、明記しておくのが良いように思います。
また、ある文字と異なる文字、非常ににた形の文字がバイト列上(=Unicodeコードポイント上)別の文字にされてしまうことがあります。これを攻撃に使った場合ホモグラフ攻撃と呼ばれており、これを不正な証明書の発行に使われてしまうかもしれません。例えば、下の「日」文字は形が似ていますが別の文字です。
日野市 (日=U+65E5 正しい)
曰野市 (曰=U+66F0)
日本、中国、韓国で使われる文字でこのような似たような形で、異なる文字はあるようで、電子委任状においては解説書別表に
日本語で記載する場合、JIS第１水準・第２水準、補助漢字以外の文字は、代替文字に変換すること。このとき、代替文字仕様位置情報を証明書に付与することが望ましい。と記載されており、上記の「日」も正しい「日」で統一されるように代替文字の変換情報が提供されるかもしれません。認証局は「JIS第１水準・第２水準、補助漢字」の範囲内であるかの確認が必要になりますね。
アパートやマンションの名称でローマ数字(IV等)が使われることがありますが、これは拡張漢字となるので注意が必要で、アルファベットで表記する必要があります。(「I」+「V」=「IV(二文字)」)
5.7. その他、記載例における細かい課題
解説書別表の記載例で、他に少し気になったところをまとめておきます。
- CRLDistributionPointsの記載例がCRLを参照しておらずHTMLへのURLになっています。*.crl のように正しい拡張子にするのが良いかと思います。
- 組織代表者生年月日が「yyyy/mm/dd」となっているが、スラッシュ"/"はOpenSSLでのディレクトリ名表記と相性が悪いので無い方がよかったでしょう。
-
記載例は、どこに何が記載されているのかバラバラで見辛く、ちゃんと証明書プロファイルの構造で記載するのが良かったかなと思います。一部、アルゴリズムやシリアルなどプロファイルのみに記載すべき情報も記載されており、混乱しやすいように思います。以下のようなプロファイルの基本構造を示すとわかりやすかったかと思います。
フィールド/拡張名 内容 発行者名 電子委任状取扱サービス(=発行者)の英語名称 有効期間 委任される期間 主体者名 (部長さん等)受任者に関する主要な英語情報(氏名、所在地等) 発行者別名 電子委任状取扱サービス(=発行者)の日本語名称 主体者別名 ・(部長さん等)受任者に関する日本語の情報
・(社長さん等)委任者に関する日本語の情報
・(部長さんの権限範囲等)代理権の情報
なんか、長々と取り留めもない話を書いちゃってごめんなさいね。
