自堕落な技術者の日記

OCSPによる失効検証は、先日のApple macOS Big Burrのソフトウェアコード署名の大量の検証で、OCSPレスポンダ高負荷による失効検証の障害が出たのではと推測されるように、通信障害、サーバー障害などでOCSP応答が取れないなどのことがあって、最近非常に評判が悪いです。そのため、ウェブブラウザの世界では、Chromeでは CRLSet、Firefox ではCRLiteという別の失効検証方法を使おうとしているそうです。ChromeのCRLSetについては2013年2月に、CRLSetで本当に大丈夫なんだろうかと思い「将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話」というブログエントリを書かせていただきました。(が、その後、Chrome CRLSetがどうなっているのかよくわかっていません。)

で、Firefox CRLiteについてですが、 先日、「Querying CRLite for WebPKI Revocations」(2020.11.26)という記事が公開されました。Firefox Nightly バージョンで実装されているCRLite失効検証の機能を確認するためのPythonのツール moz_crlite_query が合わせて公開されています。Firefox Nightly 85.0 で実装されているということなので、2021年1月26日リリース予定のFirefox 85正式版ではCRLite失効検証が使われているということなのでしょう。(間違っていたらごめんなさい。) おお、FirefoxのCRLiteがいよいよ実運用されるんだなぁ、、、とwktkしながら、今日はこの moz_crlite_query を試してみたいと思います。

インストール

Python 3.7 以上の環境で

% pip install moz_crlite_query

とすればインストールすることができます。依存するPythonモジュールをビルドするのにgcc、g++が必要になるみたいです。

私のMac Book Airは古くから使っていてPython環境が汚れていて、OSで提供されるPython2.7、Python3?、macportsのPython2、Python3などあり、切り替えがうまくいかず、インストールでとてもハマりました。 古いPython setuptoolsだと、2.7等、バージョンが古くてもインストールエラーにならないようで、これでハマりました。 最初からpyenv使っときゃよかったんだよなぁ、、、。pyenvでPython 3.9を入れ直して、Windows 10 WSL2でインストールしたmoz_crlite_queryスクリプトをコピーし戻してやっと動くようになりました。pyenvでインストールしたときmoz_crlite_queryスクリプトはどこにインストールされるんだ？？？

Windows 10 WSL2のUbuntuに入れるのは、それほど大変ではありませんでした。aptコマンドで足りてなかった、gcc、g++、python3-devを入れてpipでインストールできました。

サイトで紹介されてる実行例は、いちいちPEM証明書ファイル持ってきてますが、「moz_crlite_query --hosts 調べたいTLSサイトFQDN」で調べられます。例えばMacでwww.nist.govを調べればこんな感じ、

Windows WSLでec.europa.euを調べればこんな感じで実行できます。

(絵文字使うんじゃね〜〜！！！)
PEM証明書を指定して「moz_crlite_query PEM証明書ファイル」でも調べることができます。

で、ちょっと見てみるぞ、と

CRLiteのデータベースは一日に4回更新して配布されるそうで、moz_crlite_queryコマンドは、データベースを確認して新しいのがあれば~/.crlite_dbにデータベース一式をダウンロードして使用します。ファイルの一覧はこんな感じ。

2020-11-24T00:08:12+00:00Z-full		2020-11-26T18:08:13+00:00Z-diff
2020-11-24T06:08:12+00:00Z-diff		2020-11-27T00:08:16+00:00Z-diff
2020-11-24T12:08:14+00:00Z-diff		2020-11-27T06:08:13+00:00Z-diff
2020-11-24T18:08:15+00:00Z-diff		2020-11-27T12:08:20+00:00Z-diff
2020-11-25T00:08:23+00:00Z-diff		2020-11-27T18:08:11+00:00Z-diff
2020-11-25T06:08:05+00:00Z-diff		2020-11-28T00:08:14+00:00Z-diff
2020-11-25T12:08:22+00:00Z-diff		2020-11-28T06:08:12+00:00Z-diff
2020-11-25T18:08:11+00:00Z-diff		2020-11-28T12:08:12+00:00Z-diff
2020-11-26T00:08:11+00:00Z-diff		2020-11-28T18:08:21+00:00Z-diff
2020-11-26T06:08:17+00:00Z-diff		intermediates.sqlite
2020-11-26T12:08:14+00:00Z-diff

