<前の日記(2003年06月24日) 次の日記(2003年06月29日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2991   昨日: 4374

2003年06月25日

続・通信キャリアの独占型PKI

昨日の日記について、セキュリティホールmemoの6月25日付の欄外で次のコメントを頂いた。

OSと、通信インフラと、認証サービスとが独立して提供されるという、これこそがPKIの理念ではなかろうか。

そんなことないと思いますけど……。 全部 1 社が提供しても、「そういう実装の PKI」というだけのことなのでは。

これについては、まず、文章を次のように訂正する。

OSと、通信インフラと、認証サービスとを独立して提供できるようにしたというのが、PKIという仕組みの設計理念だったのではなかろうか。

この日記の書き始めた当初からのテーマは、「よりよい方法が存在するにもかかわらず、それが選択されないことによる、プライバシーの犠牲」という現実を理解し、少しでもましな方向へ進もうということだ。

「FirstPass」が成功しそうなのは、ほぼ無料だからというところによるものが大きいと思う。そしてそれが可能なのは、OSと、通信インフラと、認証サービスの提供主体が一体だからだろう。その反面で失われているものは、名前空間の独立性、代替認証局の利用可能性によるリスクの分散化である。名前空間の独立性が失われたことは、すなわち、統一IDによるプライバシーの低下を意味する。

もし、第三者認証事業者が対等に参入できる仕組みにしたら、携帯電話のクライアント認証は普及しないかもしれない。無料というわけにはいかないので、料金が高すぎるために普及しないという、これまでの一般のWebでの二の舞になるのかもしれない。

その点で、ドコモのやり方はビジネスとして上手だと言える。これまでも、インターネットの技術を中途半端に導入することで「いいとこ取り」をして、成功してきたと言えるだろう。インターネットは、多くの技術者や研究者の厳しい目で磨かれ洗練された技術をベースにしている。最大限の自由と公平性が得られる技術をインフラとし、その上で必要に応じたサービスを構築すればよいという理念に基づいているように思う。それに対し、携帯電話事業者の場合は、そうした理念なんかよりも、いかに現実的に成功するかを追求しているのだろう。しかし、通信インフラレベルで「いいとこ取り」(中途半端な導入)をすることは、一般的に、長期的に綻びが生じてくる懸念があるように思う。

この件で私が言いたいのは、「FirstPass」は大成功するかもしれないが、「クライアント認証ってこういうものなのね」という理解はして欲しくないということだ。

さて、次に、話を変えて、昨日の日記で書き漏らしたことを追記する。

「FirstPass」で証明書の再発行はできるのだろうか。まず、紛失した場合に再発行できるのかというと、できるのかもしれない。では、紛失していない場合でも再発行できるのか。できるとした場合、異なるID(common name)の証明書を取得することができるかどうかだ。その必要性が想定されていないならば、再発行してもIDは変化しないだろう。つまり、IDは契約者番号と一対一対応しているという可能性がある。

異なるIDで証明書を再発行してもらう必要性がどこにあるかというと、プライバシーが損なわれたと思ったときに、その証明書を破棄して、IDの異なる新しいものを取り直すという自衛手段が提供されるという点にある。IDが変わると、クライアント証明書を登録した各サービスで再登録が必要になるが、それで正常にサービスは受けられるわけであるし、手間をかけてでもプライバシーを重視したいという要求が満たされるようになる。

希望によってIDを変更するという仕組みは、住民基本台帳の住民票コードにさえ用意されているものだ。

住民基本台帳に記録されている者は、その者が記録されている住民基本台帳を備える市町村の市町村長に対し、その者に係る住民票に記載されている住民票コードの記載の変更を請求することができる。

住民基本台帳法第三十条の三(住民票コードの記載の変更請求)

これは、住民票コードによる追跡が起き得る状態になったとの不安を抱いた住民が、番号を変更することで追跡から逃れられるようにするという配慮からだ。ただし、変更履歴が記録されているので、追跡者が、変更履歴を閲覧できる者である場合には、これは有効な回避策ではない。有効となるのは、次のケースなどだ。

ここで気づいたが、EZwebの「subscriber ID」も、IDの変更ができるようにしたらどうだろうか。あるいは、既に変更できる仕組みが用意されているのだろうか。今度問い合わせてみよう。


<前の日記(2003年06月24日) 次の日記(2003年06月29日)> 最新 編集

最近のタイトル

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
<前の日記(2003年06月24日) 次の日記(2003年06月29日)> 最新 編集