Reconciling link authentication and key rotation

[Roger Dingledine <arma@mit.edu>]

Nick brought this issue up in person, and I'm passing it to the list.
(George might be the best person to answer, but others should too?)

The spec says:

|A FWD/IP4 routing type indicates that the message must be
|retransmitted using the TLS/Mixminion transport protocol. The IP field
|represents the IPv4 address.  The KEYID field contains the SHA1 hash
|of the ASN.1 representation of the next node's transport public key.
|(Note that a node's transport key does not need to be the same as the
|key it uses to decrypt subheaders.)

The design doc says:

|Each subheader also includes the address of the next node to which
|the message should be forwarded, along with its expected signature key
|fingerprint --- the mix refuses to deliver the message until the next
|hop has proved its identity.

We clearly include a hash of the next hop's key in the message. But which
key? If transport key, then how do we deal with rotating the transport
key? (We could let a node provide all transport keys that have been
recently valid; but that's kind of kludgy. Or we could include more than
one hash in the message, but there's no space for that.)

I think I tend toward what the design doc says -- the hash included in
the message is a hash of the identity (signature) key of the next mix.

So when two nodes create a forward secure link with each other, they
each provide a certificate, including the transport key, signed by their
signature key? Is there a standard procedure for providing a new transport
key that's just as authentic (signed) as the old one?

--Roger