コマンドを実行すると表示されている通り、2457のパブリックな中間CAが登録されているようで、FAQでは「すべてのCA」とか言っちゃってますが、そういうわけではなさそう。エンドエンティティがSSLサーバー証明書を発行しているような中間CAは概ね登録されているようですが、SSLサーバー証明書発行用でないCAや、中間CA証明書の検証に使うCAは登録されていないようです。登録されてない中間CAに対してクエリをかけると「Enrolled in CRLite: ✕」のように表示され登録されてないことがわかります。(絵文字ヤメロw)

「intermediates.sqlite」が中間CAのSQLiteデータベースになっており、中にはテーブルは一つしかなく、こんな感じでスキーマ定義されています。なんとなく想像つきますね。

CREATE TABLE intermediates (
  id TEXT PRIMARY KEY,
  last_modified TEXT,
  subject TEXT,
  subjectDN BLOB,
  derHash BLOB,
  pubKeyHash BLOB,
  crlite_enrolled BOOLEAN, -- crlite_enrolled = FALSEな中間CAは1656なので、対応してるのは801 CA?
  whitelist BOOLEAN); -- whitelist = TRUEな中間CAは登録されてなかった

とまぁ、こんな感じなんですが、CRLSetのときに書いた疑問は払拭されず、本当に信用できるのかモヤモヤしますね〜〜〜。なんかヤベーーーの見つけちゃった気もするし。ブラウザでどう使われているのか見ないと何ともいえないですが、、、、

今日はこんなとこで。環境も汚れてきたしバッテリーも酷い状況なのでM1 Mac Book Air買うかなぁ、、、

大したネタではありませんが、ずっと塩漬けになっていたブログ投稿を放流します。ごめんなさい。

2018年7月頭にサンフランシスコに行ってきたんですが、むこうで使うSIMをいろいろ調べていたところ、むこうで買うよりアマゾンで購入するのが主流っぽかったので、Lycammobileのを買ってみました。

READY SIMと迷いましたが、レビューコメントを見てLycamobileの方が、接続トラブルがなさそうなのでこっちにしました。私が買った時は1GBデータ通信込みで2,340円でした。旅行の前に見た時は無かったんですが、今日見たらLycamobileで4GB 2,420円があって、当時こっちがあったら、こっちを買ってたと思います。

接続には全く問題なかったです。家族で連絡も取れるし、ポケゴ三昧でよかったです。

夏休みの宿題みたいな感じで、この2ヶ月くらい、jsrsasignの大改造をし、証明書、CRL、OCSP、CMS SignedData、タイムスタンプの読み取りと生成のコードを大幅に書き直し、後方互換性をバッサリ切ったので、なんだかんだでバージョン10.0.0となりました。これで読み取りも、全部一貫して、生成もJSONでちゃちゃっと簡単にできるようになったかなと思います。

jsrsasignの保守はこれくらいでやめにして、最近は既存の証明書チェーンや、CRL、OCSPレスポンス、タイムスタンプトークンから、検証環境を自動で作るようなツールを作っています。普通だとCAごとに環境作ったり、OCSPレスポンダつくったり、TSA作ったり手間もリソースもかかり面倒くさいですが、一つのVM、一つのIPで、楽ちんポンで、これができちゃうようになるというもので、概ねベータバージョン的なものができ、QCだの、eSeal証明書だの、TSAだのいろんなテスト環境作って遊んでいます。

さて、そんな中、自分のオープンソース活動について、Googleの中の方に推薦頂き、2020年Q3の、Google Open Source Peer Bonus Awardという賞をもらい、賞金ももらってしまいました。(社内表彰みたいなのを除いて)このところ賞をもらうことなんて殆どないのでとても嬉しいです。ありがとうございます。頂いた賞金で、Mac Book Airのバッテリがヘタってきたので交換したり、家族で小さいお祝い会をしたいと思います。

