Review status of sub projects
None
Key elements from charter were highlighted - we agreed this was accurate:
PQ Code Package Project, which will build high-assurance production-ready software implementations of forthcoming post-quantum cryptography standards, starting with the ML-KEM algorithm
Alex noted the charter stats a CONTRIBUTING.md file should be present in each repo. We don’t have this. Issue 54
It was noted by Naomi this should be referred to as Voting members. We have an open community to which everyone is invited. Here we are only voting on those elegible to vote in future TSC discussions.
Discussed composition of TSC - typically starts as maintainer from each of the contributing subjects. Each member proposed in the initial list explained their role. A vote was taken which agreed with the initial voting members of the TSC. These voting members are listed in the attendance section below.
We agreed that an offline vote was the best way to elect a TSC Chair. Naomi will arrange a vote via github. Ry noted candidates should self-nominate.
Naomi also pointed out that the TSC Chair will be the PQCA TAC Rep.
Some consensus of a monthly frequency longer term, but we agreed to have the next meeting in 2 weeks time as we’re getting started. The current time (Thu 1300 UTC) seems ok. Naomi will send out a 1-off invite, and we’ll review at the next TSC meeting.
Agreed useful to have common APIs between implementations, especially where they are in the same language (and similar where it makes sense, if not).
We should ask users about APIs (including John in Mozilla where it’s used in NSS). Open Quantum Safe is also a consumer.
Tiago noted that sometimes randomization needs to come from outside, so needed an API change for NSS.
Hanno pointed out a consistent internal structure is useful too ie common functions in C implementations, as is common packaging. Doug mentioned it could be useful for a consumer to pull in several different implementations (ie generic, x86 etc).
Agreed a good starting point would be for 1 or 2 projects to present on their APIs and design decisions for the rest of the group. We could start with Tiago & then Matthias.
How do we describe assurance levels?
Franziskus mentioned this should be a high priority as it’s on our charter.
Can we have a single definition? Noted aspects can vary (ie threading model, whether algo is constant-time checked…). Agreed each project could explain what their interpretation is & share. We can then derive a common definition. Nigel pointed out we need to be able to explain to a consumer what to expect - how do I choose which implementation to use?
What do we expect from a reference implementation? Is this production ready? Agreed important to have reference implementation.
What is production code? What are it’s characteristics? Nigel noted that the PQCA has a project lifecycle proposal, and some discussion is delegated to the open quantum safe team - so probably makes sense to consolidate the discussion there.
Security vulnerability reporting also important.
Nigel suggested that Production could mean getting to a point where an org could take it & incorporate into their systems with some level of confidence, or perhaps goes into a distribution like Fedora.
Norman would like to propose a common testing harness within PQCP. Common API would help. We could use the NIST acvts test server. Need to supply credentials including cert. Ry will help out with the cert.
It may make sense for future hackathons to be more targetted?
Nigel briefly mentioned the following calls for workgroups at the PQCA:
Matthias mentioned they now have stack optimized code. Not very fast yet. Working through some cleanup including cc0 licensing. Currently no issues to discuss at tsc. For aarch64 have defined what to achieve - Hanno is new maintainer for this.
Nigel briefly mentioned our initial docs site at https://docs.pqcodepackage.org .
We ran out of time to do justice to this discussion. Continue in next session.
Action items