こんにちは。CTO室長の浅野(@masakz5)です。 SSIのVerifiable Credentialのについて見聞きしたとき、昔からPKIやx.509証明書に関わっている方々の中には「属性証明書(Attribute Certificate)」のことを思い出される方も多いかもしれません。
今回のブログでは、この属性証明書とVerifiable Credential(VC)を比較してみたいと思います。
属性証明書とは何か
属性証明書(Attribute Certificate)とは、証明書の発行対象の属性情報を公開鍵の証明書とは別のx.509証明書として発行するという考え方で、2002年にRFC3281としてRFCとなり、2010年にこれを改定する形でRFC5755となっています。
以前のブログ記事でも書いたように、一般的にx.509証明書と呼ばれるものは、公開鍵（＝対となる秘密鍵）とその持ち主（のアイデンティティ）を紐づけることを目的としており、「公開鍵証明書」(Public Key Certificate =PKC)と呼ばれたりします。
この公開鍵証明書に持ち主のアイデンティティとして記述されるものには、TLSサーバ証明書であればwww.example.comのようなFQDNだったり、個人に対して発行される証明書であれば個人の氏名やメールアドレスだったりします。
この公開鍵証明書を使って、たとえばあるサービスにアクセスしてきた人が誰なのか、という基本的な認証の部分を行うことが可能になります。ただ、たとえばその人の所属する部署や役職によってアクセスできるリソースをコントロールする必要がある場合には、そのような属性情報を他のどこからか取得してくる必要があります。
属性証明書は、このような属性情報をx.509証明書の形で取得できるようにする、という考え方のもとで生まれました。
属性証明書は以下のような特徴を持っています。
- 公開鍵証明書を発行する認証局から権限委譲された属性認証局から発行される
- 属性証明書は公開鍵の情報を持たない（公開鍵の所有確認は公開鍵証明書に依存する）
- 属性証明書はその主体（被発行者）の公開鍵証明書に紐付けられる
属性証明書の発行スキーム
属性証明書が定義された背景
そもそも属性証明書が公開鍵証明書と分離した形で定義された背景はなんでしょうか。RFCでは、以下の２つの理由から、公開鍵証明書に属性情報を記述することが適切でない場合が多いと言っています。
- 公開鍵証明書と属性情報のライフサイクルが異なる
- 公開鍵証明書を発行する認証局が属性情報の審査も行うことが難しい
例えば企業のある部署に所属している人が異動するケースを考えたとき、公開鍵証明書の有効期限と異動のタイミングが合致しないケースは多いのではないでしょうか。もし公開鍵証明書に属性情報を記述していた場合、社員が異動するタイミングで毎回公開鍵証明書を再発行して鍵を更新する必要が出てきてしまい、オペレーションコストが高くなってしまいます。
また、公開鍵証明書と属性を分離させておくことによって、個別のサービスドメインでの認証・認可に必要な情報の設定をそれぞれのサービスドメインに任せることができるようになります。公開鍵と持ち主のアイデンティティの紐付けは公開鍵証明書の認証局が行い、個々のサービスドメインに属性認証局を任せることで、公開鍵認証局が全てのドメインで必要な情報をハンドリングする必要がなくなります。リアルの世界でのマイナンバーカードや運転免許証などの公的な証明書と、特定のサービスを受けるための会員証の違いに似ているかもしれません。
なぜ属性証明書はスタンダードにならなかったのか
皆さん既にお気づきのように、現在属性証明書はほとんど使用されていません。
なぜなのでしょうか。
いろいろな要因があると思うのですが、検証の仕組みが複雑な割にニーズが高くなく、実装するアプリケーションがほとんどなかった、というのが主な理由ではないかと思います。
１つの属性証明書を検証するために、少なくとも以下のプロセスが必要になります。
- 属性証明書の妥当性検証（署名検証）
- 属性証明書（及び認証局）の失効情報の検証（任意）
- 属性認証局証明書の妥当性検証（署名検証）
- 属性証明書に紐づく公開鍵証明書（公開鍵）を使用した本人性検証
- 公開鍵証明書の妥当性検証（署名検証）・パス検証
- 公開鍵証明書（及び認証局）の失効情報の検証
このため、属性証明書を使用せず、公開鍵証明書を使用して認証を行った後に別途データベース等に保管されている属性情報を使用して認可等のプロセスを行う、という形が主流になったのだと思われます。
（ただこの場合、属性情報が集まっているデータベースを持つことがシングルポイントのセキュリティリスクを発生させることには注意が必要です。）
もう１つの要因として、公開鍵認証局が属性認証局に対して属性証明書を発行し「権限を委譲」する、というモデルが現実にそぐわなかったということもあるかと思います。
特にパブリックな認証局を考えるとき、特定のサービスドメインにおいてその属性を確認できるような機関に権限委譲するためにどのような条件が必要なのか、どのような監査を行うべきなのか。このようなことを考えた時、属性認証局の運用自体が「割りに合わない」ものになった可能性はあるのではないでしょうか。
Verifiable Credentialとの対比
では、属性証明書と対比させる形でVCを見てみましょう。
まず、公開鍵証明書に該当するものはDIDと公開鍵を紐づけるDID Documentです。DID Documentについては認証局のような特定の権限を持ったエンティティが発行するのではなく、基本的にDIDの持ち主（Subject）が主体的に発行し、分散台帳(DLT)に格納する等の手段で非改竄性を保証します。（詳細はこちらの記事をご覧ください）
属性証明書に相当するVCはIssuerによって発行されますが、VCの検証に必要となるIssuerの公開鍵もDID DocumentによってIssuerのDIDと紐づけられます。認証局からの権限委譲のような行為は必要ありません。
Verifiable Credentialの発行スキーム
一般的にはVCの検証は以下のようなプロセスになります。
- IssuerのDID Document（公開鍵）を使用したVCの妥当性検証
(必要に応じて失効確認が入る) - VCのSubjectのDID Document（公開鍵）を使用した本人性確認
属性証明書の検証と比較すると、プロセス自体は非常にシンプルになります。
また、DID/DID Documentの発行コストが比較的低いため、1人のサブジェクトが複数のDIDを使い回すことが容易になり、VCごとに異なるDIDを使うということができるようになります。このことは複数のVCをDIDで「名寄せ」することで個人を特定する、あるいは個人の属性情報を収集することを難しくし、個人情報の保護のレベルを上げることができるようになります。
もちろん、属性認証局に比べてVCのIssuerの信頼性を担保するための仕組みに乏しいなど、VCモデルの弱点もあるかと思います。ただ、属性証明書がそのコストに見合うメリットを見出せなかったために普及しなかったのだとすると、信頼性を「自己主権型」で担保することによってそのコストを下げたVCモデルは、属性証明書より広く受け入れられる可能性があるのではないでしょうか。
