anchor.diff:     all CNs up and running
   
    . Before beginning to set up hardware, run tools (on laptop) to generate root
  -   key and program Yubikey for initial set of headnodes. Set up 3 DVD-Rs as
  -   backup media (as multi-track UDF), burn media key and initial metadata to
  -   first track, followed by backups of root key and disk encryption secrets for
  -   the headnodes.
  +   key and program Yubikey for initial set of Trusted CNs, including at least
  +   one headnode. Set up 3 DVD-Rs as backup media (as multi-track UDF), burn
  +   media key and initial metadata to first track, followed by backups of root
  +   key and disk encryption secrets for the initial nodes.
    . Run tool to update the USB flash drive image for booting headnodes. Copies
      the root public key into it, as well as the top-level certificates for the
      initial set of headnodes (edits the .img file in one step).
  
positive.code:    newer timestamp on the very first statement.
  
  In this way, in an emergency situation, the chain can be restarted by using the
  offine master key to sign a new statement about the headnodes for the
  installation.
  
  This design allows headnodes to be added and removed from the installation at
  a later date without requiring that the root of the chain of trust be available
  in online storage for signing.
  
  Once the gossip process has stabilized, all CNs in the system are aware of the
  identities and keys of nodes that are authorized to act as headnodes (hosting
  core Triton services). This means that zone certificates presented by zones on
  these CNs can be validated, authenticating headnode services to each other.
  
  It is important to note that changes to the set of headnodes are expected to be
  infrequent, so it is not important to use a distributed system here that offers
  fast convergence. The simplicity of implementation of a gossip design is also
  an advantage.
  
negative.code: mount its boot flash media and update the set of headnode CA certificates stored
  there.
  
  Some Triton installations do not boot iPXE from flash media, and instead use the
  built-in PXE ROM in their system. Unfortunately, the only known way to build an
  authenticated system around the firmware PXE is to leverage the EFI Secure Boot
  and TPM features of a modern system, and support for using these with PXE is
  difficult (due to lack of general EFI support) and somewhat inconsistent between
  server vendors. It would require the ability to modify the certificates stored
  in firmware for boot signing, at runtime, which currently is a deeply
  proprietary procedure.
  
  For this reason, installations which depend on system PXE firmware will not have
  a fully secured boot procedure, and will not meet all of the stated goals of the
  system.
  
  [[green-field]]
  ## Green-field deployment step-by-step
  
  