-
Notifications
You must be signed in to change notification settings - Fork 134
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
Root CA Protection #12
Comments
cc @mnn678 |
ITYM @mnm678 |
Thanks! Update, we're working on a plan to distribute and manage a set of hardware keys among community members to sign and protect the root TUF metadata. A quorum will be needed to do anything, and we'll have documented plans for rotation, replacement, destruction, etc. Update soon! |
I'm happy to help with the design of this with practices Ideas we use internally for our own HSM and root of trust management. |
Thank you! That would be great. Here's our current working plan: https://docs.google.com/document/d/1dJ5JNyLcuB6Fbl7eV5Rx8xlXdgic2thMFSseq4Y-pRo/edit?resourcekey=0-amsoXrePIvR2244GSTxeOw (shared with sigstore-dev, feel free to request access though if you're not in it) |
An intermediate CA will be added shortly, and we can disable the root. |
Going to mark this as fixed.
|
Right now we have one root CA configured in GCP Private CA. We could improve this a bit:
Some high-level suggestions:
Add an intermediary, and keep the root disabled.
The root could then be "enterprise" which comes with auditing.
Have multiple roots, across multiple providers/HSMs.
A majority would be required to sign any new intermediate for it to be trusted.
This is TUF-style and allows us to survive a root compromise.
It requires us to implement our own cert bundle checking logic though, rather than relying on the simple standard ones.
Rotation
We'll need to figure out our root rotation strategy anyway.
This will be also affect how we intend to get our root trusted and known to clients.
The text was updated successfully, but these errors were encountered: