Names bind strings to sets of keys or programs. Principal names in Jif programs are bound to public keys in the security environment. TEP uses the environment to determine if a given principal name is bound to a given key, thus connecting principals in Jif to principals in the environment.
(cert // a certificate
(issuer // the issuer of this certificate (public-key // is specified with a public key
(rsa-pkcs1-md5 // the public key algorithm (e #11#) // the RSA public exponent
(n |ALNdAXftavTBG2zHV7BEV59gntNlxtJYqfWIi2kTcFIgIPSjKlHleyi9s 5dDcQbVNMzjRjF+z8TrICEn9Msy0vXB00WYRtw/7aH2WAZx+x8erOWR+yn 1CTRLS/68IWB6Wc1x8hiPycMbiICAbSYjHC/ghq2mwCZO7VQXJENzYr45|
)))) // the RSA modulus
(subject // the subject of the certificate (object-hash // is an object, specified by hash
(hash md5 |vN6ySKWE9K6T6cP9U5wntA==| // the MD5 hash
jar:http://www.webtax.com/webtax.jar!/COM/webtax/TaxPrep.class ))) // a URL for the object
(tag authority) // the type of authorization: "authority"
(not-before "1999-12-31_23:59:59") // cert is valid only between (not-after "2000-01-01_00:00:00") // these two times
)
(signature // the signature of the certificate
(hash md5 |54LeOBILOUpskE5xRTSmmA==|) // hash of signed object (hash md5 |Ut9m14byPzdbCNZWdDjNQg==|) // hash of signer’s key
|HU6ptoaEd7v4rTKBiRrpJBqDKWX9fBfLY/MeHyJRryS8iA34+nixf+8Yh/
buBin9xgcu1lIZ3Gu9UPLnu5bSbiJGDXwKlOuhTRG+lolZWHaAd5YnqmV9h Khws7UM4KoenAhfouKshc8Wgb3RmMepi6t80Arcc6vIuAF4PCP+zxc=|
// the signature itself )
Figure 3-2: SPKI Certificate Example
For example, the name “Alice” in a Jif program could be bound to a set of public keys, any one of which Alice might use. When TEP opens a channel that’s readable only by Alice, it must make sure that the principal reading from the channel controls one of Alice’s keys. TEP uses the security environment to check if the remote principal’s public key belongs to the set of keys bound to “Alice”. If so, TEP can release Alice’s data to the remote principal. Section 4.3.5 describes this process in detail.
3.2.1 Linked Names
In SPKI, names resolution is completely decentralized. Each principal defines their own name space by issuingname certificates. Principals bind local names to the keys of principals they know directly. Principals can then resolve names not only in their own name space, but in the name spaces of other principals [Aba98].
For example, say Alice, using key KA, binds the name “Bob” to keyKB and binds the name “Carol” to key KC. We depict this as:
KA Bob → KB (3.1)
KA Carol → KC (3.2)
Suppose Bob, using key KB, binds the name “DaveJones” to key KD:
KB DaveJones → KD (3.3)
Alice can take advantage of Bob’s bindings by linking to Bob’s name space:
KA Dave → KB DaveJones (3.4)
Alice now has a local binding for the name “Dave” that references Bob’s binding for Dave Jones. She could have instead used her local name for Bob in theextended name
“KA Bob DaveJones”:
KA Dave → KA Bob DaveJones (3.5)
We read this last line as, “KA’s Dave is bound toKA’s Bob’s DaveJones”. The name
“KA’s Dave” is resolved to{KD}using both Alice’s and Bob’s name certificates. Note that non-existent bindings such as “KC’s Dave” resolve to the empty set.
3.2.2 Name Resolution
Names are defined by certificates, and certificates may be chained together to resolve extended names. Consider the name “KA’s Dave” and the set of certificates described above. If we wish to resolve this name into a set of keys, we must find a chain of certificates that demonstrates the binding. We see that both certificates (3.4) and (3.5) provide a binding for “KA’s Dave”. Let’s use (3.5).
This certificate binds the name “KA’s Dave” to the extended name “KA’s Bob’s DaveJones”. To resolve “KA’s Dave”, we must now resolve “KA’s Bob’s DaveJones”.
Certificate (3.1) binds “KA’s Bob” to KB. We can now use KB to resolve the next part of the name, “DaveJones”. Certificate (3.3) binds “KB’s DaveJones” to KD. This is our final result, since there are no other names left to resolve.
We could have instead used the certificate (3.4) in the first step and gotten the same result. In SPKI, when multiple certificates provide different bindings for the same name, the result is the set of all possible bindings. Suppose Alice had also issued this certificate:
KA Dave → KE (3.6)
The name “KA’s Dave” is now bound to the set of keys{KD, KE}. This rule is applied recursively when resolving extended names. Suppose we add these certificates:
KA Bob → KF (3.7)
KF DaveJones → KG (3.8)
The name “KA’s Dave” is resolved directly intoKE by (3.6). It is also bound to the extended name “KA’s Bob’s DaveJones” by (3.5). Certificates (3.1) and (3.7) bind
“KA’s Bob” to{KB, KF}, and certificates (3.3) and (3.8) bind “KB’s DaveJones” to KD and “KB’s DaveJones” to KG, respectively. So the final set of keys bound to
“KA’s Dave” is {KE, KD, KG}.
Although this may seem confusing, both the chain discovery algorithm and the checking algorithm are simple recursive procedures. Since SPKI is fully decentral-ized, these algorithms can treat all principals uniformly – there are no special-case principals. Appendix A describes both algorithms in detail.
3.2.3 Names on TEP
TEP resolves names in Jif programs using SPKI’s linked local name spaces. Since each SPKI name space must start at some public key, TEP requires all principal names start from TEP’s own public key. TEP, using its public key KT, issues bindings for “dns”, “verisign”, and other trusted name services. Jif programs then name principals starting from one of these names, such as “dns edu mit lcs ajmani” or
“verisign microsoft billg”. TEP could implement name resolution with an entirely different security environment, such as Secure DNS [DNS99] or QCM [GJ98, GJ99], without requiring changes to existing Jif programs.