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

Support private PKI #34

Open
ianlewis opened this issue Apr 20, 2022 · 4 comments
Open

Support private PKI #34

ianlewis opened this issue Apr 20, 2022 · 4 comments
Labels
type:feature New feature or request

Comments

@ianlewis
Copy link
Member

ianlewis commented Apr 20, 2022

It would be useful to support private PKI.

@steiza
Copy link

steiza commented Apr 20, 2022

Yeah, so when I heard about this project I thought of it as made up of two steps:

  1. Taking workload identity information (like from GitHub Actions) and encoding it into an in-toto document with SLSA predicates

  2. Generating a signed attestation of the in-toto document, so it can be verified downstream

For (2), there are many advantages of using public sigstore infrastructure: individual projects don't have to manage PKI, there's a public transparency log, ... etc. The expectation is that this is what most open source projects would do.

But there might be cases where people don't want to use public sigstore infrastructure, maybe because the don't want their transparency logs to be public, or because they have their own PKI they way to use. In that situation, it would be nice if this project supported just generating the in-toto document (i.e. just step 1 - which they could then sign however they liked), or maybe even different options for signing other than public sigstore infrastructure (i.e. step 2).

That said, there is a lot of value in having an opinionated paved path, and maybe having different options for (2) adds more confusion than it's worth. There's nothing stopping people from implementing support for their own PKI as they need it!

@ianlewis
Copy link
Member Author

I think it's definitely something that could be considered and supported. In order to keep it simpler, maybe it's something we should wait on implementing until folks are specifically asking for it?

If we did implement it, we could allow folks to specify their own address for rekor/fulcio servers in a config file at the base of the repo like the one slsa-github-generator-go has.

@ianlewis ianlewis added the type:feature New feature or request label May 18, 2022
@asraa
Copy link
Collaborator

asraa commented Sep 15, 2022

we could allow folks to specify their own address for rekor/fulcio servers in a config file at the base of the repo like the one slsa-github-generator-go has.

The biggest challenge around here is verifying against the correct TUF root: folks would need to specify addresses for rekor/fulcio but also the trusted root CA and rekor public key they expect. That information would need to be pushed to the SLSA verifier as well.

I don't know the best solution for this yet. Do we specify the whole TUF root? On the generator side I suppose we only need to specify the rekor/fulcio, and the end-users need to know the TUF root.

@ianlewis
Copy link
Member Author

The biggest challenge around here is verifying against the correct TUF root

How do sigstore tools handle this currently?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants