![深澤直人氏によるTWELVE[トゥエルブ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/15707686663efd5db344eaf9ac21d586e92f49fc/height=288;version=1;width=512/https%3A%2F%2Fwww.sii.co.jp%2Fjp%2Fwp-content%2Fthemes%2Fsii-pr%2Fimages%2Fog-image1.png)
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 最近、ちらほらAdobe AIRを使ったプログラムが増えてきてますね。プログラムを配布する時はコードサイニングしないといけないという話はわかっていたんですが、まぁ、Adobe AIRの実行プログラム *.air は言っちゃえばjarファイルなもんでjarコマンドやZIP対応のアーカイバで解凍でき、Javaのjarに対する署名だとタカをくくっていたわけです。 久々にAdobe AIRの面白そうなプログラム「てれびなう」なんてものを見つけてしまったのでインストールしようとしたら、こんな画面が、、、 「発行者」とか「発行者ID:検証済み」とか出てますが、ボタンを押せば証明書やコード署名の内容が表示されるわけでもなく、どこから出た証明書でコード署名し
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 ≪第8回 今回で最終回となります。これまで、XML形式の長期署名フォーマットXAdESの識別名一致確認において以下の事柄を紹介してきました。 XAdESの仕様ではSigningCertificate、CompleteCertificateRefsおよびCompleteRevocationRefsに記載された証明書識別名が証明書、CRL、OCSP応答データと一致することを確認しなければならない。 XAdESにおいて証明書識別名はRFC 2253により生成されるが、これは正規化形式ではないので生成側、検証側の実装が異なれば一致確認を行うのは難しい。 実際にテストを行いRFC 2253識別名文字列の生成を行ってみると実装により違いがあることがわかっ
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 ≪第6回へ 前回は証明書識別名のRFC 2253文字列が得られる入手しやすそうな5つの実装を紹介しました。 ・Sun Java SE 6 Update 3 (build 1.6.0_03-b05) ・BouncyCastle Java Crypto Library 1.3.8 ・IAIK JCE Toolkit 3.142 ・Microsoft .NET Framework 3.5 ・OpenSSL 0.9.8i (cygwin) 今回はこれらの実装を使った場合、生成されるRFC 2253文字列にそれぞれどのような違いがあるのかテストしてみたいと思います。 テスト1: 属性タイプ名に関するテスト テスト対象の実装を用いてテスト用に生成された証
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 ≪前回第3回へ なんか忙しくって随分時間が空いてしまってゴメンナサイm(_ _)m 今回はいよいよRFC 2253で証明書識別名を文字列で表すところの紹介です。 識別名の文字列変換方式を定めたRFC 2253 RFC 2253 'Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names' とは、証明書中の発行者名や主体者名などの名前(X500Name)やディレクトリエントリの識別名をUTF-8エンコーディングされた国際化文字列に変換するルールを定めたものです。 XAdESの発行者名はRFC 2253により文字列変
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 ≪第2回へ 前回はETSI 101 903 XAdES v1.3.2における発行者識別名の一致検証の記述について説明しました。 今回は、XAdESと似たCMSバイナリ形式の長期署名フォーマットCAdESだってSigningCertificate、CompleteCertificateRefs、CompleteRevocationRefsが同じようにあるのに何故CAdESでは問題にならないのか、また、XAdESの元の仕様であるXML署名を規定したXMLDSigだってIssuerSerialはあるのに何故問題にならないのか、RFC 2253の説明に入る前に少し寄り道して説明したいと思います。 証明書・CRL・OCSP応答の(発行者)識別名の定義と
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 ≪前回(第一回)|次回(第3回)≫ 前回は、XAdESにおいては識別名の一致確認に問題があるという紹介をしたところまででした。 今回は、XAdESの仕様はどうなっているのかを見ていきましょう。 XAdESにおける検証情報中の発行者名一致確認の要件 ETSI TS 101 903 XAdES v1.3.2では、Annex G (informative): Details on XAdES signatures validationに検証続きが説明されており、CompleteCertificateRefsの証明書参照情報の検証方法については以下のように規定されています。 (注:厳密には規定でないことは後述) G.2.2.12 Checking C
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 前から書こうと思っていたんですが、やっと時間が取れそうなのでXML形式の長期署名フォーマットXAdESにおける証明書等の名前比較の問題提起について数回に分けて触れていこうと思います。 はじめに W3CのXML署名(XMLDSIG)を拡張した長期署名フォーマットであるXAdESでは、署名者が署名に用いた証明書やこれを検証に用いた証明書、証明書失効リスト(CRL)、OCSP応答が将来不正に置き換えができないように以下のような検証情報のリストをSigningCertificate、CompleteCertificateRefs、CompleteRevocationRefsとったプロパティに保持しています。 先に例を示した方が早いと思うので、Sign
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 ETSI XAdESプラグテスト関連で、ちょっと愚痴りたいこともあり、、、、(^^; テスト用に使うCAなんですが、よそで作られたプロトタイプCAを使っています。いろいろ面倒なことが多いんですが、今回困ってしまったのは証明書の識別名(Distinguished Name:DN)の相対識別名(RDN)の並びの順序のことです。 X.509デジタル証明書は、X.500ディレクトリを基礎としてこのディレクトリに基づいてエンティティが管理され証明書が発行される仕組みになっています。エンティティの名前が例えばディレクトリのルートから { C=JP, O=TEST, CN=USER1 } のような国(C)から始まる順序になっていたとすると、証明書の識別名も
DSigProposal - Office Wiki OASISの策定したワープロなどのオープンなフォーマットであるODF 1.2の署名の仕様にXAdESを使えるようにしようという提案があるそうです。 ブラジルの政府認証基盤でもXAdESを使えるようにしているそうですね。ECOMのテスト用のCRLのアクセスログを見ているとブラジルからのアクセスもあったりして、数ヶ月前CAdESのデータを送ってくれとメールが来たこともありました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く