anchor.diff:  other zone needs to also be able to validate the key of the host CN. To achieve
   this requires a chain of trust.
   
  -### Headnodes and chain of trust
  -
  -First, some terminology:
  -
  -CN:: A "CN" here is any physical node in the Triton system.
  -Headnode:: A "headnode" is any CN that has been authorized to host internal
  -Triton service zones (e.g. VMAPI, CloudAPI etc).
  +### Trusted CNs and chain of trust
   
   As is typical with any chain of trust, we must begin with a set of keys known
   as "root keys", which are ultimately trusted. What we propose here is to use
   a single root key which is only ever stored offline, broken into pieces.
   
   This root key will sign an initial statement stating that certain nodes in the
  -cluster are to be headnodes, detailing their public keys, as well as a
  +cluster are to be Trusted CNs, detailing their public keys, as well as a
   timestamp and serial number. It will then (barring exceptional circumstances)
   never be used again.
   
  -To this statement, the headnodes of the datacenter may append additional
  +To this statement, the Trusted CNs of the datacenter may append additional
   statements, with certain restrictions:
   
    * Any appended statement must include a signature both over the new statement
      and all previous statements in the chain; and
  - * The appended statement must be signed by the keys of all headnodes in the
  + * The appended statement must be signed by the keys of all Trusted CNs in the
      datacenter at the time of appending, except one (N-1 out of N, unless there
  -   is only one headnode at the time, in which case its signature is required).
  +   is only one Trusted CN at the time, in which case its signature is required).
   
   The statement may declare that a new node (with corresponding key etc) is now
  -a headnode, or it may declare that an existing headnode is no longer such.
  -
  -All CNs in the system (both non-headnode CNs and headnodes) periodically gossip
  -their current version of the headnode chain out over the network, to a multicast
  +a Trusted CN, or it may declare that an existing Trusted CN is no longer such.
  +
  +All CNs in the system (both regular and trusted) periodically gossip their
  +current version of the Trusted CN chain out over the network, to a multicast
   address on the admin VLAN.
   
   If a CN receives a new chain, it will accept it as the new canonical version
  
positive.code: service attacks on the admin VLAN, but these are out of scope for this design.
  
  Threat 2:: An intruder has escalated their network access into the admin VLAN, by
  compromise of a compute node (privilege escalation and zone escape).
  Goal 2:: The goal is to give this attacker only the minimum access required for
  the normal operation of the CN. They will be able to control other zones on that
  CN, as well as the information reported about them back to the rest of Triton.
  They will under no circumstances be able to gain control of a headnode from this
  position. Their access to the system can be terminated by revoking the
  credentials of the CN, they cannot extract any long-lived key material, and
  cannot take any actions that would escalate or allow sideways movement into
  other CNs.
  
  Threat 3:: An intruder has taken control of a public-facing headnode service (e.g.
  CloudAPI), by making use of a vulnerability in that service.
  Goal 3:: The goal is to give this attacker only the minimum access required by
  the normal operation of that service. This means, for example, that CloudAPI
  would not be able to run arbitrary commands on CNs or directly interface with
  
negative.code:     signed statement about the CloudAPI zone's IP address and keys, including
      the GZ certificate.
   .. Binder receives and validates the registration
   ... First, binder retrieves the list of valid Trusted CNs from the gossip service
       on its host CN (via the soft token socket?)
   ... Then, it compares the signature on the certificate given by the registrant
       to this list and finds it was signed by a valid Trusted CN
   ... The certificate presented includes metadata about the zone, including any
       values of `sdc_role` or `manta_role` tags. Binder validates that such
       values should be allowed to register under the given DNS name.
  