GoogleのOpen Source Peer Bonusは、4半期に一度、Googleの社員の方の推薦でオープンソース活動について表彰いただけるというプログラムなのだそうです。元気のある会社はすごいですねぇ。過去には、2020年1Qの受賞者のアナウンスがこのブログエントリでされていました。今回の表彰もまとめてアナウンスしてもらえるのではないかと思います。 ちなみに、頂いた賞状はこんな感じです。↓↓↓

また、前回あんなエントリを書いたあと、私のオープンソース活動に、いろんな方が気にかけてくれ、お声掛けしてくれたり、寄付してくださったりしました。本当にありがとうございます。これを励みに、のんびり自分のペースで活動を続けていこうと思います。

追記 (2020.10.06)

公式ブログに「Announcing the latest Google Open Source Peer Bonus winners! (Monday, October 5, 2020)」が掲載されました。あざます。あざます。

私はjsrsasignというJavaScriptのオープンソース暗号、PKIライブラリを個人的な趣味で開発し公開しています。ところが最近、npmパッケージのダウンロードが月間60〜70万件と、異常にユーザーも増え、製品でも使われ始め、ちょっと厄介なことになっており、いろいろ悩んだ挙げ句、これが正解なのかもわかりませんが、ライブラリの維持のために寄付金を募ることにした次第です。今日は、心の吐露をつらつら書いていくことにします。

jsrsasignとは

2010年ごろ、スタンフォードの学生さんであるTom Wooさんという人のJavaScriptでRSA暗号化できるコードを見つけ、自分はPKIや電子署名を専門にしていたので「JavaScriptでRSA署名できたら面白いな」と思い、2010年6月に、ほんのRSA署名単機能のライブラリとして公開したのが jsrsasign です。当時のはしゃぎっぷりはブログでこんな感じ。 小躍りしてツイートしてたのはこんな感じ。

Kenji Urushima@kjur

BigIntegers and RSA in JavaScript http://www-cs-students.stanford.edu/~tjw/jsbn/ マジか、JavaScriptでRSA暗号してるよ。

2010/05/24 07:17:03

Kenji Urushima@kjur

秘密鍵フォーマットもPKCS#1/8があつかえるといいかもしんない。そのためにも簡易ASN.1だ BigIntegers and RSA in JavaScript http://www-cs-students.stanford.edu/~tjw/jsbn/

2010/05/24 07:22:46

Kenji Urushima@kjur

実は昨日JavaScriptでRSASSA-PKCS1-v1_5 RSA署名できたのだ。 任意の文字列にSHA1withRSAで署名できると思う。DigestInfo生成は文字列連結なので簡易ASN.1を作りたいとこ♪コレ活用→ http://bit.ly/9dUYXP

2010/05/28 17:04:02

その後、ASN.1ライブラリ、X.509証明書、CRL、CMS SignedData、タイムスタンプ、CAdES-BES/EPES/T、OCSP、CSR、共通鍵暗号、楕円曲線暗号、RSA-PSS署名、DSA署名、JSONのJWS、JWT、JWKの対応など、自分が欲しいと思う機能を少しずつ建て増しをして10年になります。多くの個人のオープンソースプロジェクトは1年くらいで終わってしまうそうですが、まぁ、なんとか自分のために追加開発やメンテナンスを続けています。

このライブラリが特徴的なのは、

なんでも入っている

一つライブラリに多くのPKI、暗号の機能がつめこんであります。 Swiss Army Knife(スイスの十徳ナイフ)スタイルというそうです。 自分がものぐさなので、これをロードしさえすれば何でも試せるように作りました。

とにかく使い方が簡単

どんな秘密鍵でも公開鍵でも自動判定してロードできるようになっていたり、ASN.1 DER構造の中身に簡単にアクセスできたり、面倒くさいことはなるべくライブラリに任せてできるようになっています。証明書やタイムスタンプなどはJSONのプロパティから簡単につくることもできます。共通鍵暗号も簡単です。APIの構成はJavaのBouncyCastleライブラリやIAIKライブラリなどのJCEアーキテクチャを参考にしているので、それを知っていればさらに使いやすいでしょう。自分がものぐさだから(二回目)、極力短いコードでいろんなことができるようになっています。

