anchor.diff:  Response-Time: 1
   
   {
  -    "model": "Yubico Yubikey 4",
  +    "model": "Yubico YubiKey 4",
       "serial": 5213681,
       "cn_uuid": "15966912-8fad-41cd-bd82-abe6468354b5",
       "guid": "97496DD1C8F053DE7450CD854D9C95B4",
  
positive.code: kbmd (read: kaboom-dee) has 3 big areas of responsibility:
  
  Firstly, it's responsible for the "recovery" process -- when a server
  has lost its primary Yubikey/PIV token, it is responsible for providing
  the interface an administrator uses (either on the console or a pty) to
  recover encryption keys, set up a new Yubikey, and get the system back
  on track. Since this logically requires it to be able to set up new
  Yubikeys from scratch, it's also involved in the initial setup process
  to keep all the responsibility for that together.
  
  Secondly, it's responsible for the "unlock" process at boot --
  determining whether the primary Yubikey is available, getting the PIN
  (from boot-time module or pool config for standalone, or spawning a
  client to talk to KBMAPI), and if those fail, deciding whether to enter
  "recovery".
  
negative.code: generated PIN) is saved in a trusted datacenter service (KBMAPI).  The zpool
  key is then saved in an ECDH box.  This ECDH box requires the PIV token to
  "open" the box and provide the key.  For the PIV token to open the ECDH box,
  it must be given the PIN created during initialization.  A service on each
  machine (kbmd) handles all the functions necessary for creating the encrypted
  zpool, unlocking the encrypted zpool during boot, as well as recovering from
  a lost of damaged PIV token.
  
  [[glossary]]
  ## Glossary
  