Proving Name Resolutions

To prove that a given name is bound to a given public key, the prover must find a certificate chain that resolves the name into that key. TEP uses name resolution to check that the principal reading from an output channel is the same as some reader in the channel’s reader set (Section 4.3.5). The algorithm for name resolution is given in Figures A-3 and A-4 .

To resolve a name into a key (or any Subject), the prover calls Prove-Nameon the requested name, the target subject, and an empty proof sequence. Prove-Name

Sequence: sequence ofSequenceItem SequenceItem: Certificate | Signature

Certificate: hissuer: PublicKey, tag: String, subject: Subject, propagate: Boolean, validity: DateRangei Subject: PublicKey | Name | ClassDigest

Name: hissuer: PublicKey, subNames: sequence ofStringi

Subject ← Check-Def(proof: Sequence, issuer: PublicKey, subName: String) 1 cert ← Read-Cert(proof, issuer)

2 if cert is null or cert.tag does not equal subName, returnnull 3 returnMaybe-Resolve-Name (proof, cert.subject)

Subject ← Maybe-Resolve-Name(proof: Sequence, subject: Subject) 1 savedSubject ← subject, savedIndex ← proof.index

2 if subject is a Name,

3 subject ←Resolve-Name(proof, subject) 4 if subject is null,

5 proof.index ← savedIndex, subject ← savedSubject 6 returnsubject

Subject ← Resolve-Name (proof: Sequence, name: Name) 1 subject ← name.issuer

2 for each subName in name.subNames do 3 if subject is not aPublicKey, returnnull

4 subject ←Check-Def (proof, subject, subName) 5 returnsubject

Certificate ← Read-Cert(proof: Sequence, issuer: PublicKey) 1 if proof has ended, return null

2 cert ← next item in proof

3 if cert is not a Certificate or cert.issuer does not equal issuer 4 or cert.validity is not current, return null

5 sig ← next item in proof

6 if sig is not issuer’s signature of cert, return null 7 returncert

Figure A-1: Checker Algorithm: Name Resolution and Certificates

Check-Auth(proof: Sequence, issuer: PublicKey, tag: String, target: Subject) 1 cert ← Read-Cert(proof, issuer)

2 if cert is null or cert.tag does not equal tag,reject 3 subject ← Maybe-Resolve-Name(proof, cert.subject) 4 if subject equals target, accept

5 if subject is a PublicKey and cert.propagate is true, 6 Check-Auth(proof, subject, tag, target) 7 else reject

Figure A-2: Checker Algorithm: Authorizations

attempts to write a proof to the sequence and returns true if it succeeds.

Prove-Name works by calculating all possible resolutions of the given name.

Prove-Name calls Prove-Name-Set on the name and an empty proof sequence.

We must be careful to avoid infinite loops in the certificate graph which may occur when names are bound to other names. At the same time, we must allow proofs for different names to use the same certificates. By giving each name an empty sequence, we resolve names in separate spaces while still avoiding loops.

Prove-Name-Set returns its resolutions as a set of ProofSubjects: each Proof-Subject is a tuple containing a subject and a proof that the name resolves into that subject. Prove-Namethen checks each proof-subject pair to see if any of the sub-jects match the target. If so, the associated proof is written to the sequence and Prove-Namereturns true.

Prove-Name-Set returns the set of subjects bound to the given name, and a proof for each subject. Prove-Name-Setworks by calculating the set of principals bound to each subname and using those principals to resolve the next subname. The set of subjects bound to the last subname is returned.

To calculate the principals bound to a subname,Prove-Name-Setcalls Prove-Defs on the current subname for each current issuer. Each call to Prove-Defs returns a set of subjects that is added to the issuers for the next iteration. Once Prove-Defs has been called for each of the current issuers, the next set of issuers is used to resolve the next subname.

Prove-Defs calculates the set of subjects bound by a given issuer to a given subname. First, the set of defs issued by the issuer for that subname is retrieved using Get-Defs. Prove-Defs then calculates the union of the sets of subjects bound by each def.

Get-Defsimplements the retrieval of name certificates that match a given issuer and subname. In our implementation,Get-Defsretrieves the defs from a certificate cache local to the prover. In SPKI, certificates can be deployed widely across the network, although certificates by the same issuer are usually available from a sin-gle server. This design supports various distribution models easily by allowing the implementor to redefine Get-Defswithout changing the rest of the prover.

Prove-Defcalculates the set of subjects bound to a given def (name certificate).

Prove-Deffirst checks that the def is either bound to a key or has not already been

used in the proof sequence. This restriction ensures that this certificate will not cause the prover to enter an infinite loop (see the section on name loops below).

Prove-Def then saves the current proof index and attempts to write the certifi-cate to the proof usingWrite-Cert. If this fails, the proof index is restored and the empty set is returned. If Write-Cert succeeds, Prove-Def calls Prove-Def-Inner to calculate the set of subjects bound to the def. The proof index is then rolled back to the saved index, since the returned set contains the proofs for each subject.

Prove-Def-Inner creates a new set of ProofSubjects and adds a copy of the current proof with the subject of the def. If the subject is itself a name, the set of subjects bound to that name is also returned. Recall that the target of the proof may be the name itself, which is why the subject is returned in a separate ProofSubject.

Name Loops and Incompleteness

The prover can enter a name resolution loop if a def binds a subname to the same name or to another name that causes the prover to return to the same certificate.

For example, if Alice issues the certificate KAAlice → KAAlice, resolving the name

“KA’s Alice” causes the prover to return to the same certificate.

We can avoid loops by checking that each def used in a proof is either bound to a key or is used at most once in the current proof branch. If the def is bound to a key, this branch of the proof search terminates immediately. Otherwise, we must ensure that each def is used at most once so this branch of the proof will terminate.

Unfortunately, these restrictions mean the prover cannot find proofs for names that require multiple applications of a name certificate whose subject is a name.

Although this makes the prover incomplete, this situation is not expected to occur in typical naming graphs.