How to map worker private keys to metadata public keys?

[Lukas Pühringer]

What do you want to share with us?

The existing mapping in LocalKeyVault does not work (see repository-service-tuf/repository-service-tuf-worker#431 for details). Potential fixes are:

1. improved heuristic mapping (via container config)
   The heuristic key mapping (status quo) can be improved, e.g. by deriving the public key from the private key and matching it to a canonical version of the public key in the metadata, or by just trying sign-verify over known data.

   pro:

   • private key location does not need to be known to generate metadata
   • public key id does not need to be known for private key configuration (agreement about the key still needed!)
   • online private key location change does not need new metadata

   con:

   • requires significant engineering to implement for custom key matching for each supported signer/key type
   • solution is orthogonal to tuf key/signature matching, which relies on keyids
   • the signer API does not guarantee that a public key can be derived from a signer
   • relying on canonical public keys seems brittle
   • requiring sign-verify seems like a waste of cycles

2. private key config is included in public key (via TUF metadata)
   Approach is documented in detail in a blog post(see example 1). It assumes that the way a public key is imported and included in TUF metadata says something about how to access the related signing key. This is true for e.g. Cloud KMS services, but may not work well for file-based keys.

   pro:

   • aligns with Signer API recommended usage pattern
   • requires minimal engineering effort to load any supported signer (see SignerStore.get (POC)).
   • no other key location configuration needed, as long as the private key is available at the configured location

   con:

   • requires private key location knowledge for metadata generation
   • key location change requires new metadata

3. private key config includes public key id (via container config)
   This keeps the status quo of separate private key configuration, but adds keyids from the TUF metadata to the config to provide an explicit mapping.

   pro:

   • Has all pros from 1
   • May have pros of 2, if the private key location info has the URI format, which is understood by the Signer API

   con:

   • Manually configuring keyid=uri is bad UX (can be mitigated by providing a CLI)
   • Duplicates the effort of identifying the (public) key location to import the key into metadata and the (private) key location to configure the URI.

References

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Lukas Pühringer]

Summary from discussion with Kairo:

• We rule out option 1.
• Option 2 is problematic, because we want to support a use case, where the metadata role has no access to the signature provider, and thus cannot import the public key or configure the online signing key location.
• Option 3 is appealing, because it seemingly separates metadata role and key role, e.g.

1. key role configures signing key in worker and maps it to public key with keyid
2. key role provides public key and keyid to metadata role.
3. metadata role uses RSTUF cli to import public key into metadata, assign keyid, and add other metadata details (expirations, offline keys, etc.)
4. key role may change signing key config, without the need to update the metadata

• Problems:

  • This is a lot of work, for which we don't provide tooling (except 3.)
  • The metadata role still needs knowledge about the public key and how to identify the related private key. This info is just relayed by the key role.

• Alternative process:

1. key role uses RSTUF CLI to import public key directly into metadata, including the signing key location.
2. key role provides metadata to metadata role.
3. metadata role uses RSTUF cli to add other metadata details (expirations, offline keys, etc.)

• This is actually Option 2.
• There are workarounds to allow changing singing key file locations, without changing the metadata (e.g. "relative file path uri").

[Jussi Kukkonen]

There are workarounds to allow changing singing key file locations, without changing the metadata (e.g. "relative file path uri").

I mentioned this in chat: I don't consider this a workaround but a good solution that matches the Signer API design. I believe The signer API has this (possibly not explicitly stated) design element:

Signer configuration happens in two parts

1. details specific to this key: privkey URI
2. generic signing system configuration: ambient, expected to be handled by the application

Examples of the ambient configuration:

• GCPSigner expects Application Default Credentials to be set: alternatives include running gcloud CLI or using the google-github-actions/auth GitHub Action
• HSMSigner expects a Yubikey to be attached, and that the Yubikey contains the correct signing key

It feels 100% applicable for FileSigner to prefix the private key paths with an environment variable: this is the ambient configuration in the FileSigner case. I totally think FileSigner or something like this should be in securesystemslib (personally I will never put private keys on disk again if I can avoid it but I support this being an option for others).

[Kairo Araujo]

It feels 100% applicable for FileSigner to prefix the private key paths with an environment variable: this is the ambient configuration in the FileSigner case. I totally think FileSigner or something like this should be in securesystemslib (personally I will never put private keys on disk again if I can avoid it but I support this being an option for others).

RSTUF Project doesn't recommend it as well, but for some tests or development environments might be a use case. :)