自堕落な技術者の日記

こちらは朝の５時、CAdESとXAdESの属性証明書関連の参照情報・値情報の記述でよせばいいのに標準策定者の属性証明書の認識不足から来る、重箱の隅をつつくような、でも大きな議論に発展しそうな問題を見つけてしまったような気がする、、、、、、、見つけなきゃ良かった、、、、（Ｔ＿Ｔ）

次のプラグテストに間に合うように一応資料は作ってみる予定、、、、このブログでも紹介できるとよいなぁ、、と思います。

属性証明書は面倒臭いし殆ど誰も使ってないので、修正したとしても誰も喜ばないですし、突っ込んでもしょうがないんですけどね、、、、(じゃぁ、仕様に入れるな、みたいな、、、、（＾＾；

ECOMセミナー

第３３回　ＥＣＯＭセミナー 本人確認情報と属性情報の利用のあり方について

仕事の都合で最初のセッションしか聞くことができず中座してしまいとても残念でした。

最初の講演は属性証明書のチュートリアル的でありながら、個人的には属性証明書について考えさせられた興味深い講演でした。

属性証明書はパブリックにはあまり使われてないし、仕組み自体とても面倒くさく厄介だと思っています。これまでの属性証明書の議論でスコ〜〜ンと抜け落ちているのは属性証明書を発行する属性認証局(AA: Attribute Authority)なんじゃないでしょうか。PKIのエンドエンティティつまり一般ピープルなら誰でも発行できるものなので、認められた組織が発行した属性証明書かきちんと確認する事が非常に重要です。生成する側と検証する側で、属性認証局はトラストアンカと同等の扱い、つまり検証前に属性認証局がどこであるかを合意しておく必要があります。

属性認証局を明らかにし合意しないまま属性証明書を使うというのは本来ありえない話です。

このPKIエンドエンティティなら誰でも属性証明書を発行できるという仕様はX.509 PMIやRFC 3281の欠陥なんじゃないかと思っていて、属性認証局用の公開鍵証明書には拡張でも何でもいいから何らかの印をつけておくべきだったんじゃないかなぁ、、、とも思います。

ETSIのXAdESのプラグテストでも適当な人が勝手に属性証明書を発行しようとしたり、公開鍵証明書から紐付けることのできないものや、CAから属性証明書発行させようとしたり、とんでもない雰囲気でした。一応、指摘はしたんだけども誰も気にしていない様子でした。(そもそもXAdESソサエティーの人々の多くは証明書検証にはあまり興味が無いんです)

その割には属性証明書の検証情報の格納に拘ったりする、、、、検証なんかできていないのに、、、、全くわけがわかりません、、、、、

長期署名の場合には属性証明書の検証情報、即ち
・属性証明書自体の失効情報(もし必要ならば)
・属性認証局の公開鍵証明書(PKC)の認証パスおよび失効情報群
も必要になります。現在のETSI ESIの議論では、属性認証局PKCのパスは現状のCAdESの仕様では格納する場所が難しくて、certificatesフィールドに格納するしか手が無いというのも面倒臭いところです。

タイムスタンプの時刻監査証も属性証明書なんですよね、、、（＾＾；

認証された属性の共有の仕組みとして、SAMLの属性アサーションやOpenIDベースの仕組みが社会インフラとして普及したとするなら、属性証明書よりもそちらの方を保管したり長期署名に組み込む方が筋がいいんじゃなかろうか、、、とも思ったりもします（　´∀｀）つ

IDの話は下手な事言えないので、また別の機会にコッソリと（ｗ