Minutes of the March 6th Meeting

[johngray-dev]

Sorry it took me a few days to get these notes posted. The IETF draft deadline and other things got in the way... :) I also understand some people had difficulty getting into the gather space (because it looks like it is limited to 10 people). So I will send out a zoom meeting link for the next monthly meeting. For the IETF hackathon itself, there should be plenty of bandwidth in gather during the hackathon as it is the preferred virtual tool during the hackathon.

Here are the notes that I took during our last meeting:

1. We welcomed Goutam Tamvada to the team!
2. We organized the remote meeting times for the Upcoming Hackathon on March 25th and 26th:

• Saturday March 25th at 11:00 am and 4:00pm Japanese Standard Time (UTC + 9)
• Sunday March 26th at 1:00 pm JST (UTC+9)
• We meet using the IETF gather tool using table G

3. We discussed the project scope for the meeting:

• Compatibility matrix filled out in more detail, with cross-wise matrix
• Continue PQ key and certificate testing
• CMS and CMP is next logical goal (a number of participants interested in those formats)
• Explicit composite support
• Cert Binding Hybrid Extension (Becker-Guthrie draft)
• Isara Catalyst Hybrid format (though it is an expired draft, so maybe some of us want to bring it out of its slumber?).

4. Round Table discussions:

• Corey has created python tooling that can be used to create more extensive compatibility matrix outputs
• David Hook implemented the new KEMRecipientInfo (from https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/) and has some artifacts using RSA KEM. He is also working on CMP
• Carl may add add some CMS and CMP in the coming months.
• Michael and Goutam - Goutam will be in person, and will be there to support libOQS (a lot of us are using libOQS for our PQ implementations)
• Mike Ounsworth mentioned the diverging key formats in the unikeys draft verses the other IETF drafts which specify the algorithms. He will reach out to those authors to see if there are differences that will impact libOQS implementations.
• Markku mentioned unikeys authors need to read the original specifications as many of them already mention the key format that should be used. It looks like libOQS is using the correct formats at the moment (but that could change with round 4 tweaks to algorithms).
• Alexander will be present and will be working on CMP artifacts.