host OS would like to be able to sign small blobs with a ROT-owned key

For various purposes in the lab we use Yubikeys (in their PIV/CAC mode) to provide credentials for a machine-level principal. Gimlets don't have USB, which is fantastic from almost every perspective except that I can't use a USB-attached PIV token for the same thing in a Gimlet.

I'd like the ROT to be able to stand in for a PIV token. To provide roughly the same facility, I think at least these properties would be valuable:

• new IPCC operations that allow:
  • creating at least one ed25519 or ecdsa private key, named by some identifier (e.g., an integer slot number, or a short string, or a TLV-C style 4 byte UTF-8 token)
  • enumerating host-accessible key(s) by the slot ID used when they were created
  • for symmetry, I suppose, being able to delete a key by slot ID would make sense as well, although I don't currently expect to use that often if at all
  • fetching the public key by slot ID
  • feeding in a small blob to be signed and getting back a signature of that blob; the blob would generally be short, such as a hash of larger contents plus some header and footer bytes, as it will be used for SSH-style authentication

I don't really care how or where the key gets stored within the SP/ROT complex, as long as the plaintext private key is not something that can be extracted from the ROT (as is the case for PIV tokens with secure elements generally).

I want something that follows the "resident" or "discoverable" key model, rather than something that we'd have to store outside the ROT/SP. The key must be persistent between power cycles, and between wipes of all of the host-level storage; i.e., if we totally destroy the contents of all U.2 and M.2 disks in the Gimlet, the machine should be able to boot up a fresh OS and identify itself in the same way.

There is no requirement for an X.509 certificate or other attestation, at least at this point. I would manually gather and curate a list of known public key to Gimlet mappings in a lab-managed database as we do with public keys for principals that represent staff members.

I believe the set of IPCC primitives described above would allow us to implement a daemon that runs under the host OS and provides an ssh-agent-like interface to software that runs on the machine. This would allow software using the sshauth crate (for, e.g., authenticated HTTPS requests) or the regular ssh CLI to authenticate to remote systems.

Start by reviewing the existing IPCC operations and the ROT/SP boundary, then determine how persistent, non-extractable key storage fits the requested design. Define the operations for key creation, enumeration, deletion, public-key retrieval, and blob signing, with persistence across power cycles and host-storage wipes as the completion criteria.