3description = "A public key infrastructure (PKI) is a system for binding a set of keys to a name. Sometimes a small amount of metadata is included."
8
10A public key infrastructure (PKI) is a system for binding a set of keys to a
11name. Sometimes a small amount of metadata is included.
13Existing PKIs include PGP-style ["web of
14trust"](https://en.wikipedia.org/wiki/Web_of_trust), [SSL
15certificates](https://en.wikipedia.org/wiki/Certificate_authority),
16[ZeroTier](https://www.zerotier.com/lf-announcement/),
17[Keybase](https://keybase.io/), [OpenID](https://openid.net/what-is-openid/),
19Persona](https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Persona), and
20[Login with Google](https://developers.google.com/identity). These take unique
21approaches to the problem and have achieved some degree of success, but none
22provide globally consistent, permanent, and completely self-owned identities.
23Exhaustive exploration and categorization is unfortunately out of scope for this
24post, so we'll just describe Urbit's approach to achieving these properties in
27In Urbit, a "name" is often called a "[ship](/docs/glossary/ship)" or an "address" because we use the
28metadata in the PKI to make names routable. The total data is two 256-bit
29asymmetric keys, a cryptographic suite number (to allow changing crypto
30algorithms), the revision number of the key, and the name of a ship that will
31route for it. This sums to less than 128 bytes of data.
33Each PKI trades off various properties. We chose a tripartite system so that
34appropriate choices can be made for different use cases. Here, we explore the
35various properties we chose by following a series of binary choices -- the idea
38There are two sorts of PKI: either you can change your keys or not. If you
39cannot, then your name is impermanent, for no one can keep a set of keys secure
40forever. Even if your opsec never fails, eventually your crypto algorithms may
43However, if you sacrifice the ability to change your keys, you can have a very
44nice property: self-attesting keys. If your name is a hash of your public key
45information, then no other source of information is required to verify you are
46who you say you are. This is a useful property since it requires no coordination
47at all. Many things are impermanent, especially during development. It also
48provides a way to try out the network without obtaining a permanent address.
50This is our first stop in the idea maze. We call this sort of name a "[comet](/docs/glossary/comet)". A
51comet's name is a 128-bit human-readable hash of its public keys.
53However, Urbit is yours and it's forever. You shouldn't have to change your name
54every time you change your keys. So, we go back and take the other choice as well: you
55must be able to change your keys.
58To change keys, you must sign a message with the old keys revoking them and
59supplying the new ones<sup><a href="#f0">[0]</a></sup>. The question
60is what happens if the old keys also sign a second set of new keys. This could
61happen if an attacker obtained your old keys after the fact. This is important
62because one of the reasons to be able to change your keys is to invalidate the
63old ones so that they have no power.
65We have two options again: the PKI may be globally consistent or not. To be
66globally consistent means that if you believe a name is bound to a set of keys,
67then nobody on the network will disagree.
69If you don't require global consistency, you may sign this message and send it
70to all your neighbors, and they pass it on, and hopefully it gets to most of the
71network quickly. However, if one of those ships receives two contradictory
72versions of this message, the only thing it can do is trust the first one it
73heard, which may be different than what someone else heard. Thus, this is
74pairwise consistent but globally inconsistent. This is essentially how the
75pre-blockchain [Ames](/docs/glossary/ames) network worked, though key changes were not actually
76implemented. Because global consistency is a valuable property, we looked at
79For a globally consistent PKI that allows you to revoke keys, you need to be
80able to distinguish between two cryptographically valid messages to determine
81which was signed first. The dual problem could be solved easily — you can prove
82a message is signed after another by including the signature of the first in the
83second. This is equivalent to reading out a newspaper headline to prove a
84message was recorded after a given day.
86The problem of proving that one message was sent before any later ones
87inverts the problem. You can solve this with newspapers by placing the message
88in the text of the newspaper. While reading a newspaper requires no
89central party, writing one does. For a long time, this sort of message was
90always handled by a central party. SSL revocations are managed by a few central
91parties. When you buy property, it's not sufficient to have the previous owner
92sign the title — this must be entered into a central land registry. Otherwise,
93the owner may sell their property to multiple people and there would be no way
94to determine who is the new owner. With the land registry, all you need to do is
95ask the registry which sale happened first, and that's the one that counts.
98Again, Urbit is yours and it's forever. Trusting central registries
99jeopardizes both. The keen reader will notice that the problem of determining
100which key rotation happened first is exactly the double-spend problem that
101Satoshi solved with his proof of work algorithm for Bitcoin. His first block
102famously includes a newspaper headline to prove he didn't mine the block before
103that date. In a beautiful duality, his own algorithm proves that he didn't mine
104it after that date.<sup><a href="#f1">[1]</a></sup>
106Some argue that blockchain is only good for money. This is myopic and is
107generally based on the experience that its most valuable application so far has
108been money. The deeper problem that the blockchain cryptographic primitive
109allows one to solve a previously impossible task: prove that one message was
110signed before another without a central party. Blockchain was discovered by
111someone trying to create digital money, and he needed that primitive, but that
112doesn't mean that's all it's good for.
115Thus, we store our PKI data on a blockchain for our second kind of name:
116[planets](/docs/glossary/planet). A planet is a 32-bit address which has key
117information stored on the blockchain.<sup><a href="#f2">[2]</a></sup>
118The owner of a planet may broadcast new PKI data by adding it to the
119blockchain. Any later messages by the old keys will be rejected, and everyone
120on the network will listen to the blockchain for key data. Thus, we have global
121consistency, permanence, and self sovereignty. We know of no other solution
122that can provide these properties.
125While small individually, the aggregate PKI data for all nodes on the
126network may become very large. This is not an issue for comets because nobody
127needs to store comet keys except for those which they're talking with, and even
128those can be garbage-collected and re-requested and verified. For planets, there
129is a canonical set of keys, and somebody must store that. There are about
1302<sup>32</sup>, or 4 billion planets. If the PKI data is about 100 bytes for
131each planet, this is about 400 GB of data. This may be more than most users wish
132to store, but it's small enough that it would be very cheap for someone to host
133this data for many users<sup><a href="#f3">[3]</a></sup>.
135This information is currently stored directly on the Ethereum 1.0 blockchain,
136but as is well understood in blockchain circles this approach will not scale
137beyond a certain point. This moment came to be sometime in 2020. In reaction to
138this state of affairs, Tlon developed a "layer 2" scaling solution known as
139[naive rollups](/docs/glossary/rollups). This allows users to submit compressed
140PKI transactions to Ethereum as batches and compute the resulting change in PKI
141state locally, dramatically reducing gas costs to the point that Tlon offers a
142free-to-use public "roller" which aggregates transactions and submits them as a
145Of course, 4 billion is not enough addresses for every device on the planet today,
146much less in a few decades. So, we apply our maxim of re-examining our choices
147at each level for each use case. Examining the idea maze above, we cannot use
148the blockchain option for everything since the data is too big. However, it's
149not actually necessary for each of your devices to have its own self-sovereign
150identity separate from your planet. So we choose the option of using a central
151registry: your own planet.
153We allocate 4 billion "moons" to each of those planets. A moon is a 64-bit
154address whose 32-bit suffix is its planet. Your planet can easily store the keys
155for its own moons, and anyone who needs to talk to your moons can ask you for
158This is the sense in which moons are true ships: they're permanent names and you
159own them completely, as long as you own the planet. But they're not
160independent ships — their keys can always be revoked by their planet.
162To create a sane network, we require global consistency for all our names. There
163are three other properties; pick any two:
165- Comets are impermanent, self sovereign, and plentiful.
167- Planets are permanent, self sovereign, and not plentiful.
169- Moons are permanent, not self sovereign, and plentiful.
172Fancifully, comets are wayward celestial bodies that are great for testing and
173miscellaneous low-value things that won't last for long. Planets are where you
174can build a home and shape it into anything you want it to be. People can always
175find your planet; it's not going anywhere. Moons are useful for special
176purposes, like storage, heavy industry, and anything else you might want to do
177off-planet.<sup><a href="#f4">[4]</a></sup>
180<a name="f0" href="#0">[0]</a>: Or the equivalent with a hierarchical key
181structure. In practice, you want to have a master key which signs a junior key
182for everyday use. You use the master key to rotate the junior key.
184<a name="f1" href="#1">[1]</a>: More strictly: it proves that he didn't mine it
185after the other blocks currently on the Bitcoin blockchain. It only gives an
186ordering within the chain, not a literal timestamp.
188<a name="f2" href="#2">[2]</a>: In addition to planets, there are stars and
189galaxies. From a PKI perspective they're treated exactly like planets, but on
190the network they provide infrastructure services like routing.
192<a name="f3" href="#3">[3]</a>: In practice, this will likely be an included
193service by your sponsoring star. It could be a separate service, but it will be
194very cheap because it's a commodity and the "cost of production" is very cheap.
195At any rate, it should never rise above the capital cost of a 400GB hard drive.
197<a name="f4" href="#4">[4]</a>: To extend the metaphor, stars are a
198neighborhood to live in -- they're easier for other planets to see, so when
199they want to send you a message they look for your star first. If they don't
200even know where your star is, they can certainly find your star's galaxy, and
201that will be enough to locate the star. Of course, if your star is not
202providing satisfactory service, you can take your planet and move to another
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list