ドキュメント、サンプルが非常に豊富

ライブラリはあってもAPIドキュメントがなくてどんなAPIがあるのわからなかったり、BoucyCastleみたいにメソッドはわかるけど呼び出し方がわからないなどのことが無いようにAPIドキュメントの記述が充実しており、APIドキュメント中に例も入れています。また、Wikiなどの入門解説ページや、多数のオンラインでも試せるサンプルコード、テストコードがあり、自学習でもかなり何とかなると思います。APIが前提知識最小でも行けるように工夫してますので。

環境依存がほぼ無い、他のパッケージの依存がない

JavaScriptが動く環境であればどこでも動作します。古いブラウザでもほとんどの機能は動作しますし、Node.jsでも動きます。npmパッケージでも公開されていますし、CloudFlareなどのCDNからも利用できます。必要なサードパーティの関数は含まれており、他のライブラリ、パッケージに全く依存しておらず単独で使えます。Nodeの中でOpenSSLに依存していることもありませんし、(ブラウザ互換性でいつも悩まされる、この先どうなるかもわからない)W3C Web Cryptography APIを使っているわけでもありません。

いろんなツールがすぐ使える

自分でプログラミングしなくても、オンラインで公開しているツールで証明書を発行したり、鍵ペアを生成したり、デジタル署名の生成や検証したり、JWTを生成したり、いろんなことができます。Nodeで実装されたいろんな便利なPKI関連ツールもついています。

速いとは言えない

自分がPKI関連のいろんなことを少ないコードで簡単にテストするために作っていますので、高速に動作することを目的にしていません。数百万のトランザクションを処理したいといった目的なら他のライブラリを使う方がいいでしょう。

一人でここまでよくやったなぁ、、、と。お節介か、、、www

jsrsasignの歴史を振り返る

10年だもの、まぁ、いろいろありますよ。自分のためにちょっと歴史を振り返ってみます。

• 2010年6月：v1.0：jsrsasign初版公開。RSA署名だけ。
• 2012年4月：v1.2：公開リポジトリをGitHubに移行。
• 2013年4月：v2.0：PKCS#1 PEMなどの鍵のロード機能がつき始める。 JavaライクなSignature、MessageDigestクラス、ASN.1エンコーダー、X.509証明書エンコーダー、RSA-PSSサポートなど
• 2013年5月：v3.1：暗号化されたPKCS#5鍵のロードのサポート
• 2013年6月：v4.0：ECDSA署名サポート
• 2013年9月：v4.1：PKCS8など柔軟な鍵ロード用クラス KEYUTIL を追加
• 2013年10月：v4.2：DSA鍵、署名のサポート
• 2014年4月：v4.5：CMS SignedDataサポート
• 2014年5月：v4.6：RFC 3161 Timestampサポート
• 2014年7月：v4.7：RFC 5126 CAdES-BES/EPES/Tサポート
• 2015年6月：v4.8：NodeJS npm、JSON JWS、JWK、JWTサポート
• 2015年10月：v5.0：CSRサポート、便利なNode.JSスクリプトの追加
• 2016年9月：v6.0：OCSPサポート
• 2016年11月：v6.2：識別名のmulti valued RDN、RFC 2253 LDAP識別名文字列表現のサポート
• 2017年6月：v8.0：コードのスリム化、長期間非推奨(Deprecated)だった関数の削除
• その後、細かい機能追加や脆弱性指摘対応などが続き現在に至る

jsrsasignはどれだけ使われているか

自分の趣味でやってる調査のために開発したライブラリですが、Node.JSのパッケージ npm で公開した2015年あたりから利用者ダウンロードが増えています。github.comからのダウンロードや、勝手に行われている公開CDNからの利用もあると思いますが、npmパッケージのダウンロード数だけでいうとnpm-stat.comさんのダウンロード数グラフを見てみるに、2018年あたりからブリブリ増えてしまっており、2019年あたりからサチりはじめ、それでも最近の月間ダウンロードは60万件超、先月は70万を超えてしまいました。npmでは他のパッケージの依存関係を書けるのですが、2020年7月現在で379ものnpmパッケージのプロジェクトがjsrsasignに依存していることがわかります。とほほ。

