Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt a definition of assurance levels #3

Open
dstebila opened this issue Feb 3, 2024 · 5 comments
Open

Adopt a definition of assurance levels #3

dstebila opened this issue Feb 3, 2024 · 5 comments

Comments

@dstebila
Copy link
Contributor

dstebila commented Feb 3, 2024

No description provided.

@TheFoxAtWork
Copy link

I'm interest in assisting with this effort when it gets started.

@planetf1
Copy link
Contributor

planetf1 commented May 16, 2024

@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

@TheFoxAtWork
Copy link

Thank you for the update!

@franziskuskiefer
Copy link

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

  • AL 1 (formally verified | where this has a definition that we must agree on, probably something like functional correctness)
  • AL 2 (exhaustively tested | where this has a definition that we must agree on, probably something like property based testing, kats, fuzzing, etc.)
  • AL 3 (tested | self tests, kats)

The more fine-grained properties may then be something like

  • secret independence (machine code, or before compilation)
  • more properties ...

A label for "audited" may also be nice to have.

@planetf1
Copy link
Contributor

planetf1 commented Jun 6, 2024

I've tried to harvest the good ideas above and capture in an initial doc page.

  • Assurance - initial docs documentation#8 has a very early rough page - we could discuss at TSC. Based on a simple list not a taxonomy/rich ontology. None of the definitions are rich, nor are the levels correct.
  • OpenSSF has various checklists (scorecard, cii initiative, a base level for open source best practice) but so far none go to this kind of level. Asking in this community to see if any related activities

@planetf1 planetf1 moved this to Backlog in TSC tracking Jun 17, 2024
@planetf1 planetf1 moved this from Backlog to In progress in TSC tracking Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

4 participants