---
# System prepended metadata

title: tss-esapi Community Meeting Agenda

---

# tss-esapi Community Meeting Agenda

* Discuss development plan for v8 of `tss-esapi`
    * Should we strive to pull out `abstractions` as its own crate?
        * (firstyear) - yes I think so. I'm working on something external (kanidm-hsm-crypto) that is aimed at higher level use cases, but abstractions with common recipes would be very useful.
        * (fy) Generally the current crate doesn't "play well" with external applications, it's hard to export a public key as der or create a csr etc. This adds a huge barrier to entry for new users.
* What is missing from the `tss-esapi` crate that would be useful?
    * Any integrations that might be useful? e.g. RustCrypto traits
    * Anything we should be testing against in our CI?
    * Is documentation sorely missing anywhere?
        * (fy) More examples with focused use cases are the biggest improvement I can see
            * "I want to use a TPM private key for signing a data"
            * "I want to encrypt some data with a key stored in a TPM"
            * "I want to use a TPM for webauthn signatures with attestation"
            * "I want to use a TPM for a HTTPS server private key / mTLS and need to create a CSR"
            * "I want to hash (Kdf) a password then HMAC it to a TPM"
            * "I want to attest a machine state before releasing a secret value" + "I want to update the PCR attest values to allow updates"
            * "I want to attest a key is TPM bound"
            * "I want to extract public key parameters to format into DER or JWK"
    * Create-credentials support?
        * mostly needs a KBKDF support crate (@baloo has a WIP in RustCrypto)
* TPM test-support crate (@baloo)
    * a crate to handle bringup, management, and injection of an initial state of a swtpm or similar
    * to be consumed by downstream users of `tss-esapi`

# Minutes

* Any requests for v8? New desired functionality?
    * @Firstyear noted that it’s currently difficult for users to create a key and export its public part as DER encoded, or as a CSR etc.
        * Integrating with RustCrypto traits would solve this problem without any extra effort (see more notes on RustCrypto below)
    * Separating the abstractions stuff into its own crate seems better
        * would clean up the dependency tree of tss-esapi
        * Would allow tss-esapi and the new crate interfaces to move at different speeds
    * Simon would like to access the serialisation features that we’ve been working on
* Anything (else) missing from `tss-esapi`?
    * Create-credentials support
        * Would be good to have it implemented and packaged somewhere as a crate
        * There’s an old convo about it [here](https://github.com/parallaxsecond/rust-tss-esapi/issues/160)
        * If we have the KDF in the ecosystem, might as well incorporate this functionality in our API
    * Handling of state for software TPMs
        * Useful functionality for CIs, also for state injection (e.g., in a vTPM)
        * swtpm seems to have an API to inject/extract its state ([link](https://github.com/stefanberger/swtpm/blob/master/man/man8/swtpm_ioctl.pod))
            * But no easy way to parse and operate on that state programatically
    * Better docs and logging
        * It’s fairly difficult to understand the error codes returned
        * Tbh this is a TPM-specific issue, rather than something related to our crate
        * Something we could do better is better logging when we’re the ones returning an error
            * Perhaps coupled with some links in the docs to the relevant parts of the spec
* RustCrypto
    * Having an integration similar to the one proposed by @baloo for cryptoki would be great
    * In a separate create would be better, given the large dependency tree that this brings in
    * We’d need to define some good defaults, as the TPM interface defines a superset of options, especially when it comes to access control for objects