PDF　千夜一夜

« 2007年04月 | メイン | 2007年06月 »

2007年05月31日

PDFと署名(35) — PFUのタイムスタンプ検証プラグインへの疑問

先日、PFUのタイムスタンプ検証プラグインについて、疑問を感じている旨をお話しました。

PDFと署名(33) — PDF署名の検証の互換性にはまる！

その後、なかなか調べる時間がとれず、と言いますか、分からないことを勉強する時間が取れないというのが、本当のところなんですが、調査は遅遅として進んでいませんが、とりあえず、ひとつ気になることがあります。

ダウンロードした検証プログラムに添付のマニュアルを読んでいましたら、このマニュアルには、PFUタイムスタンプはAcrobatのデフォルトハンドラで検証できない、と書いてあります。引用しますと、

「PFU タイムスタンプの使い方」2006年5月版　P.57/60　より　
「9.2　他のAcrobat 署名プラグインによる検証について
本製品を使用して取得したタイムスタンプ付き署名を、以下に挙げるようなAcrobat署名プラグインで検証すると、正しい検証結果を得られません。本製品とは異なる検証結果が得られますが、本製品による検証結果が正しい結果です。」

として、Acrobat 8のデフォルトハンドラが、検証できないハンドラのリストに含まれています。

しかし、このようになるのは、PDF Reference違反ではないでしょうか？

前回、PFUのサンプルPDFの署名辞書には、次のエントリがあります。

/SubFilter/adbe.pkcs7.sha1

このSubFilterエントリは、オプションですので、必須ではありません。そして、この説明に、
(Optional) A name that describes the encoding of the signature value and key information in the signature dictionary. An application may use any handler that supports this format to validate the signature.

とあります。これを見ますと、アプリケーションは、SubFilteｒで説明したフォーマットサポートする任意のハンドラを、署名を検証するのに使って良いと書いてあります。

ですので、PFUのサンプルPDFは、adbe.pkcs7.sha1をサポートするハンドラで署名を検証することを許していることになります。もし、PFUのハンドラで作った署名をAcrobatのデフォルトハンドラで検証できないのであれば、/SubFilter/adbe.pkcs7.sha1というエントリを作成してはならないのではないでしょうか？

これは、Acrobat SDKの方の問題なのかもしれません。いずれにしても、電子署名の検証を許されるハンドラが、正反対の検証結果を出してしまうのはちょっと解せません。正反対の結果をだすようなハンドラには検証を許さないようにさせないといけないのではないでしょうか。そのためには、SubFilteｒエントリを作らないようにすれば良いと思います。（まだ、確認したわけではないです。）

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月30日

「暗号解読 — ロゼッタストーンから量子暗号まで」

ここ1週間ほどで、サイモン・シンの「暗号解読 — ロゼッタストーンから量子暗号まで」新潮社刊　ISBN4-10-539302-2　を読みました。

暗号というと暗いイメージをもたれる方も多いと思います。実際、私も暗号なんて近づきたくない領域だと思っていましたが、この数ヶ月、公開鍵暗号方式を中心に少し勉強して、身近になりつつあるところで、この本を読んだのはグッドタイミングでした。

冒頭にスコットランド女王メアリー裁判の話があります。メアリーはのエリザベス女王暗殺を企てたかどで死刑になったのですが、その判決が下ったのは、メアリーと陰謀の計画者バビントンとの暗号による通信が解読されて証拠として提出されたため、というエピソードは、「弱い暗号を使うなら、使わない方が良い」という格言を強く印象付けてくれます。

また、第二次大戦前から大戦中にかけて、ドイツの「エニグマ暗号」解読についての、知恵を振り絞った戦いについても、単なる物語ではなく、エニグマ暗号機の仕組みまで技術的な面から分かりやすく解説されています。

日本の紫暗号についてもほんの少しですが、触れられています。日本海軍がミッドウエー海戦に大敗したのは、日本軍がアリューシャン列島を攻撃すると見せかけてアメリカ艦隊をひきつけておき、ミッドウエーを奇襲しようという計画が紫暗号を解読されたために、不意打ちを仕掛けた日本軍が逆に不意打ちにあった、という話です。

このあたりまでは、暗号の重要さはわかっても、既に過去の物語でもあり、現代の一般庶民には身近なものではないと感じる部分です。

しかし、第VI章「アリスとボブは鍵を公開する」という節で、コンピュータによる大量情報処理にとって鍵の配送が死活問題になっているというあたりから、急に身近な話になります。共通鍵暗号方式では、鍵の配送が最大の弱点。1970年代の米合衆国政府の鍵の管理、配送にあたったCOMSECという組織が運搬した暗号の鍵は日々何トンにものぼった、という生々しい話もあります。

公開鍵交換による鍵配送問題の解決を考案したディフィーとヘルマンの実話、RSAの公開鍵暗号方式の誕生の実話などが詳しく紹介されています。二千年以上にわたる暗号の歴史上画期的な、公開鍵暗号方式は、1970年代後半から現在にいたるインターネットの爆発に時機を一にしているということに深い感動を覚えました。必要は発明の母といいますか、見えざる神の手に導かれるようにして公開鍵暗号方式が誕生したことがよく分かります。

「暗号解読 — ロゼッタストーンから量子暗号まで」こそは、インターネット時代における暗号の重要さを認識する上でも、多くの人にお薦めしたい本です。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月29日

Window Vistaで文字化けするPDF

今日、お客さんからAntenna House PDF Viewerで文字化けするPDFがあるので、調べて欲しい、という要請がありました。早速、調べてみましたところ、このPDFは、確かにAdobe ReaderでWindowsXPでは正しく表示されます。しかし、Window Vistaで表示しますと文字化けしてしまいます。次の図をご覧ください。

■問題のPDFをWindows XP上でAdobe Readerで表示したところ。

■問題のPDFをWindows Vista上でAdobe Readerで表示したところ。

このように同じPDFの表示が、Windows XPとWindows Vistaでまったく異なってしまいます。

なぜ、こんなことが起きるのでしょうか？

このPDFの特徴は、
(1)　フォントが埋め込まれていない。
(2)　文字コードも使われていなくて、文字コードの代わりにCID（グリフID)が使われています。
(3)　CIDを使った場合、CIDを文字コードに変換するために、 ToUnicode CMAPという変換テーブルを用意しないといけないのですが、そのテーブルが用意されていません。

ですので、例えば、このPDFをWindowsXPのAdobe Readerで表示して、テキストを選択、コピーして、他のアプリケーションにペーストしますと、文字が化けてしまいます。

では、Adobe Readerで正しく表示できるのはなぜかと言いますと、このPDFのフォントはMS明朝・MSゴシックですが、フォントの Encoding が Identity-H で任意の２バイトコードになっています。そこで、推測ですが、Adobe Readerは、ＰＤＦの中のグリフＩＤを受け取って、指定されたフォントのグリフＩＤでWindowsの画面に表示しているものと思われます。

注意すべきことは、グリフIDは、フォント固有になっているのでフォント間で互換性がありません。このケースでは、たまたまPDFを作った環境とPDFを表示する環境のフォントがまったく同じなので一見正しく表示できているのでしょう。要するに偶然うまく表示できていると思います。

Windows XPのMS明朝・MSゴシックは、V2.31です。
ところが、Windows VistaではMS明朝・MSゴシックはV5で、恐らくグリフIDが変わっているため、Vistaで表示すると文字が化けてしまうものと思います。

この、PDFを正しく表示できるようにするには、

(1)フォントを埋め込むか
(2)CIDではなく、文字コードを使うか
(3)ToUnicodeCMAPを用意する

のどれかの対処が必要です。

ちなみに、このPDFは、SVF for JAVA Printで作られたものです。

そういえば、SVF for JAVA Printって、国税庁のWebでも使っていたな、と思って、確定申告のPDFを作ってみました。しかし、こちらはWindowsVistaでも文字化けしないようです。

このPDFのProducer情報

この違いは何でしょうか？

■文字化けする方のPDFは、フォントのエンコーディングがIdentity-Hになっています。

■文字化けしない方のPDFは、フォントのエンコーディングが違います。

なので、SVF for JAVA Printの設定によって変わるようです。それともバージョンによって違うのでしょうか？これは、ウイングアークに聞いてみないと分かりません。でも、Vistaが普及したらSVFで作ったPDFは、文字化け問題が頻発する懸念があります。会社によっては、10年後に、昔作った帳票PDFを見ようとしたら全部文字化けで大騒ぎ、なんてことになりかねません。

あなたの会社は、大丈夫ですか？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年05月28日

PDFと署名(34) — PDFへのタイムスタンプ付与

昨日は、少し回り道をしてしまいましたが、次は、PDFとタイムスタンプについて調べてみます。

今までに、PDFに電子証明書を使って署名することで、PDFの内容が作成後に変更または改竄された場合にはこれを検知することができるようになること、さらには、電子証明書が何らかの形で認証されているものであるならば作者本人が作成したものであることも、つまり否認防止などもできることになります。

さらに、タイムスタンプをつけることで、PDFが「いつ作成されたか」を特定できることになります。実際のビジネスでは、いつ、ということが非常に重要になるケースが多いとでしょうから、電子書類にタイムスタンプをつけるというサービスは、PDFかどうかに関わらず重要なビジネスと思われます。

タイムスタンプ・プロトコルに関する技術調査によりますと、欧米では1990年代の中ごろからタイムスタンプサービスが立ち上がっているようです。

2000年前後にタイムスタンプの標準化が図られました。2001年に電子署名に基づくタイムスタンプの標準であるRFC3161ができています。

RFC3161: Internet X.509 Public Key Infrastructure　Time-Stamp Protocol (TSP)

電子文書にタイムスタンプをつける技術はさまざまで、特許も多数ありますが、その中で、電子署名に基づくタイムスタンプ技術は、米国では、裁判で公知の技術として特許には抵触しないという認識になっているようです。

RFC3161のタイムスタンプ方式を簡単にまとめますと次のようになります。

(1)タイムスタンプを付けたい文書のハッシュ値を計算する。
(2)ハッシュ値を、信頼できるTSA（タイムスタンプ・オーソリティ）に送信する。
(3)TSAは、ハッシュ値に、TSAの秘密鍵で電子署名をして、電子署名した署名データを、要求元に送り返す。

以上で、文書のタイムスタンプデータが出来上がります。これを文書と関係つけて保存すれば、それで、タイプスタンプ付き文書となります。

ここで分かりますように、タイムススタンプを施すことで、時間のみでなく、文書の原本性（改竄されたり、変更されてない）までもが分かるようになります。