jsrsasignは自由に使ってもらっていいですが、ライセンスは放棄はしていないので、ライセンス掲載の義務はあり、たまにエゴサーチでPDFで検索してみると、いろんな製品の中でも使われちゃってることがわかります。

• 独シーメンスのConnect X300というビル制御システムで使われていたり [OSS一覧]
• EUの公共向けシステムらしいCITADELで使われていたり [OSS一覧]
• セールスフォースのSalesforce DMPで使われていたり [OSS一覧]
• ソニーのビデオプロジェクターLSPX-A1、映像製作機材XDS-1000、PDW-HR1等で使われていたり [LSPXガイド] [XDS OSS一覧] [PDW OSS一覧]
• キヤノンの複合機 iR-ADV や 印刷機 imagePRESS C165 で使われていたり [iRADV8505 OSS一覧] iRADV4500 OSS一覧] [imagePRESSガイド]
• 横川電気のSMARTDAC+というデータ測定機器で使われていたり[マニュアル][英語]
• VERINTという通話記録機器など提供する会社の製品で使われていたり [OSS一覧]
• Oracle Blockchain Platformで使われていたり [ライセンス情報]

あとは、以前シャニマスのライセンス表示にjsrsasignが載っていたり、某社は使っているのにオープンにしていただいてなかったり、、、、（＾＾； こんな、個人が趣味で開発しているライブラリに、みなさん乗っかっちゃって大丈夫なんですかね。逆に心配になっちゃいますね。

ユーザが増えた悩みの始まり

最初は、「自分の調査のために趣味で維持しているライブラリがみなさんの役にたって、使ってもらえてるなら良いことだなぁ。これからも趣味で自分の必要そうな機能は追加していこうかなぁ、、、」で済んでたんですが、最近ユーザーも増えてそうも言ってられなくなってきたんです。

そもそも、jsrsasignは MITライセンスの下で無償、無保証で配布されています。もし、セキュリティ脆弱性やバグがあっても、私には修正する義務はないし(とはいえ、指摘されたら直すわけですが)、オープンソースなので問題があれば好きに修正して使っていただいていいわけです。もちろん修正コードをもらえれば、それは反映してすぐに公開します。

そんな中おきたThe RegisterやUsenixの指摘

2020年5月にITセキュリティのニュースサイトであるThe Registerで 「What happens when the maintainer of a JS library downloaded 26m times a week goes to prison for killing someone with a motorbike? Core-js just found out」という記事が掲載されました。JavaScriptのバージョンの違いを吸収するためのCore-jsという有名なライブラリがあって、その開発者がバイクで交通事故を起こして被害者の方が亡くなり収監されて、ソフトウェアのアップデートが滞っており問題だというものでした。

この記事の中で、私のjsrsasignも、2018年4月から2020年まで更新されてないと指摘をされてしまいました。

(記事引用)
Another JavaScript cryptographic library known as jsrsasign faces a similar challenge: its maintainer, Kenji Urushima, hasn't been active since April 2018. Programmers who use the software have expressed concern about the lack of communication and an unaddressed vulnerability, noting that 350 npm projects depend on the library, including some by Microsoft and Mozilla,
(抄訳)
jsrsasignとして知られている別のJavaScript暗号ライブラリも同様の課題に直面している。その管理者である Kenji Urushima は、2018年4月から活動していない。このソフトウェアを使用しているプログラマは、対話の欠如と対応されていないある脆弱性について関心を寄せている。注目すべきは、MicrosoftやMozillaを含む350のnpmプロジェクトがこのライブラリに依存しているという事である。

指摘された問題は、Minervaと呼ばれるECDSA署名のタイミング攻撃により処理時間を大量監視していれば秘密鍵が復元できる可能性があるというもので、元々、楕円曲線暗号の部分はBitcoin-JSを使っており、自分のコードではないので、調査するにしてもかなり時間がかかる根の深い問題でした。また、自分は本業の方も忙しい時期だったのでなかなか調査もできず、誰からも修正コードの支援をしてもらえないままでいました。jsrsasignは大量のトランザクションで使われることもあまりないし、攻撃の実現はかなり低いと考えていました。他の簡単に回答できるものには回答していましたが、根が深いのでこの問題は手付かずにしていたのです。

おそらくこの記事をうけて、USENIXという団体の機関紙のコラム「Who Will Pay the Piper for Open Source Software Maintenance? Can We Increase Reliability as We Increase Reliance?(誰がオープンソースソフトウェアの保守の費用を負担するのか？(オープンソースの)依存が増える中、信頼性を上げることできるのか？」の結論でも、jsrsasignを「(開発を)撤退したソフトウェア」として取り上げられてしまいました。

やっとMinerva脆弱性の修正

jsrsasignの根深い問題の調査まで手がまわらない状態が続いていたのですが、プライベートで慌ただしい時期がようやく終わりかかり落ち着きだした2020年4月、Node.JSのパッケージマネージャーを管理するnpmのセキュリティチームからもMinervaの脆弱性指摘が来てしまい、いよいよ直さざるをえない状況になりました。他の人が作ったコードを解析し、修正し、テストケースを作成して確認し、修正リリースを出しました。[勧告]

そしてまた別のMalleabilityに関する脆弱性指摘が3つも

2020年6月に Antonio de la Piedra さんから、3つのmalleability(展性)に関する脆弱性の指摘を受けてしまい、初めてUS-CERT、MITREの脆弱性データベースにCVE登録されてしまいました。3つのうちの1つは、npm のセキュリティチームからも対応依頼が来ました。「malleability(展性)」とは、金属を叩いて延ばしても破壊されずに広げることができる性質のことを言うのですが、ソフトウェアの世界では、同じ意味のデータを別の表現ができるという事をmalleabilityと呼んでます。例えば、10進数で数値の12345という値があったとして、先頭にゼロを幾つかつけて00012345としても値は同じであるといった事です。

暗号では、大きな数値を使って暗号文、署名値など表現することが多いですが、 指摘された3つの脆弱性は簡単には以下のようなものでした。

• CVE-2020-14966 ECDSA署名の署名値が、前述のようなゼロを先頭に足した値を使ったものでも正しい署名として受け入れてしまう等。(CVSS3.X 7.5, CVSS2.0 5.0)
• CVE-2020-14967 RSA暗号の暗号文が、前述のようなゼロを先頭に足した値を使ったものでも復号ができてしまう。(CVSS3.X 9.8, CVSS2.0 7.5)
• CVE-2020-14968 RSA-PSS署名の署名値が、前述のようなゼロを先頭に足した値を使ったものでも正しい署名として受け入れてしまう。(CVSS3.X 9.8, CVSS2.0 7.5)

これが深刻な脆弱性にあたるかに関しては疑問があり、前述のようにゼロを足したとしても、別の署名対象文書を正しい署名として受け入れたり、暗号文の内容を別の内容に書き換えることができたりといった攻撃とは無関係です。また、大量にゼロを足した場合にメモリ破壊が起きると指摘されましたが、JavaScriptのBigIntegerでは、C言語のような桁あふれも発生しないので指摘にはあたらず、脆弱性を利用した攻撃は実現できないと考えています。vulndbのCVSSスコアはそれほどでもなかったですが、US-CERTのスコアはやたら高いです。

6月頃は仕事もプライベートも落ち着いていたので、週末や夜に対応の時間を取ることができ、問題の調査をし、コードを修正し、Antonioさんにもらったテストコードで問題なくなった確認し、2週間くらいで修正リリースし、セキュリティアドバイザリを公開しました。 [勧告1] [勧告2] [勧告3] かなり短期に対応できたかと思います。ちなみに、RSA-PSSはDaveさんが提供してくれたコードで、自分で解析して修正しなければならないので厄介でした。ECDSAについては、署名値が厳密なASN.1 DER構造であることをチェックしていなかったために起きた問題で、その厳密なチェックをする機能を追加するのにテストケースが多すぎて骨が折れました。

というわけで、オープンソースのライセンスで、現状有姿、無保証で提供するという条件で利用してもらっているにもかかわらず、結局、義務的に直さざるを得ず、問合せ対応や、報告者への対応、セキュリティアドバイザリの作成などしなければならない状況になっているのです。ソフトウェアの開発や保守でお金をもらっているわけでもないのに、とてもモヤモヤします。もちろん、本当に攻撃の影響を容易に受けてしまうような深刻な脆弱性については、何とか時間を作って急いで修正します。でも、「自分のために作ったライブラリを他の人が喜んで使ってくれるなら開発にかかったコストも要求せず、無料で、現状有姿で提供しましょう。」と言っただけなのに、多くの土日や夜まで潰して手厚いサポートまでタダで求めてくるのは「それは善意の搾取です！！！」とガッキーのように叫びたくなります。

同じオープンソースの暗号ライブラリでも、OpenSSLのように多くのメンバーが開発に関わっていて、修正パッチの提供も有志がやってくれるような状況なら、脆弱性指摘を対応する体制も作れますが、私一人で開発しているような状況なので、仕事やプライベートの都合でタイムリーに脆弱性対応できないケースがあります。そんな手厚いサポートを求められても困るのです。

私は、製品のセキュリティインシデントレスポンスチームであるPSIRTの仕事もしていたので、外部から脆弱性を指摘された場合に、しかるべき機関と調整しながら脆弱性対応する必要があることもわかっています。ただ、こうしたライブラリの場合は厄介で、よく使われる機能も、そうでない機能も様々取り揃えてライブラリを構成しているので、問題への影響が大きいのか小さいのかという判断をつけにくいです。そのため、リスクが高かろうが低かろうが「直せ」と要望が来てしまいます。なんか、段々、オープンソースを公開するのが面倒くさくなってしまいました。

そして寄付金を募ることにしました

「お金もらってるわけでもないのに文句言うな」とモヤモヤした気持ちを抱えたまま、jsrsasignを維持し続けるのもモチベーションが持ちそうにないので、ふと「寄付金」を受け付けてみてはどうかなぁ、、、と思いました。寄付金制度を導入すれば、どれだけの人がこの一人プロジェクトを応援してくれてるのかわかるし、「こんなに応援してくれてるんだから、ちょっと頑張らなきゃなぁ」という気持ちになるかもと思ったわけです。調べてみると、

• (1) GitHubのスポンサー制度(毎月いくらとか設定して応援してもらえる。日本の口座もOK)
• (2) Bitcoin、Bitcoin Cashなどの仮想通貨による寄付(自分の口座が放置されてた)
• (3) Paypalによる寄付 (日本の金融機関ではできない)
• (4) Open Collective (日本ではかなり敷居が高そう)
• (5) Buy Me A Coffee (これも面倒くさそう。でも決済がGitHub Sponsorsと同じStripeだから可能性あるかな)

(1)は検索してみると日本の開発者の方も設定しているようで、いろんな方の設定内容を参考に設定することができました。(2)は、仮想通貨口座のアカウントの復旧、追加本人確認手続きが結構面倒だったんですが何とか復活させることができました。(3)はちょっと考えがあるので、そのうちチャレンジしてみようと思います。(1)の審査までの準備は、わからないことも多くて相当かかったのですが、審査申請して2週間と言われてたところを2日くらいで承認されました。(2)と合わせて、ようやく今日、READMEに寄付受付を書いてみました。

今後、そのうちどうするか

と、まぁ、サポートや脆弱性対応のモチベーションは何とか寄付金で自分をだましだましやろうと思うんですが、自分もいい歳なので、自分が開発、サポートができなくなった時にどうするかですよね〜〜。急遽、長期入院などして何もできないことがあるかもしれませんし。GitHubでは、後継者を指定して何かあったとき、その人に管理を譲ることができる機能があるんですが、こんなわけのわからないソフトのメンテと問合せサポートを他人に押し付けるわけにもいかないので、多分自分が開発できなくなったら一代限りで終わりなんでしょうねぇ。ソースは全てリポジトリにあるので、引き継いでくれる人が世界のどこかから出てくるのかもしれませんが、完全にお任せで好きにしてもらうのが良いんじゃないかと思ってます。

ただ、自分に何かあったとき、「このプロジェクトは今後一切、メインの開発者がサポートできなくなりました。」と伝えてあげる必要はあるなぁと思っています。娘か知り合いに託すしかないのかなぁ。そうしないと、また The Registerの記事のような騒ぎになってしまうので、、、なんか、デジタル遺品とか終活ノートみたいな話ですね。

趣味でちょっと、好きなものだけ好きなように開発したかっただけなのになぁ、、、なんでこんなことになっちゃったのかなぁ、、、

こんなこと書いちゃってますが、開発はぼちぼち続けていきますよ。本人はいい加減な人間なので、そんなに気に病んでるわけでもないので、どうかお気になさらずに。 なんか、愚痴っぽい話につきあってもらってすみません。今日はこの辺で。

お詫び：この記事は３月に書き始め、５月に大方できていたのですが、なんかボリューム満点な割に、落とし所がなくなってしまい、辛くなって放置していました。これが終わらないせいで、他の記事も何となく書くのが億劫になっていました。やっと８月末の今日、少し書き足して生煮え記事として供養させてください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

結果は以下のようになります。

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

日本語部分は16進数表示されてしまいました。

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)。

これらにない属性タイプが全く使われないわけではなく、例えばEV証明書でjurisdictionOfIncorporationC(登録管轄国)などの属性が使われているが、別のガイドや標準で規定しない限りは、上記以外の属性タイプを使って、プログラムが異常終了したり、エラーが発生したとしても文句は言えないわけです。相互運用性の問題が発生するので、RFC 5280で記載された属性タイプを使う方が安心かと思います。

5.2. organizationIdentifier属性タイプについて

organizationIdentifier属性タイプは、一般には企業や組織の番号を表すために用いられ、電子委任状では「国税庁が指定する法人番号」を記載するとしています。欧州の国民IDであるeIDAS規則の電子証明書でも、organizationIdentifierが使われており、徐々に浸透していくであろう属性ではありますが、

• 5.1節で述べた通り、RFC 5280には無い属性であり
• 4.8節の汎用証明書ビューアーでも表示されない属性タイプである
• 他のほとんどの属性では、「代理権内容：」のようなプリフィクスを使った表記にしている

などの事から、この属性だけを、無理に厳格にorganizationIdentifierを使う必要もなかったのではないかという気がします。

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

主体者の属性であれば、CN(commonName)を使うべきだったのではと思います。

5.5. ではどの属性タイプを使うのが良かったのか

以上で示してきたように、

