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.

Sign up for GitHub

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

Jump to bottom

RFE: private key reference scheme #447

Closed
jku opened this issue Oct 28, 2022 · 4 comments · Fixed by #456
Closed

RFE: private key reference scheme #447

jku opened this issue Oct 28, 2022 · 4 comments · Fixed by #456
Labels
enhancement

Comments

@jku
Copy link
Collaborator

jku commented Oct 28, 2022 •
edited
Loading

Taking this out of #445 as I think it makes sense in general, not just in KMS:

Idea

Let's define an identification scheme for private key materials in Signer:

  • allows applications that sign (TUF repository, or a CLI signing tool) to reference a specific private key, regardless of private key "storage" method
  • allows changing key "storage" (e.g. from RSA-key-in-file to GPG key) with configuration, no code changes needed
  • simple so that it works on CLI and configuration files
  • covers all private key types: private key files, GPG, yubikeys, KMS...

sigstore ReferenceScheme

sigstore has a ReferenceScheme for their KMS abstraction: I think that would work for private keys in general
https://github.com/sigstore/sigstore/tree/main/pkg/signature/kms. There's no requirement to be 1:1 compatible with sigstore, just showing this as a reference of something we could copy.

Proposal

https://docs.google.com/document/d/1KQY5v1ASXpZM5GhfATV_WJf7GaMJrfBOXr06dtxc-ps

Review welcome here or in the doc!
This was referenced Oct 28, 2022
Closed
Merged
jku added a commit to jku/securesystemslib that referenced this issue Nov 2, 2022
@jku
Initial GCP Signer implementation
292986e 
Very bare bones Signer for Google Cloud KMS: Private keys live in KMS,
signing happens in KMS (although payloading hash happens in Signer).

This is not super usable without issue secure-systems-lab#447 but demonstrates the simplicity.
With 447, the usage pattern nwould be

signer = Signer(
    "gcpkms://projects/openssf/locations/global/keyRings/securesystemslib-test-keyring/cryptoKeys/securesystemslib-test-key/cryptoKeyVersions/1",
    pubkey
)

so all GCP specific details are in the private key URI.

Key creation is not supported at this point.
jku added a commit to jku/securesystemslib that referenced this issue Nov 2, 2022
@jku
Initial GCP Signer implementation
92c7d20 
Very bare bones Signer for Google Cloud KMS: Private keys live in KMS,
signing happens in KMS (although payloading hash happens in Signer).

This is not super usable without issue secure-systems-lab#447 but demonstrates the simplicity.
With 447, the usage pattern nwould be

    signer = Signer(
        "gcpkms://projects/openssf/locations/global/keyRings/securesystemslib-test-keyring/cryptoKeys/securesystemslib-test-key/cryptoKeyVersions/1",
        pubkey
    )

so all GCP specific details are in the private key URI.

Key creation is not supported at this point.
jku added a commit to jku/securesystemslib that referenced this issue Nov 2, 2022
@jku
Initial GCP Signer implementation
52882d1 
Very bare bones Signer for Google Cloud KMS: Private keys live in KMS,
signing happens in KMS (although payloading hash happens in Signer).

This is not super usable without issue secure-systems-lab#447 but demonstrates the simplicity.

Key creation is not supported at this point.

A test is added with a few caveats:
* dependencies are not added to requirements.txt: this would
  more than triple the size of requirements-pinnex.txt...
  Not sure what the best path her is
* Test only works on GitHub (because of the authentication)
* There's a separate tox env, meaning the test only runs once
  per test run: this allows testing separate requirements
  but also makes it easier to set very low usage quotas on GCP
jku added a commit to jku/securesystemslib that referenced this issue Nov 2, 2022
@jku
Initial GCP Signer implementation
07ee954 
Very bare bones Signer for Google Cloud KMS: Private keys live in KMS,
signing happens in KMS (although payloading hash happens in Signer).

This is not super usable without issue secure-systems-lab#447 but demonstrates the simplicity.

Key creation is not supported at this point.

A test is added with a few caveats:
* dependencies are not added to requirements.txt: this would
  more than triple the size of requirements-pinnex.txt...
  Not sure what the best path her is
* Test only works on GitHub (because of the authentication)
* There's a separate tox env, meaning the test only runs once
  per test run: this allows testing separate requirements
  but also makes it easier to set very low usage quotas on GCP
jku added a commit to jku/securesystemslib that referenced this issue Nov 2, 2022
@jku
Initial GCP Signer implementation
541ade4 
Very bare bones Signer for Google Cloud KMS: Private keys live in KMS,
signing happens in KMS (although payloading hash happens in Signer).

This is not super usable without issue secure-systems-lab#447 but demonstrates the simplicity.

Key creation is not supported at this point.

A test is added with a few caveats:
* dependencies are not added to requirements.txt: this would
  more than triple the size of requirements-pinnex.txt...
  Not sure what the best path her is
* Test only works on GitHub (because of the authentication)
* There's a separate tox env, meaning the test only runs once
  per test run: this allows testing separate requirements
  but also makes it easier to set very low usage quotas on GCP
jku added a commit to jku/securesystemslib that referenced this issue Nov 2, 2022
@jku
Initial GCP Signer implementation
762766a 
Very bare bones Signer for Google Cloud KMS: Private keys live in KMS,
signing happens in KMS (although payloading hash happens in Signer).

This is not super usable without issue secure-systems-lab#447 but demonstrates the simplicity.

Key creation is not supported at this point.

A test is added with a few caveats:
* dependencies are not added to requirements.txt: this would
  more than triple the size of requirements-pinnex.txt...
  Not sure what the best path her is
* Test only works on GitHub (because of the authentication)
* There's a separate tox env, meaning the test only runs once
  per test run: this allows testing separate requirements
  but also makes it easier to set very low usage quotas on GCP
@jku
Copy link
Collaborator Author

jku commented Nov 3, 2022 •
edited
Loading

Almost complete proposal https://docs.google.com/document/d/1KQY5v1ASXpZM5GhfATV_WJf7GaMJrfBOXr06dtxc-ps -- still debating myself if I should propose a Key class as well but overall this is definitely ready for review

@lukpueh
Copy link
Member

lukpueh commented Nov 3, 2022

still debating myself if I should propose a Key class as well

FYI: There's new Key-related work available downstream in in-toto/securesystemslib. This is part of #370

@jku jku mentioned this issue Nov 4, 2022
Merged
@joshuagl
Copy link
Collaborator

@kairoaraujo would love your input on the design here, especially:

  • URI scheme key reference
  • Importing existing keys (i.e. SSH key or YubiKey) is not yet handled, any thoughts on that?

@jku
Copy link
Collaborator Author

jku commented Nov 21, 2022

  • Importing existing keys (i.e. SSH key or YubiKey) is not yet handled, any thoughts on that?

I swear I wrote about it somewhere, but can't hurt to do it here too:

  • Constructing entirely new keys or importing them is inherently specific to signing system -- we can't create generic APIs and should not try
  • I would add this functionality into Signer implementations:
    • typical use case is going to need both signer and Key at same time (to insert them into their respective storage)
    • since I've made the signer already "own" a public key in the PR, we can add generic API to get that public key from Signer
  • but nothing prevents a specific Key from having a import() method as well if that makes sense for the specific use case

This fits at least the KMS use case and I think it should fit yubikeys as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

signer: Add abstract Key class, implement private key uri scheme for Signer jku/securesystemslib
3 participants
@jku @lukpueh @joshuagl