-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Adopt a definition of assurance levels #3
Comments
I'm interest in assisting with this effort when it gets started. |
@TheFoxAtWork At the PQCP TSC last week we discussed this topic briefly (1st, so lots to get through), and agreed that a good starting point would be for the experts in each subproject to share their perspective, and that we'd then try to normalize across the subprojects. From my perspective we need to be able to articulate clearly what a consumer should expect from each algorithm, and help them understand how to decide. Matthias is going to share the views from his projects mlkem-c-embedded and mlkem-c-aarch64at the tsc next week |
Thank you for the update! |
I would suggest a few labels with different assurance levels that we can add to repositories, and a document that defines them. On top, we should have additional, more fine-grained properties each library defines, but they are unlikely to be understood by many consumers. High level it could be something like
The more fine-grained properties may then be something like
A label for "audited" may also be nice to have. |
I've tried to harvest the good ideas above and capture in an initial doc page.
|
No description provided.
The text was updated successfully, but these errors were encountered: