[Rats] PKIX Attestation design team meeting notes 2024-03-011

[Mike Ounsworth <[e-mail]>]

As always, the full meeting notes are on github:

https://github.com/lamps-wg/csr-attestation/blob/main/meetingNotes/2024-03-1
1.md


LAMPS > csr-attestation

Draft will be ready for WGLC once two minor points are resolved:

Need completed sample -- IETF 119 hackathon objective. Monty has posted
shell scripts to generate a TPM attestation in the correct format, we just
need to wrap that inside openssl scripts to put that into a CSR for the same
subject key. https://github.com/mwiseman-byid/csr-attestation-tpm-example

The new registry pointing to attestation formats from other SDOs; how
exactly will that interact with TCG; more importantly do we need to change
the currect document, or can we sort out how TCG wants their stuff
cross-referenced within the constructs of how the registry table is
currently laid out?

RATS > x509-evidence

Great continued discussion on what the goals are, following on JP's
presentation of the Crypto4A format in our last meeting.



"PKIX Attestation" group goals

Focus: Network & PCIe HSMs TPMs already have a suite of well-defined
attestation formats, we are trying to do the equivalent for the HSM
community.

Usecases

- Key attestations -- for example to place inside a CSR.
   * Is this key in hardware? FIPS? Keygen date? Storage attributes for the
private key?
   * Attesting some properties of the platform come indirectly into scope,
but no need to directly attest the platform.
   * In a CSR for meeting CA/B F. rules.
   * More general attestation formats would enable HSM fleet monitoring type
solutions.
   * Maybe we should define an attestation format where the key attribute is
optional so that it can be used for platform attestations later on. (note:
TCG solves the same problem by allowing both X.509 SubjectKey certs, and
also Attribute Certs as attestation statements).
- Operators may onboard the HSM into their own Attesation Trust hiararchy,
and either inject a new On-Device Attesation Key to the HSM, or certify the
existing AK in their PKI. "Take ownership".
- Offboarding audit logs; attest that audit logs come from a given HSM.
- "Mandatory-to-implement" minimum set of claims? Or all optional? JP
suggests that all claims be optional and the client requesting the
attestation from the HSM can request the set of claims that it wants
included in the produced attestation. (that plays well with a nonce, for
example). Ned countered that the way most hardware does it today, the
claimset profiles are baked in at the hardware level.
- Do we want to build-in a mechanism for multiple signatures (envisioning PQ
hybrids), or counter-signatures? (this would more-or-less rule out X.509 as
a carrier format).


- - -
Mike Ounsworth
Software Security Architect
(pronouns: he/him)