昨日は要件をざっくりと整理しました。今日はこの要件を満たすようなメッセージングプロトコル・アーキテクチャを設計していきます。

電子メールでは送受信のための識別子としてメールアドレスを使っています。メールアドレスは RFC 5322 で以下のように定義されています。

  addr-spec       =   local-part "@" domain

  local-part      =   dot-atom / quoted-string / obs-local-part

  domain          =   dot-atom / domain-literal / obs-domain

  domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

  dtext           =   %d33-90 /          ; Printable US-ASCII
                      %d94-126 /         ;  characters not including
                      obs-dtext          ;  "[", "]", or "\"

つまり，@ の右側がドメイン名、左側がそのドメイン内でのローカルIDとなります。

メールアドレスもオーバーレイ通信を行うためのアドレスとして機能しています。メールアドレス自体はインターネット上でユニークなIDですが、このアドレスのうち @ の右側のドメインはLocatorとしての意味も持ちます。具体的に、

asai@example.jp

というアドレス宛のメールを送信する場合、送信元は example.jp のMXレコードから送信先のメールサーバのドメイン名を解決します。そして、送信先のメールサーバでは @ の左側（または複数のドメインのメールを管理する場合はメールアドレス全体）から配送するメールボックスを特定してメールを配送します。

このように、メールアドレスはIDとLocatorとしての機能の両方を持ちます。

今回設計するメッセージングプロトコルでは、昨日定義した機能要件である

3. プロバイダ非依存の識別子（ID・アドレス）によるメッセージング
4. 人の扱うIDとそれ以外のIDの分離（人の扱わないIDからのセマンティクスの排除）

を満たすように送受信者の識別子の設計を行います。

まず、人の扱うセマンティクスを持った識別子とのマッピングはのちほど検討するとして、セマンティクスを持たない送受信者の識別子を設計することとします。これにより、機能要件4を満たすようにします。メールアドレスでは、IDの一部がLocatorとして機能しているため、プロバイダに依存する構造となっています。今回実装する予定のメッセージングプロトコルでは、プロバイダ非依存にするために、プロバイダ情報となり得るLocator情報をID・アドレスから分離します。

ここで、Identifier (ID) の設計のために、その定義と要件を検討します。例えば、RFC 3986 では、Unique Resource Identifier (URI) の Identifier を

Identifier

An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification. Our use of the terms "identify" and "identifying" refer to this purpose of distinguishing one resource from all other resources, regardless of how that purpose is accomplished (e.g., by name, address, or context). These terms should not be mistaken as an assumption that an identifier defines or embodies the identity of what is referenced, though that may be the case for some identifiers. Nor should it be assumed that a system using URIs will access the resource identified: in many cases, URIs are used to denote resources without any intention that they be accessed. Likewise, the "one" resource identified might not be singular in nature (e.g., a resource might be a named set or a mapping that varies over time).

と定義しており、アクセスするためのLocator情報を提供するものではないとされています。また、URI は "globally unique" かつ "persistent" (永続的) であると述べられています。

今回のメッセージングプロトコルで利用する送受信者のIDも、"globally unique" であり、また、前述したとおり、プロバイダ非依存にするためにプロバイダ情報となり得るLocator情報をIDから分離します。一方で、プロバイダ非依存であることと、IDの生成や検証が非中央集権的であることは同一ではないため、中央集権的にするのか非中央集権的にするのかを検討します。メッセージングプロトコルで利用する送受信者のIDは以下を満たす必要があります。

• ユニーク性の保証
• IDの保有と検証
• IDの委任（サービスプロバイダへの委任）情報の登録と検証
• サービスプロバイダのLocator等のIDに紐付く情報の解決

中央集権的なIDの実現方法は、IPアドレスのように特定の組織（IANA）から階層的に割り当てたり、DNSのようにレジストラ経由でレジストリに登録するなどの方法があります。一方で、非中央集権的なIDの実現方法としては、UUIDやDecentralized Identifiers (DID)があります。DIDについては Internet Infrastructure Review（IIR）Vol.43 の解説がわかりやすいかと思います。DIDはUUIDと違い、ブロックチェーン技術などを用いて検証可能であり、またDIDに対応するドキュメントを解決できる点を特徴としています。

今回はUUIDのような乱数ベースの自己割り当て型のIDに対して、公開鍵暗号アルゴリズムを用いて保有を示すための証明書を発行する中央集権的なメカニズムにより、ユニーク性の保証とIDの保有と検証を実現します。この仕組みはPKIと同じなので、証明書を発行（署名）する機関もPKIの用語を借りてCertificate Authority (CA)と呼ぶこととします。中央集権的なメカニズムは非中央集権的なものへの置き換えも可能だと思うので、今回はこの方式で進めます。（UUIDのようにバージョンを識別するための記号くらいは入れてもよいかとは思いますが、永続化されるIDにバージョンというセマンティクスを入れてよいものか悩んでいるので、今回はとりあえず完全に乱数で実装しようと思います。個人的にはLocatorなど機能として「使われない（使えない）」ものに限ればセマンティクスなら入れてもよいかとも思っています。）

IDの生成については、上記のように中央集権的なメカニズムを用いますが、IDの管理は非中央集権的なメカニズムを採用します。ピア・ツー・ピア (P2P: Peer-to-Peer) ネットワークでIDを管理することとします。このP2PネットワークでIDの委任情報の登録と検証、サービスプロバイダのLocator等のIDに紐付く情報の解決を行えるようにします。

今回のIDは以下のとおり、256ビット（16進数文字列表現で64文字）とします。

ID := [0-9a-f]{64}

送受信者は公開鍵暗号方式の鍵ペアを作成して、このID文字列に対して証明書署名リクエストを作成してCAにIDのフォーマットとユニーク性の検証と署名を依頼します。CAはIDのユニーク性が確認できた場合は署名した証明書をID管理のP2Pネットワークに登録します。なお、この方式では乱数を使わないIDも発行可能になってしまうので、実装が進んだらもう少し賢い方法を考えたいと思います。

P2Pネットワーク上でID（と証明書）とそれに紐付く情報を管理します。このID管理ネットワーク上で委任情報の登録などを行う場合は、IDの証明書署名リクエストの際に生成した鍵ペアのうち秘密鍵を用いて認証します。

P2Pネットワーク上でのIDに紐付く情報の検索・ルーティングにはDistributed Hash Table (DHT)を使おうと思いますが、このあたりは攻撃耐性を含めて実装しながら検討していきたいと考えています。なお、メッセージのやりとりもこのP2Pネットワーク上に実装しようと思っています。

今日は送受信者IDの設計とID発行・管理の仕組みをまとめました。明日はこのID発行・管理の仕組みを実装しようと思います。