-
Notifications
You must be signed in to change notification settings - Fork 19
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
TAP for TUF developer key management #141
Conversation
Signed-off-by: Marina Moore <mnm678@gmail.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
As I've mentioned before: One thing I don't see is how to bind the specific, ephemeral developer public key to a specific version of the message (i.e., TUF targets metadata). Recording it on Rekor is one way, but the TUF client may not always be able to efficiently verify that, especially in offline environments. Perhaps the message could also record the ephemeral pubkey itself, but it's something to think about. Basically, how do I know which keys were used to sign which messages, even if all the keys are vouched by the Fulcio root? |
The Fulcio certificate chain would be included in the signature. But yes, the client would need to make sure that this particular certificate is allowed to sign the metadata either by checking the TL directly, or by trusting the repo to do so. May be the repo could additionally indicate the correct certificate? |
Rendered version here, for those interested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few more comments / suggestions on this. Thanks for turning it into a TAP @mnm678!
Signed-off-by: Marina Moore <mnm678@gmail.com>
Thanks for the review @axelsimon! I updated the document |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more comments.
Co-authored-by: axel simon <github@axelsimon.net>
Fulcio can use any OIDC identity. This changes the metadata format to reflect this. Signed-off-by: Marina Moore <mnm678@gmail.com>
@trishankatdatadog @joshuagl Any blockers on having this merged in as a draft? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a good basis to merge as draft. Do we want to make an explicit recommendation (in security analysis?) that systems using Fulcio for developer key management SHOULD set up an auditor?
Signed-off-by: Marina Moore <mnm678@gmail.com>
Added |
Also clarify that auditors may use TAP 3 multi-role delegations Signed-off-by: Marina Moore <mnm678@gmail.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
@trishankatdatadog @erickt I made edits and responded inline. Any objections to merging as a draft? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more suggestions, trying to resolve open conversations / comments.
adds consistent capitalization and some clarifications Co-authored-by: axel simon <git@axelsimon.net>
Signed-off-by: Marina Moore <mnm678@gmail.com>
Co-authored-by: axel simon <git@axelsimon.net>
Signed-off-by: Marina Moore <mnm678@gmail.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
The previous reviews were dismissed by some recent changes. @joshuagl @trishankatdatadog @axelsimon can I get 2 reviews/approvals for this to be merged as draft? |
Co-authored-by: asraa <asraa@google.com> Signed-off-by: Marina Moore <mnm678@users.noreply.github.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
Apologies if any of this is a bit off base or not the correct avenue, I'm still familiarizing myself with TUF a bit so I very well may have some core misunderstandings. Please correct me if so. I see some overlaps with this functionality and the some use cases we have for defining Roles using SPIFFE/SPIRE short-lived certificates. Where this is focused around verifying the OIDC identity using the Fulcio issued certificate we want to do similar by constraining on a specified SPIFFE ID on a SPIFFE issued certificate. I'm wondering if they may be some way we can come to a common solution for both? Or if perhaps creating a base PKI key type that both the sigstore and SPIFFE implementations could extend for their specific requirements? I've done some with with in-toto ITE7 for similar types of functionality with regards to defining functionaries with PKI issued keys, if that's relevant at all here. |
I think that we can certainly have a similar mechanism for using SPIFFE/SPIRE identities with TUF. My main reason for keeping this proposal limited to Fulcio is to simplify the fields required in the delegation and signature, and ensure that each key type has all fields that are needed for a secure implementation. For example, the Sigstore bundle in the signature is vital for the security of Fulcio signatures. |
Highlight that existing Sigstore tooling should be used Signed-off-by: Marina Moore <mnm678@gmail.com>
@JustinCappos @trishankatdatadog @joshuagl are we ready to merge this as a draft? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine merging as draft. I would like to have someone from the Sigstore side also review this before moving the TAP to accepted. Ideally we would have more clarity around monitoring TLs, etc. at that time too...
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great write-up, Marina! I think this will be fun to implement, e.g. for python-tuf using the new signer API.
I left a couple of minor comments inline, admitting that I don't know sigstore well enough for a detailed review of the signing and verification workflows.
I do have two high-level comments:
-
Talking about "repository" and "developer" in this TAP requires some implicit assumptions about a particular TUF setup. Likely something like PEP 480. For the sake of generality and clarity, I wouldn't make those assumptions. Instead, I would limit the scope to the specification of the new key and signature metadata formats, and the signature creation and verification (online and offline), plus monitoring routines.
-
A more vague and very high-level observation: We are conflating two PKIs here, which both seem to offer similar concepts like key hierarchies, expiry, revocation, etc. I can't pin-point a particular problem with that, I just want us to make extra sure that those concepts are not in conflict with each other, or add extra complexity to TUF without a practical security advantage.
I mention this, because I just made a similar realization with gpg keys and signatures and redundant delegation and expiration checks.
Oh, and some more minor nit-picks (feel free to ignore):
- There's a random mix of
”
and"
in this document. I suggest tos/”/"/g
. (Same goes for’
and'
). - Sentences in lists should end consistently with (or without)
.
.
Signed-off-by: Marina Moore <mnm678@gmail.com>
Especially this: * generalized the "repository" * generalized the "developer" * fixes links Signed-off-by: Marina Moore <mnm678@gmail.com>
Thanks @lukpueh I updated the pr, and tried to generalize away from the "developer" and "repository" terms where possible. The main point is that someone is signing the metadata using an OIDC account, and some central entity is responsible for performing some Sigstore verification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates. I think this is good to be merged as draft. I left a few non-critical comments.
Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com> Signed-off-by: Marina Moore <mnm678@users.noreply.github.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
Thanks @lukpueh! If you think it's ready to be merged as a draft can you mark as approved? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's ready for draft status...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for continuing to drive this @mnm678 ! I am happy to merge this as a draft. I left a few minor comments, but we can easily handle those in a follow-on.
It would be good to get a 👍 from @znewman01 or another Sigstore expert before we do merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With my Sigstore maintainer hat on: this LGTM as a draft.
This TAP proposes the use of Fulcio to improve developer key management in TUF.