Proposal: Integrate with attestation for hardware-backed keys

[jalseth]

Description

Some use cases prefer using hardware-backed key storage to (hopefully) ephemeral software keys. Some hardware devices support attestation to prove the key material is generated on the device, is non-exportable, and other attributes such as the serial number of the device. Fulcio could accept these attestations, verify them, and then embed them in the x509 extensions for the certificate it issues. To protect user privacy, all official Fulcio clients must place this functionality behind flags/config options to protect against accidental upload of this info.

Open Questions

• How should Fulcio determine which attestation roots should be trusted?
  • What is the story for when/if we need to revoke trust due to abuse?
• Should Fulcio map vendor OIDs to normalized Fulcio OIDs, or just embed the full vendor attestation x509?
  • If normalized, should Fulcio give a way for clients to specify that some of the fields should not be published (such as serial number) to allow for better privacy?

[haydentherapper]

Related to #66. We chose to not pursue this at the time since it encouraged developer-managed keys, which is not what the public infrastructure is focused on. This feature fits into the larger story around supporting private deployments and optionality for key management mechanisms.

How should Fulcio determine which attestation roots should be trusted?

Either a model like what we have with OIDC, where it's a set of trusted configured providers, or blindly accepting attestations without verification and letting the client handle verification.

What is the story for when/if we need to revoke trust due to abuse?

A solution for this could look the same as solving revocation for OIDC compromise. You could leverage TUF to distribute attestation roots.

[jalseth]

Where it makes sense, I think Sigstore public infrastructure should be agnostic on what is trustworthy and should defer to the client to build a verification policy. I would like to accept attestations from any source as long as the certificate chain is valid. This removes the need for Fulcio to have a revocation story which I think makes sense. For private instance use cases, this would still allow those users to specify which attestations should be trusted and monitor for suspicious events like a new hardware-backed private key being associate with a user identity (especially if the device serial changes).

But this presents a problem: How to map vendor OIDs to standardized Fulcio OIDs if Fulcio doesn't have any vendor-specific code? I'm thinking this could be worked around by having the client supply a map for the OIDs, but that is increasing the complexity of the service. Thoughts?

[trishankatdatadog]

I agree with Hayden that Fulcio has not been designed to solve this problem. This is an excellent problem that I think demonstrates why software repositories¹ should use TUF to solve the problem of which public keys should be used to verify which packages². In this manner, a package repository could say that package A is supposed to be sign using Fulcio's ephemeral keys, whereas package B is supposed to be signed using a long-term hardware-backed key.

Cc @znewman01 @mnm678

Footnotes

1. See the OpenSSF Securing Software Repositories WG. ↩

2. See PEP 480 for an example of how this could be done. ↩

[jalseth]

I agree that it should be up to the client to implement a verification policy that suits its use case and that Fulcio should not try to solve what is trustworthy and what is not for all users. But, it is useful to have Fulcio embed attestation properties without having to store and manage those separately. Fulcio already does this for the tokens issued by CI platforms.

[trishankatdatadog]

I was suddenly curious about whether Fulcio supported long-term keys, and I was surprised that the spec suggests it does. In that case, I'm not sure there's a strong argument (except for priorities and community enthusiasm for the idea) against supporting hardware-backed keys.

[haydentherapper]

I was suddenly curious about whether Fulcio supported long-term keys, and I was surprised that the spec suggests it does.

Correct, Fulcio does not track key usage so clients are free to reuse keys.

Note that Cosign does support hardware-backed keys. The benefit of this feature would be proof of possession of a hardware-backed key.

[trishankatdatadog]

Correct, Fulcio does not track key usage so clients are free to reuse keys.

Yes, on second though, this is not as surprising as thought. What's really short-lived are Fulcio's certificates, not necessarily the leaf/user certificates.

Note that Cosign does support hardware-backed keys. The benefit of this feature would be proof of possession of a hardware-backed key.

Right: the Q here as I understand James is whether Fulcio should validate those attestations before recording.