Doesn't handle stand-in values, or when chaff is added to the tree.

The example in the Combined Tree section is wrong

• Still need to write section on out-of-band checking / anonymous access to KT server.
• When a malicious update gets added, there's no way to tell if the key owner or service operator did it.
• Would be nice to think about streaming verification. Or at least give real numbers on proof size if streaming is not necessary.

Maybe not? We need to write an applicability statement on how to use KT for username -> public key bindings and really think through that. But the protocol can generally be for a lot of things.

We can't stop monitoring an old version of the key until it's direct path converges with a newer version.

KT currently assumes that all lookup requests happen interactively with the server. Some systems want to provide sender anonymity, which means the recipient user can't lookup the sender's public key themself (this would leak sender-recipient pairs to the server). There should be some kind of certificate-like, non-interactive lookup proof.

Multiple people have flagged that this would be operationally very nice to have, but it would need to be done in a way that preserves the system's security properties.

Re: mimi draft

I don't think it actually works to base what values can be omitted on the last field.

Access control policy can't change(?)

The number of stored keys in a KT server can be interpreted as the number of users of a service. Many service operators might consider this number very sensitive. Need to think about ways to best obscure it, and write that up.

One good option would be multi-tenancy -- that is, having multiple service providers share the same KT log. Maybe could also change the format of prefix tree proofs.