TAP for TUF developer key management

[mnm678]

This TAP proposes the use of Fulcio to improve developer key management in TUF.

[mnm678]

cc @JustinCappos

[trishankatdatadog]

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?

[mnm678]

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?

[axelsimon]

Rendered version here, for those interested.

[axelsimon]

Just a few more comments / suggestions on this. Thanks for turning it into a TAP @mnm678!

[mnm678]

Thanks for the review @axelsimon! I updated the document

[axelsimon]

A few more comments.

[mnm678]

@trishankatdatadog @joshuagl Any blockers on having this merged in as a draft?

[joshuagl]

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?

[mnm678]

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?

Added

[mnm678]

@trishankatdatadog @erickt I made edits and responded inline. Any objections to merging as a draft?

[axelsimon]

A few more suggestions, trying to resolve open conversations / comments.

[mnm678]

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?

[mikhailswift]

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.

[mnm678]

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.

[mnm678]

@JustinCappos @trishankatdatadog @joshuagl are we ready to merge this as a draft?

[JustinCappos]

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...

[znewman01]

someone from the Sigstore side also review this
Consider this comment an IOU. I'll also circulate it more generally.

Ideally we would have more clarity around monitoring TLs, etc. at that time too...
@SantiagoTorres is pushing hard on this on the Sigstore end so I bet he'll be a good source for updates. I think @mnm678 is also thinking about TUF<->TL interactions more generally as well.

[lukpueh]

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:

1. 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.

2. 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 to s/”/"/g. (Same goes for ’ and ').
• Sentences in lists should end consistently with (or without) ..

[mnm678]

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.

[lukpueh]

Thanks for the updates. I think this is good to be merged as draft. I left a few non-critical comments.

[mnm678]

Thanks @lukpueh!

If you think it's ready to be merged as a draft can you mark as approved?

[JustinCappos]

I think it's ready for draft status...

[joshuagl]

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.

[znewman01]

With my Sigstore maintainer hat on: this LGTM as a draft.

[mnm678]

I'm going to merge this, with #168 as a followup to address some minor comments, and #169 to document future changes, especially those that are pending documentation from the Sigstore side.