Request for feedback: Verifiable external review record for OSS security (QSP Stage245)

[mokkunsuzuki-code]

Hello OpenSSF community,

I’m working on a small open-source security project called QSP (Quantum-Safe Protocol).

In the latest stage, I implemented a mechanism where:

• a review result can be recorded
• the record is signed
• the signature can be independently verified

The goal is to make external security review itself reproducible and auditable.

GitHub:
https://github.com/mokkunsuzuki-code/stage245

This is not a full security solution, but an attempt to address:

“How can we preserve and verify security review results in OSS?”

I would really appreciate feedback on one point:

→ Does this kind of “signed review record” have value for OSS security or supply-chain trust?

Even a short comment would be very helpful.

Thank you for your time.

[jagmarques]

Signed review records absolutely have value for supply chain trust. The tricky part is key management - who holds the signing key, and how do you rotate it without invalidating old reviews? We hit this building asqav for AI agent compliance and landed on ML-DSA-65 (FIPS 204) with a public verification URL per receipt. The verifier doesn't need the signer's key because the receipt is self-contained. Might be worth looking at for QSP too - Ed25519 is fine now but NIST's post-quantum timeline means new signing infrastructure should probably start quantum-safe.

[mokkunsuzuki-code]

Thank you very much — this is extremely valuable feedback.

Your point that signed review records are valuable, but that key management (who holds keys, how rotation works, and how past reviews remain verifiable) is the real challenge, is very insightful and aligns with what I am starting to realize in this project.

I also found your approach particularly interesting:
the idea of self-contained receipts with a public verification URL, where the verifier does not need to separately obtain the signer’s key, seems like a very strong direction for improving practical usability and auditability.

For the current stage, I used Ed25519 because it is simple and widely supported, but I agree with your point that new signature infrastructure should consider post-quantum readiness from the beginning. Exploring ML-DSA-based approaches is definitely something I would like to look into.

Based on your feedback, I am planning to make the next step of QSP focus on:

Key lifecycle (including rotation and validity)
Algorithm agility (not binding to a single signature scheme)
More self-contained and verifiable review receipts

Your comment helped clarify what the “next real problem” is — thank you again for taking the time to share this.

I would be happy to share the next iteration once it is implemented.

[mokkunsuzuki-code]

Thank you again for your earlier feedback.

Based on your comments, I implemented the next step as Stage262.

This stage moves toward self-contained verification:

• embedded public key inside the receipt
• no separate public key file required
• lifecycle-aware receipt structure
• algorithm-agile format for future PQ migration

Repository:
https://github.com/mokkunsuzuki-code/stage262

This is not fully trust-free “keyless” verification yet,
but it significantly reduces verifier-side dependency.

I am planning to explore post-quantum signatures (e.g., ML-DSA / FIPS 204) and verification URL models as next steps.

Your feedback directly shaped this stage.

I would really appreciate any further thoughts.