• description属性タイプの利用は、過去に使用例が見当たらず相互運用性の観点からも問題があるのではないか。
• OU属性タイプの利用は本来、部署名を表す属性であるため適切ではないのではないか。

いずれも、多少なりとも問題があるように思います。 主体者個人に帰属する属性はcommonName(CN)を使用するのが良かったのではないかと考えています。

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でのディレクトリ名表記と相性が悪いので無い方がよかったでしょう。
• 記載例は、どこに何が記載されているのかバラバラで見辛く、ちゃんと証明書プロファイルの構造で記載するのが良かったかなと思います。一部、アルゴリズムやシリアルなどプロファイルのみに記載すべき情報も記載されており、混乱しやすいように思います。以下のようなプロファイルの基本構造を示すとわかりやすかったかと思います。

  フィールド/拡張名	内容
  発行者名	電子委任状取扱サービス(=発行者)の英語名称
  有効期間	委任される期間
  主体者名	(部長さん等)受任者に関する主要な英語情報(氏名、所在地等)
  発行者別名	電子委任状取扱サービス(=発行者)の日本語名称
  主体者別名	・(部長さん等)受任者に関する日本語の情報 ・(社長さん等)委任者に関する日本語の情報 ・(部長さんの権限範囲等)代理権の情報

なんか、長々と取り留めもない話を書いちゃってごめんなさいね。