「PDF 1.6から、署名辞書の署名データ（Contentsキーの値）に含めるPKCS#7のオブジェクトに、タイムスタンプを非署名の属性として含めることができるようになりました。PDFにおけるタイムスタンプは、RFC3161準拠であり、かつ、RFC3161の付録Aに記述されているように計算され、埋め込まれなければならない」、とされています。
（PDF Reference 1.7 P.739より）

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月27日

PDFと署名(33) — PDF署名の検証の互換性にはまる！

今日は、PDFとタイムスタンプの関係を調べようと思って、PFUのWebページを見てました。

PFUタイムスタンプサービス

このページはなかなか分かりやすく、タイムスタンプのことを説明してあります。それで、少し試してみようと思い、サンプルPDFを見つけました。

サンプルPDFは、次のページにあります。
PFUタイムスタンプ for Adobe® Acrobat®（検証用）

さっそくダウンロードして、Adobe Reader8で表示しました。ところがこの署名を検証すると次のようになってしまいます。

Acrobat Reader8が英語版のため、英語のメニューなんですが、「この文書は無効（INVALID）である。署名してから、文書が変更されたか、それとも壊れている。」となってしまいます。

ちなみに、これは、Acrobat Reader8のデフォルトハンドラで検証している状態です。

次に、PFU のWebページから、検証用のプラグインをダウンロードしてインストールしてみました。
そうして、署名を検証しますと、今度は次のように、「署名が有効である」となります。

同じ署名が、検証につかうハンドラによって、「有効」と「無効」というまったく異なる結果になってしまうのですが、こういうことがあって良いのでしょうか？

なぜかなあと思って、調べ始めたら、はまってしまいました。

結論から言いますと、このPDFでは署名辞書が次のようになっています。

/SubFilter/adbe.pkcs7.sha1
/Filter/PFUP.TimeStamp
/PFUP.DigestMethod/SHA512
/Prop_Build<</Filter<</Name/PFUP.TimeStamp/

などとなっていますので、PDFのタイムスタンプ用のハンドラ（Acrobatのアドイン）で署名をしているようです。

ハッシュのダイジェスト計算にSHA512という新しいアルゴリスムを使っています。

しかし、adbe.pkcs7.sha1は、SHA1をサポートするハンドラで検証することを意味すると思います。このためにAcrobat Readerのデフォルトハンドラで検証すると、ハッシュ値の計算結果がPFUのハンドラの計算結果（署名辞書に埋め込まれている値）と違ってしまい、署名の検証結果が「無効」になるのでしょう。

原因はともかく、このような場合、Adobe Readerのデフォルトハンドラで、「無効」という相反する結果がでるのはまずいでしょう。デフォルトハンドラでは、最悪でも「不明」あるいは「検証できない」というメッセージを出すようにするべきだと思います。

このPDFは、PFUの署名・タイムスタンプ設定用プラグインで作成されているわけですが、作成時のSubFilterキーの値の設定を変更するほうが良いように思いますが、如何でしょうか？

※追記：このPFUのサンプルのPDF署名辞書の署名データ（PKCS#7形式）を調べてみたのですが、どうも、電子署名部分はSHA1になっているように見えます。つまり、タイムスタンプはSHA512で、電子署名はSHA1。しかし、これ以上はいま調べている能力も時間もありません。また、そのうち。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月26日

xfyの未来は？

今日は、ジャストシステムのxfyソリューション・フォーラムがありました。

牧野　二郎弁護士の「内部統制時代を生き抜く企業側の心構えとは」という講演は、40分間という短い時間でしたが、内容抱負で大変参考になりました。こういう講演を無料で聞かせていただいたことにまず感謝！

また、別室でxfyのデモがありました。
ジャストシステムで用意したデモ：
・J-SOX対応の文書作成
・製造業のマニュアル作成
・金融機関向けのマニュアル作成
・XBRLソリューションなど

それから、次のパートナーによる展示：
・NECネクサソリューション
・キヤノンマーケティングジャパン
・日本情報通信
・JIEC

これを一渡り見ての感想ですが、xfyの技術はホントにすごい！の一言につきます。私は、弊社のエンジニアには昔からXSL_FOをWYSIWYGで編集したいと言っても、なかなか相手にしてもらえませんでした。技術的には不可能でないことは、分かっていますけれども、xfyではそれをいとも簡単そうに実現しています。その点は、まったく脱帽するしかありません。

ただ、気になるのは市場ですね。XMLの市場というのは、なかなか大変な市場で、特に今回のデモなどを見ていますと、ジャストシステムは、xfyでかなりドキュメント系の分野に踏み込んでいるのですが、本当にドキュメントの分野でXMLのマーケットが爆発的に大きくなるのだろうか？ということです。

昨年のxfyの発表時点では、xfyでエンタープライズ・アプリケーション・フレームワークということで、IBMのDB2や、Oracle10gなどと連携し、XMLデータの入力・可視化する開発フレームワークを強調していたと記憶しています。これに対して、この半年の間で、かなりドキュメントに重点をシフトしてきたという印象を受けました。

しかし、ドキュメントのＸＭＬはなんといってもスキーマが大変で、企業内データのレベルと比べますと、かなり複雑です。複雑なため開発のコストと時間がかかり、結局、大きなシステムになるためスタートしてからできるまでに時間がかかる傾向があります。そういう分野で急激に売上を増やせるのだろうか？と他人事ながら心配になりました。

ちょうど、ジャストシステムは、5月23日に2007年3月期の決算を発表しましたが、売上高約127億円に対して、経常赤字が約21億円。連結では、売上高130億円に対して経常赤字約33億円です。

「平成19年３月期　決算短信」

