Meeting 22/11/23

[THS-on]

## Attendees

• @ansasaki
• @aplanas
• @edwards-n
• @galmasi
• @Isaac-Matthews
• @kkaarreell
• @lkatalin
• @lukehinds
• @maugustosilva
• @mdrocco
• @mbestavros
• @mheese
• @mpeters
• Niteesh Dubey
• @osresearch
• @ruocco
• @stringlytyped
• @stefanberger
• @THS-on
• @tpletcher-hpe
• @ueno
• @sergio-correia
• Maya Constantini
• Supreshna

Time: 25/10/23 15:30 GMT (https://www.timeanddate.com/worldclock/fixedtime.html?msg=Keylime+Meeting&iso=20231122T1530&p1=136&ah=1)
Meeting link: https://uni-kiel.zoom-x.de/j/63830615926?pwd=Qm16ZlZEYWFSSVNNdFVueURQS250Zz09

Topics

• Open PRs
  • added import function for private keys keylime#1497
  • support for user mode in run-test.sh keylime#1498
  • ca_impl_openssl: support CRL distribution point from config keylime#1499
• Update push model
• Update IDevID (should be now complete and test are done)
• Update keylime Operator
• Roadmap review

[stringlytyped]

Hi everyone, I am unfortunately not going to be able to make tomorrow’s meeting due to another commitment. Not sure if you are planning to have one in December, but if so, I’ll do my best to make it to that one.

That said, I thought I’d give an update on the push model here:

• Previously I had been debating two different options for the cert trust store. The first was to simply have the user load certs into a directory, as is the current approach. The second was to make trusted certificates manageable over the REST API. The issue with the first option is that there is no standards-blessed way to determine the type of certificate (EKcert, DevID cert, TLS cert, etc.) from the certificate itself, which I have concluded after much investigation. By taking the second approach, we can associate metadata with each certificate, so the user can mark for what purposes the cert should be trusted. Helpfully, in the last meeting, it seemed that you all would prefer this second approach any way.

• After reaching this conclusion, I have started work to support implementation of new REST APIs for certificate management. Since the push proposal in totality consists of significant additions to the existing APIs, I wanted to establish a good foundation on which to make these changes. So, I have been working away at a light refactor of the existing APIs so that we are using consistent patterns throughout the codebase, something we discussed in the enhancement PR.

• I will have more to share on this in the coming weeks, but it would be good to get some feedback before then. I am making an effort to follow common patterns but @THS-on if you are available sometime in the next couple weeks, I would appreciate some of your time to check that things look good so far.

• I recently involved a colleague of mine (Supreshna) to accelerate progress on the other parts of the push model proposal, starting with the attestation protocol. We plan to work in parallel but will still submit PRs sequentially, as previously discussed (trust mechanisms first, followed by authentication mechanisms and then the attestation protocol).

Let me know if you have any questions and I’ll answer them when I can.