anchor.diff:  | Set to true if this range is allowed, or false is this range is blacklisted.
   
   | ca_dn
  -| The distinguished name (DN) of the attestation CA for this pivtoken.  Used to
  +| The distinguished name (DN) of the attestation CA for this PIV token.  Used to
   disambiguate any potential duplicate serial numbers between vendors.
   
   | comment
  
positive.code: be configurable in SAPI through the variable `KBMAPI_RECOVERY_TOKEN_DURATION`.
  By default, this value will be set to 1 day.
  
  When the `POST` request is received for an existing pivtoken, KBMAPI will
  verify the antiquity of the newest member of `recovery_tokens` and in case it
  exceeds the aforementioned `KBMAPI_RECOVERY_TOKEN_DURATION` value, it will
  generate a new `recovery_token`.
  
  On all of these cases, the status code will be `200 Ok` instead of the
  `201 Created` used for the initial pivtoken creation.
  
  
  ### UpdatePivtoken (PUT /pivtokens/:guid)
  
  Update the current fields of a pivtoken.  Currently, the only field that can be
  altered is the `cn_uuid` field (e.g. during a chassis swap).  If the new
  `cn_uuid` field is already associated with an assigned pivtoken, or if any of
  the remaining fields differ, the update fails.
  
  This request is authenticated by signing the Date header with the pivtoken's 9e
  key (same as CreatePivtoken).  This however does not return the recovery token
  in it's response.
  
  
negative.code: currently size limitations of zfs properties should allow for a single
  property to store approximately 8 boxes worth of data.
  
  The soft-token keys have to be boxed individually to the primary PIV token
  (so that the primary PIV token can't unlock all of them in a single
  operation), but they do not have to be boxed individually to the backup
  keys. In fact, it would be pretty inconvenient if they were, because we
  would have to do the challenge-response process at least N times for a
  