その赤字はxfy事業によるものです。事業戦略説明資料によりますと、xfy事業部の赤字が約40億円(XMetal、海外を含む連結）となっています。これは、投資であるというと聞こえは良いですが、40億円のコストをかけて、2007年3月期xfyの売上はわずか5千万円(但し、XMetalを合わせた、xfy事業では2.6億円)です。発表数字によりますと、xfyの欧米での売上はゼロとなっていますので、この売上は、ほとんど国内と思われます。

xfyを発表したのは、確か2004年のXML Conference(USA)ですので、発表してから既に3年を経過しています。それで、5千万円の売上しかないというのは、少なすぎるのではないでしょうか。

例えば、米国最大のXMLドキュメント・ソリューション＆ソフトベンダであったArborText社も、結局独り立ちできずに、PTCに買収されましたが、2005年3月末時点で、4千万ドル強（約48億円）の累積赤字を抱えていました。XMLドキュメントのビジネスは、それだけ技術的にも難度が高く、営業的にも敷居が高いのです。このように見ますと、ジャストシステムのxfyへの挑戦は、ビジネスとしてみても、とんでもなく難度の高いものと思います。

それだけに、うまくビジネスとして軌道にのれば、誰も追いつけない領域を作り出せるとも言えますが。いづれにしてもここ１，２年が勝負の分かれ目。健闘を祈ります。

※ArborTextは未公開企業でしたが、PTCが公開企業のため、PTCがArborTextを買収した時に決算書が開示されました。それによりますと、2004年12月期の年間売上は、約33百万ドル(39億円）、税引前損失4百万ドル（4.8億円）となっていました。売上高を超える累積損失を抱えていたということからもXMLドキュメント・ソリューション＆ソフト・ビジネスの難しさが想像できます。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (2) | トラックバック

2007年05月25日

XSL Formatterケーススタディ：ブログ製本サービス

XSL Formatterのケーススタディに、クインランドのブログ製本サービス「QBook」が紹介されました。

詳細はこちらをご覧ください。
☞ ブログ製本サービス「Ｑｂｏｏｋ」（キューブック）

ブログのPDF化、製本サービスにつきましては、以前に何回かこのブログでも取り上げましたとおり、無償のPDF化サービスから、有償の製本サービスまで様々なサービスがあります。QBookは、それらのサービスの中でもかなり強力なシステムのように思います。

製本サービス依頼者が、(1)Webブラウザ上から、かなりこだわったページのレイアウトを指定できること、(2)オンラインの内容編集システムで、Webブラウザからブログの内容の編集や、記事の並び替えなどができること、(3)製本するまえにWebブラウザから出来具合をプレビューするためにFlashプレビューで確認できるのことなどが特徴です。

ケーススタディに次の画面が紹介されていますとおり、プレビューをPDFではなくFlashで実現したことで、出来上がりの本をイメージしやすくなっていると思います。

XSL Formatterは、サーバ上でXMLからPDFを自動生成するのに使われています。

記事の編集結果とレイアウトから、オンデマンドでPDF化されますが、さらにサーバ上でPDFはJPEGを経由してFlashのデータになります。そして、FlashのプレビューでOKがでて、発注されたならば、PDFをオンデマンド印刷システムで紙に印刷して製本すると言うシステムになっています。このあたりが完全に自動化されているのも特徴です。

クインランドのブログ製本サービスは読売新聞（2006/7/24）、産経新聞（2007/2/12）などで様々な新聞にも取り上げられていますが、それらの記事を見ますと、子育て日記をブログに書くだけではなく、さらに本にして家族や親戚に配りたい人たちに喜ばれているとのことです。ブログというWeb上の日記を、本と言う形のあるものにするということに、また別の楽しみが加わるのですね。

クインランドでは、このシステムの販売も行うとのことですので、関心をお持ちのかたは下記までどうぞ。

Ｑｂｏｏｋに関するお問い合わせ先：
株式会社クインランド　ＤＭＥＳ事業本部
企画営業部　福山氏　　TEL．　078-858-5721
システム部　遠藤氏　　TEL．　03-5408-189

【ご参考】過去のブログPDF化についてのお話
・2006年09月22日　ココログ出版　（XSL Formatter 利用例）
・2006年08月23日　ブログをPDF化するサービス　続き
・2006年08月22日　ブログをPDF化するサービス

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月24日

PDFと署名(32) — PDF署名の検証について、再び

PDF署名の検証については、既に何回かお話しました。しかし、どうも、断片的でしたので、もう一度、Adobeの「Digital Signature User Guide」に沿って、簡単にまとめてみたいと思います。以下は、Adobe Readerによる署名の検証の概要です。

○署名が有効（妥当）であるとは？
・署名に使った証明書が有効で信頼できること。すなわち、署名者の証明書から信頼できる認証元までのチェーンを作ることができて、また、署名者の証明書が失効していないこと。
・文書が署名されてから変更されていないか、もしくは許可された変更のみがなされていること。

○署名の有効性検証の結果
・有効、不明、有効でないの3つの状態になる。
・有効とは、署名が有効で信頼できる証明書に関連づけられており、かつ、文書は著者が禁止した方法では変更されていない状態
・不明とは、署名が有効性を検証できない証明書に関連づけられているか、文書に不明な変更があるか、それとも未検証の状態
・有効でないとは、署名が有効でない証明書に関連づけられているか、それとも文書は著者に禁止された変更がなされている

※PDFの署名の有効性の検証は、証明書の状態と文書の状態を完全に分離していません。本来、証明書の状態と文書の状態は完全に独立なので、検証結果を明確に分離しても良いように思うのですが。このため、Adobe ReaderのPDF署名の検証状態の表示はとても分かりにくいように感じます。

PDF署名では、署名につかったハンドラが様々になります。署名につかったハンドラと署名を検証するハンドラは同じものであることが望ましいのですが、これは代替ハンドラを使うこともできます。このことは、既にお話しました。

☞ 2007年05月10日　PDFと署名(23) — 署名ハンドラ

証明書が失効していないかどうかの検証は、証明書失効リスト（CRL)と照合するか、それとも、オンライン証明書状態プロトコル(OCSP)でチェックするかのいづれかの方法になります。そして、PDFには、通常署名とMDP署名という2種類の署名がありますが、Adobe Readerは通常署名では必ずしも証明書失効チェックは行われません。MDP署名では必ず証明書失効チェックをするようです。

☞ 2007年05月16日　PDFと署名(28) — PDFの2種類の署名

Windows証明書ストアを信頼するかどうか？
証明書の有効性を検証するには、証明書のチェインを作ることになりますが、証明書のチェインはルート証明書に行き着きます。「Windows証明書ストアには、メーカからの出荷時に、様々なルート証明書が入っていますし、なんらかの拍子に、ルート証明書がWindows証明書ストアに入ってしまうことがあります。そこで、個人ユーザは、Windows証明書ストアを信頼しない方が良い。企業ユーザは、管理者が遠隔操作でWindows証明書ストアを管理できるので、信頼しても良い。」（「Digital Signature User Guide」P.88 6.2.3 Using Root Certificates in the Windows Certificate Storeより）。」

証明書を直接入手した場合、その証明書を信頼する証明書のリストに追加できます。

こうしてみますと、Adobe Readerによる署名の検証結果については、それを左右する様々な要因があり、署名検証の運用管理は注意深く要因を管理しなければならないでしょう。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月23日

GreenPDF.com　PDFで地球温暖化を救う！

PDFを印刷するのをやめて、地球温暖化防止に貢献しよう！という運動を推進する「GreenPDF.com」ができました。

GreenPDF.com

このWebページにPDFをアップすると、PDFに「印刷を減らそうというメッセージ・バナー」を付けてくれるということらしい。試しに早速、PDFをアップしてみました。

そうしますと、戻ってきたPDFには、開く度に次のようなバナーがでるようになります。

このバナーには、「このPDFを印刷しないことを考えよう！」というメッセージが書かれています。

うーーん、こんなことをまじめにやっている人がいるとはちょっと信じ難いですが。

GreenPDF.comについては、先日、フロリダで開かれたPDF Conferenceでプレゼンテーションがあったようです。

GreenPDFのプレゼンテーション資料（ちょっと大きなPDFです）

Planet PDFに、プレゼンの印象が載っています。
Disney World wows -- PDF 2007 Conference wrap-up

GreenPDF運動のスポンサーは、FormRouterという会社と、Global Warming Initiatives, INC という団体だそうで、スラッシュドット・ジャパンにも、彼らのニュースが紹介されています。
地球温暖化防止のためにPDFを印刷しない運動

スラッシュドットのコメンタを読みますと、コメンタ達は、どちらかというとPDFが嫌いな人が多いようですね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月22日

Antenna House PDF Convert! 3 (英語版）を発売

アンテナハウスでは、「リッチテキストPDF3 D&D」の英語版、「Antenna House PDF Convert! 3」を本日から発売しました。

詳細はこちらをご覧ください。

「PDF Convert!3」

いままで、弊社では、システム製品（主にサーバライセンス）の英語版はいろいろと販売してきましたが、廉価版のデスクトップ製品の英語版を出すのは本製品が初めてです。

以前に、
# 第525話　2007年03月25日 PDFからWord、Excel変換ソフトの評価　（3）
# 第522話　2007年03月22日 PDFからWord、Excel変換ソフトの評価　（2）
# 第521話　2007年03月21日 PDFからWord、Excel変換ソフトの評価　（１）

などで、海外のPDFからWord/Excelへの変換を行う製品と「リッチテキストPDF3」との変換精度を幾つか比較してみましたが、「リッチテキストPDF3」は海外製品と比較しても十分競争力があると判断しました。ただし、「リッチテキストPDF3」の方は、機能が多いので英語版を作るのは少し時間がかかります。そこで、とりあえず、「リッチテキストPDF3D&D」を英語版にしたものです。

PDF Convert!3は、インストーラとヘルプは英語版ですが、GUIはWindowsの地域と言語が日本語であれば、日本語メニューを表すようになっていますので、日本語Windowsでも問題なく使えます。

次のバージョンからは、「リッチテキストPDF3」の方も英語版を用意していきたいと思っています。アンテナハウスは、2002年頃から海外での販売に力を入れており、現在、海外子会社を含む連結売上の約30%が海外売上となっています。これらの経験から判断しまして、日本のソフト製品は十分海外で通用すると思います。問題は、販売のノウハウ、販売網、ブランドなど、どちらかと言いますと、技術よりマーケティングになると思います。そのあたりの経験を増やしていくのが当面の課題と考えています。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月21日

PDFと署名(31) — PDFの署名値について

先日、PDFに署名するときルート証明書の情報は不要ではないかと言いましたが、もしかすると誤りかもしれません。これについて、PDF Reference 1.7の関連する箇所を調べてみました。

2007年05月19日 PDFと署名(30) — PDFの署名の検証

PDFの署名辞書について、まず、表8.98を見ますと、次のようになっています。
Contentsキー
(必須)署名値。ByteRangeキーが存在するとき、バイトレンジ・ダイジェストの値を表す16進の文字列。ByteRangeキーが存在しないとき、Contentsエントリを除く、署名辞書のオブジェクト・ダイジェストの値。公開鍵署名では、Contentsは一般的にDER符号化のPKCS#1バイナリ・データオブジェクト、または、DER符号化のPKCS#7バイナリ・データ・オブジェクトである。
Certキー
(SubFilterキーがadobe.x509.rsa_sha1のとき必須。それ以外では使わない)（中略）
SubFilterがadbe.pkcs7.detachedまたはadbe.pkcs7.sha1の時、このエントリは使わない。そして証明書のチェーンをContentsキーのPKCS#7封筒に入れなければならない。(2007/5/22 注）

ということは、証明書のチェーンを作成して、署名値の中に入れなければならないようです。

さらに、8.7.2署名の互換性という項を見ますと、PKCS#7署名については、最低限、署名者のX.509署名用証明書を含まねばならない、となっています。ここと、下の部分の記述からしますと、ルート証明書は必須ではないようにも見えます。果たしてルート証明書をPDFの署名辞書に埋め込まねばならないのかどうか、説明があまり明確ではないように思います。どうなんでしょうね？

ところで、PKCS#7オブジェクトは、オプションとして次の属性をもつことができます。

・RFC3161に準拠するタイムスタンプ　（PDF1.6～）
・署名された属性として、証明書検証情報　（PDF1.6～）
・署名者の信頼チェインから、一つ以上の発行者証明書　（PDF1.6～）
・署名者の証明書に関連するRFC3281属性証明書、一つ以上　（PDF1.7～）

このあたりの説明は、PDF Reference1.5とPDF Reference1.6の間でかなり変更になりました。また、PDF Reference 1.7でも少し変更になっており、PDFの電子署名機能は、最近になって変更され固まってきたと言えそうです。

注）2007年5月22日追記
この部分ですが、「もしSubFilterがadbe.pkcs7.detachedかadbe.pkcs7.sha1の場合に証明書チェーンを埋め込む場合は、PKCS#7のデータ中に埋め込む必要がある。」
と解釈すべきではないか、というコメントがありました。確かにそういう風に解釈できるようにも思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月20日

FrameMaker の復活まぢか！　PDF保存、3次元PDFサポート

Adobeのテクニカル・コミュニケーション・チームのブログ(5月8日）で、FrameMaker8のβ1版が、現在、テスト段階に入っているという話が出ています。
FrameMaker Beta is here...
また、β2版のテスターを募集しています。

また、USでは既に、FrameMaker8の情報がいろいろな形でリークされ始めたようです。
5月13日から16日にミネアポリスで開催された、STCセミナー（Adobe がゴールド・スポンサー）で、Adobeのマネージャが、FrameMaker8について講演したようです。
Adobeがスポンサーになったセッションがありますので、恐らく、そこで講演したのでしょう。
参加者のブログに、簡単なメモがのっています。

アドビのユーザ間のフォーラム：
http://www.adobeforums.com/cgi-bin/webx?13@@.3bc3daae/3
Palimpsest(ブログ)：
http://www.scriptorium.com/palimpsest/labels/FrameMaker.html

※参考「2007年02月05日FrameMaker 復活？」

ところで、ＳＴＣ Conferenceのセッションを見てましたら、DITAに関するセッションが多いですね。

■Technical Communiｃation Summits
Session Materials:
○Case Studies in Structured Authoring, XML, and DITA..
・Dupont, Jay
　"A Do it Yourself Dita Pilot Project"
・Kadilak, Denise
　"Implementing Structured Documentation"
・Petrie, Guy
　"Industrial-Strength Single-Sourcing: Using Topics to Slay the Monster Project"

○DITA Evolves...
・Priestley, Michael
　"DITA Evolves"

○Real-World DITA...
・Sliwinski, Larissa　
　"DITA at Business Objects "

○Reviewing DITA Support in Tools...
・Manning, Steve
　"Reviewing DITA support in tools"

※上記のセッションのプレゼン内容は大抵Web上にアップされています。

DITAサポートツールのレビューで、弊社のXSL Formatterが紹介されていました。

「PDFを作るための非常に強力なformatterで、ToolKitの代替を提供している。しかし、PDFしか。。」
う～ん、PDFの他に何が欲しいのかな？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月19日

PDFと署名(30) — PDFの署名の検証

さて、今週は、水曜日から金曜日3日間ソフトウェア開発環境展ということで、3日間のうち半分ほどは、国際展示場に行っていました。弊社は、このところ、ソフトウエア・コンポーネントの販売が好調で、だんだん、パッケージ会社からソフトウエア・コンポーネント会社に事業の中心がシフトしつつあります。そういう意味では、今年のソフトウェア開発環境展は丁度良い機会でした。

ブースでは、XSL Formatterを初め、PDF製品を出展して説明させていただきましたが、大勢の方に関心をもっていただき、また、説明を聞いていただいた方も多く、本当にありがとうございました。

今回、参考出品した「PDF電子署名モジュール」を目当てにお立ち寄りいただいた方も予想外に多く、商品化に向けて、ますます張り切っていきたいと思います。さて、「PDF電子署名モジュール」関係で幾つか、ご質問をいただきました。その中に、

○PDFの署名にルート証明書が付くかどうか、

という御質問がありました。

これは、Acrobatを初め、PDFの署名にSelfSign方式を使っているため、いわゆる、PKI（公開鍵インフラ）の立場から見て、「PDFの署名の信頼度はどうなんだろう？」という疑問をもたれているのではないか、と推察しました。

この質問に対してお答えするため、まず、「PDF電子署名モジュール」では、どのような「秘密鍵＋電子証明書」を使うかについてQ&A形式で整理してみます。

質問：認証局が発行した証明書は使えますか？

回答：使えます。「PDF電子署名モジュール」（参考出品版）では、Windowsの証明書ストアに証明書を登録して、Windows証明書ストア用のAPIを使って署名をします。ですので、Windowsの証明書ストアに入れることのできる電子証明書であれば、任意のものが利用可能です。

質問：自己署名（Self-Sign）証明書は使えますか？

回答：使えます。「PDF電子署名モジュール」（参考出品版）には、自己署名証明書を発行する機能も付いています。また、自己署名証明書は、Windowsの証明書ストアに入れることができます。

質問：Windowsの証明書ストアとは何ですか？

回答：Windows標準の証明書管理領域を、証明書ストアと言います。Internet Explorerの[ツール]－[インターネットオプション]の[コンテンツ]タブから[証明書]ボタンをクリックして証明書ストアに格納されている証明書を確認することができます。Windows環境では、証明書と秘密鍵を証明書ストアに入れて利用する方法が一般的です。

[Windows証明書ストア]

さて、そこで、最初の「PDFの署名にルート証明書が付くかどうか」という御質問ですが、電子署名したPDFには、PDFの指定した範囲のハッシュ値を秘密鍵で暗号化したデータと、その秘密鍵のペアである公開鍵証明書（電子証明書）を埋め込みます。ですので、ルート証明書が署名されたPDFの中に付くわけではありません。

ルート証明書は、PDFに埋め込まれた電子証明書を検証するために使うのですが、その際、署名を検証する環境で、PDFの中の電子証明書からルート証明書までのチェーンができれば、ルート証明書の役割は終わりです。そういう意味では、ルート証明書は署名を検証するPC環境にあるか、あるいはインターネット経由でアクセスできれば良いのであって、「電子署名をしたPDFの中にルート証明書を入れる必要はもともとありません。」ということになります。

上記アンダーラインの部分、PDF Referenceを確認しましたところ、間違っているのかもしれません。

☞ 5月21日へ続く

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年05月18日

PDFと署名(29) — MDP署名のダイジェストの計算

先日、PDFの署名には、(1)普通の署名と(2)MDP署名（有効な証明用署名）の2種類があることを説明しました。
2007年05月16日　PDFと署名(28) — PDFの2種類の署名

普通の電子署名では、署名を付けたい文書のハッシュ値を計算します。そして、そのハッシュ値を秘密鍵で暗号化することになります。PDFの場合、(1)普通の署名では、PDF文書の中の指定した範囲（バイトレンジで指定。通常は、署名辞書の署名の値以外の部分）のハッシュ値を計算します。

MDP署名では、ハッシュ値の計算の過程で、「オブジェクト・ダイジェスト」という特別な方法が使われることがあります。

簡単に言いますと、コンピュータのメモリ中のPDFオブジェクトのツリーの中で指定したオブジェクトを辿ってダイジェストを計算する対象となるデータストリームを生成する方式です。オブジェクト・ダイジェストの方法については、PDF Reference1.7では付録I Computation of Object Digestsに説明されています。

この計算方法は、単純な文書のダイジェスト計算と比べてかなり面倒なようです。電子署名では、ソフトウエアAで作成したPDFの電子署名をソフトウエアBで検証する場合もありますので、互換性が重要なのですが、あまり複雑だと完全な互換性が実現できるのだろうかと、少し心配になったりします。

そのためかどうか分かりませんが、MDP署名の検証方法は、PDF 1.5とPDF 1.6以降でかなり変わっています。

MDP署名の検証（PDF Reference 1.7 pp.732－733)
「PDF 1.5は、署名の時点でのオブジェクト・ダイジェストの計算値が、署名参照辞書(表8-103)のDigestValueエントリに保存されることを要求する。従って、アプリケーションはこのエントリを、検証の時点で計算されたオブジェクト・ダイジェストと比較することができる。もし、値が違っているならば、署名は妥当でないものである。
PDF 1.6では、DigestValueエントリは要求されない。バイトレンジ・ダイジェストを検証したならば、署名辞書(表8-102)のバイトレンジ・エントリで指定される文書の部分が署名の時点での文書の状態に対応するものと知られる。従って、アプリケーションは署名されたものと現行の文書バージョンを比較することができ、それによって変換パラメータで許可されない任意のオブジェクトに対して修正があったかどうかを知ることができる。付録Hの実装メモを参照。」

これを読む限り、PDF 1.6～では、MDP署名において、著者が変更を許可していない部分についてはオブジェクト・ダイジェストを計算するのは止めてしまったように見えます。ともかく、PDF 1.5と1.6～では、MDP署名の検証方法が根本的に変わっていることになります。恐らくは実装上の都合と思いますが、PDFの仕様がこのように変わっているのは注意が必要です。

※米国の専門家のPDFの仕様についての意見を読んでいても、PDFの仕様はPDF Referenceではなく、Adobe製品（つまり実装が仕様）であるということが問題である、と書かれていました。ISO標準になれば、Adobe 製品の実装が標準である、という態度は許されなくなります。早くISO標準になって変わって欲しいところです。

なお、MDP署名で著者が、フォーム・フィールドや注釈などに変更を許す時は、その部分は、フィールドMDP変換という方法で署名参照辞書が作られて、検証されます。フィールドMDPは、フォーム・フィールドのリストに対してオブジェクト・ダイジェストを計算する方法です。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月17日

Acrobat 3D Version 8を発表、Acrobat Elementは、7で終了？

アドビ・ジャパンはAcrobat 3D Version 8を6月中旬から発売すると発表しました。

アドビ システムズ社、ADOBE ACROBAT 3D VERSION 8 日本語版の提供開始を発表

これは、3次元CADのデータを3次元のPDFに変換するもの。

ニュース・リリースは出ていませんが、日経パソコン・オンラインによると同じ日に、Acrobat 8についても幾つか発表も行ったようです。
http://cmad.nikkeibp.co.jp/?4_6286_143439_3

この記事を見ますと、まず、Acrobat 8のスタンダードとプロフェッショナルのVista対応版が5月下旬にでるようです。

それから、興味深いことに、Acrobat Elementのパッケージ版は販売を終了するようです。
廉価パッケージは、ほとんど収益に貢献しないということが分かったのでしょうね。
収益に貢献しない廉価版はさっさと止めるのは正解だと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月16日

PDFと署名(28) — PDFの2種類の署名

2007年05月14日　PDFと署名(26) — Adobe Readerによる署名されたPDFの検証で、署名されたPDFの検証で「有効な証明用署名を含んでいる」という状態と、「署名が有効である」という２つの有効な状態があることをお話しました。

この二つの状態は、Acrobat8では次の二つのメニューに対応しています。

○署名が有効である：アドバンスト->電子署名->この文書に署名
○有効な証明用署名：アドバンスト->電子署名->可視署名を使用して署名、または、可視署名を使用しないで署名

この二つがどう違うかをもう少し見てみますと、
（1）「有効な証明用署名」の方は、文書の作者または1人しか署名できません。そして、これは、PDF Reference1.7では、MDP（修正検出・防止（modification detection and preventionの頭文字））署名として説明されているものに相当します。MDP署名は、PDF文書に最大でも1個しか存在できません。

（2）一方の、「文書が有効である」の署名の方は、document：文書（ordinary：普通）署名とされています。これは複数存在することができます。

さらに、MDP署名をすると、署名者が文書を修正することについての許可（Permission）を与えることができます。この許可は、「変更を許可しない」、「フォームフィールドの入力と署名フィールドに署名を許可」、「注釈の作成、フォームフィールドの入力と署名フィールドに署名を許可」の3段階となり、PDFの中では、電子署名用の許可辞書（8.7.3Permissions）に記録されます。

パスワードによるセキュリティハンドラでも同じようなユーザへの許可を与えることができます。
※パスワードによる許可制御についてはこちらをご覧ください。
2006年11月13日　PDFのセキュリティ機能（3）—PDFの利用許可制御

電子署名の許可辞書の設定はパスワード・セキュリティによるユーザの許可設定とは別物です。パスワードによる許可辞書と違って文書を暗号化するわけではありません。署名を検証する側にとってもMDP署名をサポートするには、利用許可設定の内容に沿った修正かどうかを検出しなければならないことになります。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月15日

PDFと署名(27) — SODEC で、PDF電子署名モジュールを参考出品

いよいよ、明日から年に1度のSODEC開催！アンテナハウスも[ブース番号：東11-8（プロジェクト管理ゾーン内）]にてシステム製品を中心に主要製品を出展します。

ブログでずっとPDFと電子署名について書いてきましたので、もう公然の秘密ですが、弊社では、ずっとPDFの電子署名ツールの開発を行ってまいりました。その第一弾として、サーバサイドのシステムに組み込んで使うための「PDF電子署名モジュール」を近い将来リリースする予定です。

そこで、SODECでは、じゃーーん！開発中のPDF電子署名モジュールをXSL Formatterと連携するデモをご覧いただきたいと思います。

○ポスター

（画像をクリックしますとPDFが表示されます）。

PDF電子署名モジュールは、予め設定した電子署名関連の情報をPDFに設定するものです。

電子署名関連の情報とは、
・PDFに電子署名を付与
・PDFの署名辞書に書き込む情報（署名理由、署名場所、署名者連絡先）
・タイムスタンプ（タイムスタンプ・サーバより取得）
・電子署名の外観（印影など）
などです。

Windowsの証明書ストアに登録されている証明書を使うことができます。PDF電子署名モジュールは、Windowsの証明書ストアと連携して、秘密鍵で署名したデータと電子証明書をPDFに埋め込むことになります。タイムスタンプは予め指定したタイムスタンプ・サーバから取得します。

XSL Formatterとの連携では、XSL Formatterで電子署名の外観を付加したい領域を指定しておくことで、指定位置に電子署名の印影をつけることができます。

ダイナミックに変化するコンテンツをFormatterで組版した結果によってできあがるページ数が変化する場合、印影をつける位置（ページ番号とそのページ内の座標）が変わる可能性があります。そのように印影をつける位置が、コンテンツ依存で変更になっても対応できます。このあたりは、単純な固定フォーマットの帳票ソフトでは、実現が難しいところと思いますが、XSL Formatterのようなドキュメント組版ソフトでは簡単に実現できます。

また、電子署名とリニアライズ、電子署名とパスワードによるセキュリティ設定などを組み合わせることもできます。

今後、お客様のご意見を伺って、製品の詳細な仕様を詰めて行きたいと考えていますので、関心をお持ちの方は、ぜひ、SODECでデモをご覧頂き、忌憚のないご意見をいただければと思います。なにとぞ、よろしくお願いします。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月14日

PDFと署名(26) — Adobe Readerによる署名されたPDFの検証

Adobe Readerで署名付きのPDFを開きますと、次の例のように署名の状態を確認することができます。

Adobe Readerのヘルプを見ますと、署名の状態を示すアイコンには、次の6種類があるとされ、簡単な説明文がついています。
(1)：未署名の署名フィールド
(2)：PDF が証明済みであること、つまり有効な証明用署名を含んでいる
(3)：署名が有効である
(4)：署名が無効である
(5)：署名後に文書が変更されている
(6)：信頼済み証明書の一覧に署名者の証明書がないために署名が検証できなかった

これらのアイコンと説明はなんとなく分かりそうですが、よく考えると分からないですね。そこで、「Digital Signature User Guide」の説明を見て、もう少し調べてみました。

(1)最初の未署名の署名フィールドについては、既に、ブログでお話しました。
(2)次の、「有効な証明用署名を含んでいる」のアイコンは、証明プロセスを使って証明し、かつ、この署名者が第一番目の署名者であり、かつ、文書が署名後に変更されていないか、許可された範囲で変更されていることを示す。
※この証明プロセスで技術的にどんな処理をしているのか、(2)との違いについては、さらに調べてみる必要があります。
(3)「署名が有効である」というのは、有効な証明書を使って署名されており、また、署名後に不正な変更がないことを示しています。
(4)「署名が無効である」とは、証明書が不正か、それとも、文書に許可されない変更がなされていること。
(5)「署名後に文書が変更されている」は、証明書が検証できず、かつ、文書に予め許可された変更がなされているということを示します。
(6)最後は、証明書を検証することができないか、文書の検証を完了できなかった。

なお、この他に、との不明状態が紹介されています。前者は証明書の信頼性を検証できず、かつ、文書が署名後に変更されていること、後者は、証明書の信頼性を検証できず、かつ、文書は署名後に変更されていない状態を示すようです。

このようにPDFの検証では、(a)電子証明書の検証、(b)文書内容の変更の検証があり、さらに文書内容の変更では、予め許可された変更は妥当ですが、許可されていない変更は不正となります。このように状態が多いので複雑です。

参考資料：「Digital Signature User Guide Acrobat and Adobe Reader Version 8」2007年2月27日

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月13日

PDFと署名(25) — 署名の外観

PDFでは電子署名に印影やサインなどの外観をつけることができます。

例えば、次の図のように署名者の印影を付与するために外観を使います。

一般に、PDFのフィールドには、外観をwidget注釈で設定できるのですが、署名はフィールドの一種として扱われますので、署名の外観をwidget注釈で設定できるわけです。この概観は、本来の目的である電子署名されたPDFを検証するために必要なものではなく、外観のない署名[不可視署名]も許されます。

書名付きのPDFをAdobe Reader8で表示しますと、次のようにアイコンとツールチップが表示されます。

このアイコンとツールチップは、Adobe Reader（プログラム）で表示しているもので、PDFの中に埋め込まれているものではありません。

この署名の外観のために、widget注釈の外観辞書（AP辞書）をどのように設定するかは、原則として、注釈のAP辞書の仕様に基づいていれば問題はないはずです。しかし、各署名ハンドラが勝手にすると、ユーザが混乱を招くということで、「Digital Signature Appearances　（Acrobat 6）」にガイドラインがあります。

参考資料：Digital Signature Appearances　（Acrobat 6）

これを読みますと、Adobe自体が、Acrobat 6でかなり大幅に署名の外観の取り扱いを変更したことがわかります。すなわち、Acrobat 4/5では、署名の外観を、署名の検証状態と対応して、未検証だと「？」を表示、検証結果が不可では「×」を表示するように変化させるため、AP辞書にそのためのデータを埋め込んでいました。

ところが、Acrobat 6からは、現在のように、アイコンとツールチップを表示する方法に変わっています。
現在のAcrobat は、Acrobat 4/5で作成した電子署名の外観を同じように取り扱える下方互換機能をもっていますので、Acrobat 4/5の古い電子署名とAcrobat 6以降の新しい電子署名で外観の表示が変わるはずです。

このように、Acrobatでは、署名の外観の取り扱いも、Acrobat 4/5と6～で変わっている、ということに注意しなければなりません。なお、ガイドラインではサードパーティはAcrobat 6～と同じように外観を作ることが推奨されています。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月12日

PDFと署名(24) — PDFの署名が複雑な事情

PDFの署名は、次の二つの点で非常に込み入っています。

○その第一はPDF Referenceで決める署名の付け方が込み入っていることです。

署名は対話フォーム（AcroForm)の一種である「署名フィールド」として定義されており、まず署名フィールドを作って、署名すると、そこに署名辞書ができます。

またPDF署名には外観をつけることができ、署名の外観は注釈の一種として定義されます。この署名に外観をつけるというのは、PDF特有の機能になります。

そこで、署名辞書のない（未署名の）署名フィールド、署名済みの署名フィールド、外観のある署名、外観のない署名などのパターンができてしまいます。このようにPDF署名は、署名する・しないという単純な状態ではなく、複雑な状態をもつため、ユーザが理解するのがとても難しくなってしまいます。

○その第二は、PDFの署名は、PDF Reference 1.3（Acrobat4）で初めて導入された比較的新しい機能ですが、その後、PDF Reference 1.5（Acrobat6）で大幅に変更になっています。つまりPDFのバージョンによって大幅に変更になっている点がある、ということです。

これを示すために、署名に関連する各種の辞書のキーがPDF1.3からPDF1.5でどのように変わったかを表にしてみました。次の表を見ますと、PDF 1.5で署名関連の辞書が大幅に変更になっていることが一目瞭然です。また、PDF1.6、PDF1.7で細かい仕様拡張が行われています。

○フィールド辞書のキー

Field Dictionary
	PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
	FT	FT	FT	FT	FT
	FT	Parent	Parent	Parent	Parent
	Parent	Kids	Kids	Kids	Kids
	Kids	T	T	T	T
	T	TU	TU	TU	TU
	TU	TM	TM	TM	TM
	TM	Ff	Ff	Ff	Ff
	V	V	V	V	V
	DV	DV	DV	DV	DV
	AA	AA	AA	AA	AA
/FT /Sig固有			Lock	Lock	Lock
			SV	SV	SV

○Lock辞書

Lock
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		Action	Action	Action
		Fields	Fields	Fields

○SV辞書

SV
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		Filter	Filter	Filter
		SubFilter	SubFilter	SubFilter
				DigestMethod
		V	V	V
		Cert	Cert	Cert
		Reasons	Reasons	Reasons
			MDP	MDP
			TimeStamp	TimeStamp
			LegalAttestation	LegalAttestation
				AddRevinfo
		Ff	Ff	Ff

○SVのCert辞書

Cert
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		Subject	Subject	Subject
				SubjectDN
				KeyUsage
		Issuer	Issuer	Issuer
		OID	OID	OID
		URL	URL	URL
				URLType
		Ff	Ff	Ff

○署名辞書のキー

署名辞書
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
Type	Type	Type	Type	Type
Filter	Filter	Filter	Filter	Filter
SubFilter	SubFilter	SubFilter	SubFilter	SubFilter
Contents	Contents	Contents	Contents	Contents
		Cert	Cert	Cert
ByteRange	ByteRange	ByteRange	ByteRange	ByteRange
		Reference	Reference	Reference
		Changes	Changes	Changes
Name	Name	Name	Name	Name
M	M	M	M	M
Location	Location	Location	Location	Location
Reason	Reason	Reason	Reason	Reason
		ContactInfo	ContactInfo	ContactInfo
		R	R	R
		V	V	V : 署名辞書形式のバージョン
		Prop_Build	Prop_Build	Prop_Build
		Prop_AuthTime	Prop_AuthTime	Prop_AuthTime
		PropAuthType	PropAuthType	PropAuthType

○reference 辞書

reference
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		TransformMethod	TransformMethod	TransformMethod : DocMDP, UR, FiledMDP, Identity
		TransformParams	TransformParams	TransformParams
		Data	Data	Data
		DigestMethod	DigestMethod	DigestMethod
		DigestValue	DigestValue	DigestValue
		DigestLocation	DigestLocation	DigestLocation

○DocMDP TransformParam 辞書

DocMDP TransformParam
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		P	P	P
		V	V	V

○UR TransformParam 辞書

UR TransformParam
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		Document	Document	Document
		Msg	Msg	Msg
		V	V	V
		Annots	Annots	Annots
		Form	Form	Form
			FormEx	FormEx
		Signature	Signature	Signature
			EF	EF
			P	P

○FieldMDP 辞書

FieldMDP
PDF 1.3	PDF 1.4	PDF 1.5	PDF 1.6	PDF 1.7
		Type	Type	Type
		Action	Action	Action
		Fields	Fields	Fields
		V	V	V

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月11日

PDF Driver V3.2とPDF Tool V2.6を発売

本日より、Antenna House PDF Driver V3.2をリリースします。これに伴い、Antenna House PDF Tool も同時にバージョンアップを行いV2.6とします。

PDF Driver V3.2は、V3.1MR2から次の2点が変更になっています。
(1) JIS X0213の全文字 (11,233文字） を正しく扱えるようになりました。
JIS X0213:2004の中でUnicodeの補助面に割り当てられている303文字とUnicodeに単独のコードポイントがなく合成文字で表す25文字を、WindowsVistaのメイリオとMS 明朝V5、MSゴシックV5フォントについて正しく取り扱いができるようになりました。
(2) 設定ファイルの保存先フォルダを変更しました。
ユーザが作成した設定ファイルの保存先が、V3.1 までは PDF Driver のインストール先でしたが、V3.2 からは「アプリケーションデータフォルダ」に格納するようにしました。

Windows Vistaに標準搭載されている、メイリオとMS 明朝V5、MSゴシックV5フォントは、JIS X0213:2004の全文字のグリフを持っています。ところがこの中の303文字がUnicodeの補助面（UTF-16ではサロゲートペアで表す）に割り当てられていることと、25文字がUnicodeにコードポイントがなく、合成文字で表さなければならないためアプリケーションの改造が必要になる、ということを以前にお話しました。

・2007年01月04日　Windows Vista と日本語文字コード問題（1）
・2007年01月05日　Windows Vista と日本語文字コード問題（2）
・2007年01月06日　Windows Vista と日本語文字コード問題（3）
・2007年01月07日　Windows Vista と日本語文字コード問題（4）

Antenna House PDF Driver V3.2は、PDF作成時に、これらの文字をフォント埋め込みしてAdobe Readerなどで表示可能にすると共に、グリフからUnicodeへのコード変換表をPDFに用意することで検索も可能にするよう改良しました。これによって、これらの文字を含め、JIS X0213:2004の全文字を正しく取り扱いできるようになりました。

私どもの調査では、Adobe Acrobat 8のPDF Driverは、JIS X0213:2004の全文字を正しく扱えるようですが、それ以外の製品は正しく扱うことができません。例えば、SKY PDF Pro Driver（V2.53) は前記303文字のフォントの埋め込みはできますが、グリフからUnicodeへのコード変換表が正しく作られないため、それらの文字を検索できません。クセロのPDF Driver（2.00β3）は、前記303文字のフォントを埋め込むことさえもできません。

Adobe Acrobat 8は、Windows Vistaにも、Office 2007にも正式対応していません。従って、現時点で、
Antenna House PDF Driver V3.2が、Windows Vista、Office2007対応を正式に保証し、かつ、JIS X0213:2004全文字を使える唯一のPDFドライバということになります。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月10日

PDFと署名(23) — 署名ハンドラ

PDF署名では、様々な署名処理プログラムを使うことができます。これを署名ハンドラと言います。署名に使ったハンドラの名前と、それを検証するための望ましい署名ハンドラの名前が、作成されたPDFの中の署名辞書に保存されています。

独自の署名ハンドラを使って署名をつけた場合、署名のついたPDFをAdobe Readerで開いて、その署名を検証しようとしたとき、署名に使ったハンドラがパソコンにないと、次の図のようなメッセージが出ることがあります。

【例】PDF内の辞書に記録された署名ハンドラが、検証するPCにないとき

署名に使ったハンドラがないとまったく検証できない、ということでは不便ですので、互換な署名ハンドラでも検証できるようになっています。

署名辞書では、検証のために使うのが望ましい署名ハンドラがFilterに登録されています。さらに、SubFilterには、どのような署名のアルゴリズムを使ったかを表すキーワードを記録することになっています。そこで、SubFilterの内容をチェックして、そのキーワードに示した形式をサポートする任意の互換ハンドラで検証することができます。

SubFilterの定義済みのキーワードは、adbe.pkcs7.detached, adbe.pkcs7.sha1, adbe.x509.rsa_sha1の３つです。

先ほどのPDFを見ますと、署名辞書（一部）には、

/Type /Sig
/Filter /MDIS.SignedPDF
/SubFilter /adbe.pkcs7.detached

となっていて、MDIS.SignedPDFという三菱電機インフォーメーションシステムズ社の署名ハンドラで署名を検証するのが良いということを示しています。

SubFilterは、adbe.pkcs7.detachedとなっています。adbe.pkcs7.detachedは、次のアルゴリズムをサポートしています。
○メッセージのダイジェスト
SHA1 (PDF 1.3)
SHA256 (PDF 1.6)
SHA384 (PDF 1.7)
SHA512 (PDF 1.7)
RIPEMD160 (PDF 1.7)

○RSA公開鍵暗号化アルゴリズム
1024-bit まで(PDF 1.3)
2048-bit まで (PDF 1.5)
4096-bit まで(PDF 1.5)

○DSA アルゴリズムのサポート
4096-bitsまで (PDF 1.6)

そこで、adbe.pkcs7.detachedの形式をサポートする署名ハンドラを使っても良いということです。上の例では、AdobeReaderについている標準の署名ハンドラ（多分、PPKLiteプラグインの中にある）を、MDIS.SignedPDFの代わりに使って検証ができるようです。(但し、完全ではないと思います）。

このあたりの署名ハンドラの互換性は、もっと明瞭・厳密な仕様が必要なように思います。早くISO標準になって欲しいですね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月09日

PDFと署名(22) — PDFと公開鍵暗号

PDFと公開鍵暗号の関係について、PDF Referenceから整理してみます。

まず、PDFでは、公開鍵暗号を(1)暗号化と(2)署名の二通りの方法で利用できます。
(1)暗号化は、PDFを渡したい相手の公開鍵を使ってPDFを暗号化する機能です。PDFのセキュリティで一般的なのはパスワードによる暗号化です。これは相手によらずPDFを一定のパスワードで暗号化します。それに対して公開鍵による暗号化では、PDFを渡したい相手の公開鍵を使って暗号化しますので、相手毎に異なる条件でセキュリィを設定することができます。

この公開鍵暗号化によるPDFのセキュリティについては、既に、2006年11月19日 PDFのセキュリティ機能（7）—公開鍵セキュリティ・ハンドラで概略を紹介しています。

(2)署名は、PDF文書への電子署名です。一般文書への電子署名と同じように、PDF署名では、署名した人が誰かを確認したり、あるいは、文書の署名者に否認防止（知らないよと言わせない）、改竄の有無の検出を行うことができます。さらに、PDF署名は様々な高度な署名の利用ができることになっています。

PDF Referenceで規定しているPDF電子署名の仕様概要は以下の通りです。

注意しなければならないのは、仕様として規定されていても、それを正しく実装したアプリケーションがないと利用できないことです。さらに、正しく実装するだけではなく、それが簡単に使いこなせないと活用できません。また、身近に使いこなすには、安価なツールも必要になります。そういうツールがないと絵に描いた餅になってしまいます。とりあえずは、絵に描いた餅だと思って読んでみてください。

１．PDFでは、署名は署名ハンドラが取り扱います。この署名ハンドラは、プラグインとして実現でき、独自の様々な機能も実現できます。つまり、自分でハンドラを書いて特殊なこともできるというわけです。

２．署名の情報は、PDFの中の署名辞書に登録されます。署名ハンドラは、署名辞書に独自のエントリを定義することもできます。

３．署名は、データまたはデータの一部のダイジェストを計算し、それをPDFの中の保存することで作成します。署名の検証では、ダイジェストを再計算し、PDFの中に保存されていた値と比較します。もし、一致すれば、文書は変更されていないことになりますが、不一致になりますと文書が署名されてから変更されたことになります。

４．PDFではダイジェストを計算する方法に二つの方法があります。第一は文書の中の全体または特定領域の範囲を指定して計算する方法。第二はメモリの中の特定のオブジェクトを辿ってダイジェストを計算する方法です。この第二の方法はPDF独自ではないでしょうか。これによって、かなり複雑なPDF独自の署名機能を実現できると思います。

５．PDFには幾つかの標準タイプの署名を含むことができます。
(１)１つ以上の通常の署名
(２)最大１個の変更検出・変更防止署名
(３)最大２個のユーザ権利の使用権を指定する署名

ここまで読んだだけで、PDFでは、どうもかなりいろんな種類の署名ができそうだと思われますね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月08日

PDFと署名(21) — 電子証明書ICカードはなぜVistaで使えない？

もういろいろなところで、問題として取り上げられていますが、電子入札・電子申請が軒並みWindows Vistaで使えません。また、電子証明書ICカードもWindows Vistaで使えないようです。

○電子入札コアシステムのクライアントはWindows Vistaは使えません。
コアシステムにおけるWindows Vistaへの対応について
「RC1版では、既存のICカードドライバが動作しないこと、およびJRE1.3.1では正常動作しないことが判明しており、現時点ではWindows Vistaのクライアント端末にてコアシステムを使用することはできません。このため、Windows Vistaにつきましては、2007年1月30日以降もコアシステムのクライアント推奨稼動環境には含まれませんのでご注意ください。」（2007年5月8日現在）

これを受けて、電子入札対応ICカードを発行している認証局でも、Vista非対応という表示をしているところがあります。

当然ですが、コアシステムを採用しているすべての団体の電子入札への応札者のクライアントPCは、Windows Vistaは使うことができません。

○公的個人認証サービス利用者クライアントソフト自体がVistaに対応していません。
公的個人認証サービスの利用に必要となるパソコン等の仕様について
「次のいずれかが必要です。

* Microsoft Windows XP (Service Pack 2適用)。
* Microsoft Windows XP (Service Pack 1適用)。
* Microsoft Windows 2000 (Service Pack 4適用)。
* Microsoft Windows 2000 (Service Pack 3適用)。
* Microsoft Windows 2000 (Service Pack 2適用)。
* Microsoft Windows NT (Service Pack 6a適用)。
* Microsoft Windows Millennium Edition (Me)。
* Microsoft Windows 98 Second Edition (SE)。」
（2007年5月8日現在）

当然（？）、公的個人認証サービスのICカードで、Vistaで動作保証されているものは見当たりません。

この結果、電子政府の窓口もほとんどWindows Vistaに対応していません。電子政府の申請は、かならずしも、電子証明書必須ではないですし、また、電子証明書を使うにしてもICカードとは限らないのですが。

これは一体どこに問題があるのでしょうか？
・ICカードリーダのデバイスドライバの問題？
・WindowsVistaとJAVA（JRE）の問題？

○ICカードリーダのデバイスドライバの問題なら、ICカードリーダをVista対応版にすれば解決できます。しかし、電子証明書用のICカードリーダを販売している会社でVista対応版を用意しているところは見当たりません。ICカードリーダのメーカの方は、上位のアプリケーションがVista対応でないのだから、別に、Vista対応を急ぐ必要はないと思っているようです。

例えば日立のICカードリーダ
「※公的個人認証サービスをご利用の方へ
現在、公的個人認証サービス利用者クライアントソフト自体がVistaに対応しておりません。今後、公的個人認証サービス利用者クライアントソフトのVista対応に合わせて検証試験を行います。 」
（2007年5月8日現在）

また、JDL電子申告システムのWindows Vistaの対応ページには次のように書いてあります。
「JDL電子申告システムは、弊社Windows Vista™対応ハードウェア製品およびソフトウェア製品でご利用いただくことができます。但し、電子署名に必要なICカード（ICカードマネージャ）とICカードリーダライタにつきましては、現在提供元およびメーカーの動作確認が報告されておらず、ご利用いただくことができません。したがって、電子署名のみ、動作確認済みの弊社Windows®XP搭載機種およびWindows®XP対応製品で行ってください。」　（2007年5月8日現在）
これをみると、原因はICカードのリーダライタ側にあるということなんですが。

しかし、ICカードリーダのベンダは沢山あるのだから、どこか1社ぐらいは、Vista対応版を出してもよさそうなものですが。なぜ、どこも出さないのでしょう？

○また、JAVAの実行環境にも問題があるようです。もともと、JAVAを使えば、アプリケーションをOSから独立にできるという触れ込みでしたが、Vistaの登場でそれが嘘であることがばれてしまいました。JAVAそのものが一つのアプリケーション実行環境(JRE）なので、アプリケーションがWindows環境依存からJAVA環境依存に変わっただけだったのです。だから、JREがVistaできちんと動かない限り、JAVAアプリケーションの作者は手も足もでません。Vistaの登場で、そのことがはっきり分かったともいえるんだよね。じゃあ、クライアントのJREを全部入れ替えろ！というのも面倒なことになります。要するにWindowsクライアントのジャバはジャマなんです。

※JAVAはアプリケーション開発の生産性が高いということでJAVAを選んだケースが多かったのかもしれない。しかし、生産性が高いというのは、反面ブラックボックスが増えるということでもあります。そういう意味では、Vista問題はソフトウエア開発環境の選択の事例研究として、専門家が検討すべきでしょうね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月07日

ビジネス用の書式を集めたWebページのご紹介

アンテナハウスでは、「書けまっせ!!PDF2」用のPDF書式集「書けまっせ!!フォーム」を用意しています。

書けまっせ!!フォームのページはこちらです。
http://www.antenna.co.jp/form/

「書けまっせ!!フォーム」は、PDF形式に特化した書式ページですが、PDFに限定しなければ、書式を集めて無償で使用可能にしているWebページは沢山あります。次に幾つか紹介してみます。

○書式の王様　http://www.bizocean.jp/
　社内文書1,494種類、社外文書481種類、個人文書277種類、法定文書1344種類、英文文書97種類　合計3,717書式が登録されています。
　ダウンロードのランキングが公開されています。こちらです。
　上位を見ますと、　

1位　領収書
2位　出勤簿
3位　FAX送付状
4位　時候のあいさつ
5位　失態の詫び状
などとなっていて、かなり一般的な社内書式に人気があるようです。

ファイル形式には、PDF形式もあります。しかし、上位30位以内は、ExcelかWord形式ばかりですのでPDFは人気がないのかな？ちょっと残念ですね。「書けまっせ!!PDF2」のようなPDFへの記入ソフトが普及すれば、PDF書式にもっと人気が出ると思います。

○テンプレートバンク　http://www.templatebank.com/
パーソナル、ビジネス、素材と分かれています。Webサイトの名称はテンプレート（様式）になっていますが、内容はWebページ用の素材などがかなり多くなっているようです。
ビジネスの分野に、「伝票・帳票・届出用紙」という分類がありますが、このあたりに書式が登録されています。PDFの書式もありますが、有償のものが多いようです。

○B-Form.biz　http://www.businessform.biz/
ビジネス文書のポータルサイト。1000種類と言っていますので、「書式の王様」より少ないですね。Word、ExcelとならんでPDF形式のものもありますが、PDFは比較的少ないようです。

○ビジネス文書の森　http://www.jusnet.co.jp/business/
有償と無償の雛形があります。100種類の無償のビジネス文書の雛形がありますが、書式として形が整っているものではなく、文章の雛形中心のようです。PDF形式のものはありません。

○ハート封筒のオリジナルテンプレート　http://www.heart-group.co.jp/download/index.html
このWebページには同社のオリジナルのテンプレートが公開されています。Word文書になっているようです。PDFでも十分使えそうなものもありますが、残念ながらPDFは用意されていません。

こうしてみますと、PDF形式に絞って簡単に使える書式を用意している民間のWebページは比較的少ないように思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月06日

PDFと署名(20) — 電子証明書と個人情報

次に、電子証明書と個人情報保護の関係について考えて見ます。PDFを含めて文書に電子署名すると、文書と署名データと電子証明書を一緒に相手に渡すことになります。このように電子証明書の内容は相手方に開示されるものです。

現在、さまざまな認証局が発行している電子証明書は、公開鍵証明書の標準であるX509のバージョン3を基本としていますが、subjectAltNameを独自拡張して、証明書所有者について詳しい情報を保存しているものが多いようです。

例えば、次のようになっています。
・公的個人認証サービス　(東京都）— 氏名, 生年月日, 性別, 住所, 氏名代替文字の使用情報, 住所代替文字の使用情報
・電子認証登記所 — 商号、本店、資格、氏名、会社法人番号、管轄登記所
・AOSignサービス（日本電子認証株式会社） など — C=JP, S=本社住所(都道府県), L=本社住所(群、市町村以下), O=企業名, CN=氏名
・TOiNX電子入札対応認証サービス（東北インフォメーションシステムズ株式会社） — 利用者氏名（かな漢字表記、以下、同じ）、組織名、区市町村名、都道府県名、国名
・日本司法書士会連合会認証サービス — ST=（所属する事務所所在地の都道府県）, L=（所属する事務所所在地の市町村以下）, O=（日本司法書士会連合会 固定）, OU=（所属する司法書士会名称）, T=（司法書士:司法書士登録番号）, T=（簡裁訴訟代理関係業務認定:認定番号）, CN=（利用会員氏名）

一方で、認定認証機関でも、subjectAltNameを独自拡張していないものもあります。このように電子証明書の発行機関によって拡張領域に記録される内容は様々です。

もともと、公開鍵暗号方式は、公開鍵をインターネットなどで一般に公開するという概念からスタートしています。そして、公開鍵の所有者等の情報を記載するとともに、公開鍵自体の情報を改竄から守るために公開鍵証明書の形式で公開します。Webサーバに掲示するサーバ証明書がその典型的な使用例でしょう。

一般に、運転免許証やパスポートなどは身分証明書としても使うことができます。これを身分証明書として使ったり、体面で相手に提示したり、あるいは、パスポートは航空券を申し込む時、コピーして提示したりします。しかし、このような身分証明書をインターネットなどで不特定多数に公開する人はまずいないと思います。これに対して、電子証明書は、公開される身分証明書であると言っても良いと思います。

電子証明書によって署名をした相手が本人であるかどうかを判断するためには、本人を特定する情報は必須です。ところが、電子証明書は署名した文書とくっついてインターネット上で相手にわたりますので、電子証明書が個人情報やプライバシーに関わる情報を含んでいると、これが公開されるのははまずいということになります。

この点に、電子証明書の矛盾があります。このことを考えると、各認証機関がsubjectAltNameを独自に拡張してしまったのは少しまずいのではないかとも思います。X509ではそのために属性証明書が規定されていて、関連する公開鍵証明書に紐付けして使うようになっています。しかし、属性証明書を発行している認証局は少ないようです。

例えば、首相官邸Webから公開されている「2006年度　電子政府評価委員会報告書」には、公的個人認証サービスをもっと普及させるために、電気、ガス、医療などにも使えるようにせよ(p.25)、とあります。しかし、そもそもいままで三文判で済ませていたような申し込み書に、個人情報満載の電子証明書を使う必然性があるのでしょうか？
※電子政府評価委員会のWebページ

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月05日

PDFと署名(19) — 商業登記に基づく電子証明書は使えそう。しかし。

法務省の「商業登記に基づく電子認証制度」（電子認証制度）は、法人の登記情報に基づく、電子証明書を発行しています。この電子証明書は、次の人が対象となります。

「登記所に印鑑を提出している会社の代表者・支配人や商号使用者。また、会社以外の民法法人，独立行政法人，特殊法人，認可法人，協同組合，社会福祉法人，医療法人，宗教法人，学校法人，信用金庫，特定非営利活動法人などについても，登記所に印鑑を提出した代表者。」

電子認証制度の電子証明書には、公開鍵証明書 X.509 V3仕様の独自拡張部分を用いて、法人について、商号、本店、代表者名、代表者の資格、管轄登記所、会社法人番号が記録されています。従って、この電子証明書に対応する秘密鍵で署名した文書については法人を特定できます。

この電子証明書の発行申請は、各法人の管轄登記所ですが、東京法務局が電子認証登記所（CRCA）となります。電子証明書の検証は、署名された文書の受信者がだれでも行うことができますので、一般の企業の取引でも使うことができます。登記内容は商業登記法に基づいており、虚偽の登記は罰則が適用されますし、汎用性が高いものと思います。

しかし、問題が幾つかあります。

(1)手数料は3ヶ月単位で3ヶ月から最長で27ヶ月（2年と3ヶ月）。3ヶ月の場合で2,500円、1年7,900円、27ヶ月で16,900円となります。さらに、取得申請時に登記済みの印鑑証明も必要ですので、印鑑証明1通分の手数料がプラスされます。
(2)秘密鍵・公開鍵ペアを自分で行い、公開鍵をフロッピディスクに入れて提出しなければなりません。いまどきは、フロッピディスク・ドライブ装置を持っていないPCも多いのにね！
(3)フロッピへの記録方式が規定されています。このフロッピ作成等の処理を行うためのアプリケーション・ソフトウエアが必要です。
　☞ 電子証明書の方式等に関する件（告示）
(4)この電子認証制度の電子証明書は、多くの電子入札システムで使えます。但し、例えば電子入札コアシステムでは、電子証明書の保存媒体としてはICカードしか使えませんので、コアシステムを採用した電子入札に使おうとすると、受け取った電子証明書を電子入札コアシステム用のICカードに移すことが必要です。
(5)電子認証登記所が発行した証明書を検証するときは、証明書失効リスト（CRL)ではなく、オンライン（OCSP）で状態を問い合わせる必要があります。従って、インターネットに接続していない端末から証明書有効性の検証はできません。

電子認証制度の電子証明書は、法人（代表者）の証明書としては、最も正統的であり、かつ汎用に使えるものです。この点、今後の普及を期待したいところです。しかし、普及させるには、手数料をもっと安くすること、期間を大幅に延長すること、手軽に使えるアプリケーションが増えることなどの諸条件が整うことが必要なように思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月04日

PDFと署名(18) — 公的個人認証サービスの電子証明書の用途は？

2007年04月27日PDFと署名(12) — ルート認証局の種類で、全国の地方自治体が行っている「公的個人認証サービス」を紹介しました。このサービスは、「電子署名に係る地方公共団体の認証業務に関する法律」（公的個人認証法）に基づくもので、公的個人認証サービスの電子証明書は次の特徴があります。

(1)個人が現在住んでいる市町村（住民基本台帳がある住所）を通じて、都道府県の知事に対して、発行を請求します。
(2)市町村長が本人の確認を行い、その確認通知を受けて、都道府県知事が発行します。
(3)電子証明書は、現在のところ、住民基本台帳カードに保存されます。
(4)電子証明書には、住民基本台帳に記録された氏名、住所、生年月日、性別と、利用者が電子署名のために使用する秘密鍵に対応した公開鍵が記載されます。
(5)電子証明書は発行の日から３年間有効です。但し、有効期間中であっても住所の変更や氏名の変更の場合などで記載事項に変更が生じた場合は無効になります。
(6)2007年04月29日PDFと署名(14) — 電子証明書の検証で説明しました通り、電子証明書を使った署名を検証するには、証明書の失効をチェックする必要があります。しかし、公的個人認証サービスの電子証明書の失効者リスト（CRL）を入手できるのは、行政機関などの特別な機関に限ります。従って、一般の個人・法人には公的個人認証サービスの電子証明書による署名を検証することはできないことになります。

以上のこと（特に、(6))からお分かりになりますように、公的個人認証サービスの電子証明書は、行政手続だけに使うことができます。

使用できる行政手続きは、次に一覧があります。

公的個人認証サービスを利用する行政手続き
・国の機関等
・地方公共団体等

使える行政手続きの種類は多いので、社会保険労務士、行政書士、など様々な申請の代理業務を行っている場合には、メリットが大きいかもしれません。

ただし、どこまで使えるかの判断は難しそうです。例えば、特許庁のインターネット出願ソフトの概要（平成17年1月）p19 には、「住基カードの公的個人認証サービス電子証明書については、現時点(H16.12)では、「電子署名に係る地方公共団体の認証業務に関する法律」第19 条第2項により、利用方法が限定されている為、利用できません。」とあります。

注意しなければならないのは、この電子証明書には、氏名、住所、生年月日などの個人情報が入っていることです。このためこの電子証明書を公開すると、まさに、個人情報の公開になってしまいます。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月03日

PDFと署名(17) — e-Taxで使う電子証明書

昨日は、電子入札で使う電子証明書が、個人（自然人）の電子証明書になっていることが多いようで疑問を感じる、とお話しました。

もう少し調べてみますと、認定認証局によっては、電子署名法の施行規則で求めている手続き（個人の本人性確認のみ）の他に、所属する企業までを確認して電子入札用の電子証明書を発行するところも多いようです。実際のところ、電子入札などの政府・行政と法人間の取引行為に個人の電子証明書を使うというのは不合理なように思います。これは公私混同でもありますので、正さねばならない問題でしょう。

また、法務省の商業登記認証局では、法人代表者の電子証明書を発行していますので、電子入札では、そういうものを使う方向に進むかもしれませんね。

では、国税庁の電子申告・電子納税(e-Tax）で使う電子証明書はどうでしょうか？
e-Taxの場合、関与する税理士が申告する場合は、税理士の電子証明書でよいのですが、自己申告する場合は電子証明書が必要です。使える電子証明書は、次のものです。
・個人の申告等では、地方公共団体の公的個人認証サービス、　法務省が運営する「商業登記認証局」が発行するもの、認定認証局が発行するもの。
　☞ 個人が利用可能な電子証明書には何がありますか。

・法人の申告等でも同じです。
　☞ 法人が利用可能な電子証明書には何がありますか。

e-Taxでは、法人税の申告に代表者個人の電子証明書も使える、と明確に書いてあります。

　☞ 商業登記認証局の発行する法人代表者の電子証明書は、法人代表者個人の所得税申告にも使用できますか。また、法人代表者個人の公的個人認証サービスなどの電子証明書は、法人税の申告に使用できますか。を参照。

法人税の申告に代表者個人の電子証明書を使うことができる根拠は、「法人税法では申告書に法人代表者の自署・押印」を求めていることだそうです。私の記憶では、紙で法人税関係の申告をする時の押印に使う印鑑は、三文判でも問題ないはずです。つまり、法人税の申告では電子証明書は三文判の延長としての役割を担っているのでしょう。このあたりに、税理士が関与した場合は、本人の電子署名が不要ということになる遠因があるのではないでしょうか。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月02日

PDFと署名(16) — 電子証明書の使用者は法人？自然人？

通常の社会活動において、署名者の主体は、自然人または法人となります。例えば、個人的に物品を購入したり、個人で住宅や土地を購入する場合、その主体は自然人です。それに対して、会社として物品を購入したり、会社としてビルの賃貸契約したり、業務の請負契約をする場合は、その主体は法人となります。

従来の印鑑の場合であれば、自然人は地方自治体に実印を登記できます。そして、重要な契約は個人の実印を用いて押印し、その印鑑証明を添えることが求められます。

また、法人の代表者は、民間企業であれば、法務局に代表者印を登記しており、企業を代表して重要な契約をする場合は代表者印を使用して押印し、その印鑑証明を添えることが一般に行われます。

このあたりまでは、電子化されていない印鑑による商取引の常識だろうと思います。

ところが、電子署名法とその施行規則を調べますと、電子署名法に基づく認定認証局が発行する電子証明書の所有者は、どうも自然人に限られるようです。

「電子署名及び認証業務に関する法律」の第六条二では、認証業務を行うものは、利用者（電子証明書の発行相手）の特定方法を、「申請に係る業務における利用者の真偽の確認が主務省令で定める方法により行われるものであること。」と定めています。

そして、その主務省令にあたる「電子署名及び認証業務に関する法律施行規則」では、第5条（利用者の真偽の確認の方法）で、具体的な方法を定めています。この部分は長いですが、端的にいいますと、「住民票の写し、戸籍の謄本など」の提出を求め、そして、「パスポートまたは運転免許証など」で本人を確認する、こととなっています。従って、電子署名法に基づく認定認証局の発行する電子証明書では法人の代表者であることは証明されません。

ところが、官公庁などの電子入札の入札資格者は、ほとんどの場合、自然人ではなく法人のはずです。例えば、国土交通省の電子入札運用規則には次の項目があります。

「電子入札を利用することができるＩＣカードは、競争参加資格認定通知書に記載されている者（以下「代表者」という。）又は代表者から入札・見積権限及び契約権限について年間委任状（様式２）により委任をうけた者（以下「受任者」という。）のＩＣカードに限る。」

※電子入札運用基準

このため、法人の代表者と自然人を対応つける必要が発生します。つまり、前述の通り、ICカード（認定認証局の発行する電子証明書）は自然人のものになります。で、その自然人のICカードが、確かに、その法人を代表する人のものであることを証明しないといけないのですが、どうやって、これを電子的に証明するのでしょうか？例えば、A建設工業の代表者山田太郎が、電子証明書記載の山田太郎と同一人物であることを証明するのは、電子証明書のみではできないと思います。また、委任状を用意したとして、委任状の電子署名が代表者のものであることを、どのように証明するのでしょうか？

アナログの世界では、法人の代表者印は法人に紐付け付けられていて、代表者が別の人に交代しても、印鑑の所有者の登記を変更するだけでした。ところが、電子証明書の方は、自然人である代表者の方に紐付けられていることになります。どうも、180度違っているように感じます。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年05月01日

PDFと署名(15) — 電子証明書の用途別種類

次に、電子証明書の種類とその値段について、ざっと調べてみたい思います。電子証明書の用途としては、次のようなものがあるようです。

・サーバ証明用
・コードサイニング証明用
・個人認証用
・社員であることの認証用
・会員であることの認証用
・官職証明用
・電子入札・開札システム用
・電子届出・電子申請用
・電子申告・納税用
・電子契約用
・その他

以下に簡単に説明します。
・サーバ証明書
　インターネットのサーバとクライアントの間でSSL暗号通信を行うために、サーバ側に用意する証明書。
・コードサイニング証明書
　Windowsなどで、プログラムをインストールする際に、その開発元を証明する用途で用いられる証明書。
・個人認証用
　一番多いのは、電子メールなどに電子署名をすることで、電子メールの送信者を証明するもの。それ以外に、ベリサインなどでは、簡単に個人を特定するためのクラス１という証明書を発行している。
・社員であることの認証用
　会社の中にプライベートな認証局を構築し、社員に対して証明書を発行するもの。会社のネットワークに入る人を特定するなどの用途で用いることができる。
・会員であることを認証用
　会社の社員と同じような趣旨。
・官職証明用
　官庁の職責で発行する文書に電子署名するための証明書で、GPKIの認証局が発行する。
・電子入札・開札システム用
　認定認証局などが、官公庁・行政機関の入札の書類用に発行する。発行先は企業になる。
・電子届出・電子申請用、電子申告・納税用
　認定認証局などが、官公庁・行政機関への電子届出・申請、税金の申告・納税用に企業向けに発行するものと、地方自治体が発行する公的個人認証サービスの電子証明書がある。公的個人認証サービスの電子証明書の対象は個人。
・電子契約用
　企業間取引のために用いる電子署名の証明用
・その他
　例えば、商業登記に基づく証明用電子証明書があります。これは、商業登記の内容を証明するもののようです。

こうしてみますと、電子証明書の種類は非常に沢山ありそうです。他にも探せばもっとありそうに思います。ひとつの証明書で、全てを賄えれると良いのですが、なかなかそうも行かないです。特に、PDFとの関係では、サーバ証明書やコードサイニング証明書は関係がありません。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック