SPIFFE ID Federation Planning

[dlorenc]

We now have support for SPIFFE IDs, and federation through #107!

This means we can issue certs for subjects like spiffe://somedomain.com/foo/bar, and authenticate them against an OIDC endpoint. Right now we require that the OIDC endpoint be at or above the same (sub)domain of the SVID. An OIDC endpoint of foo.com can grant SVIDs for bar.foo.com, but not the other way.

We can also grant subordinate certificates (certificates signed by our certificate, that are also permitted to act as CAs) to other nested Fulcio instances.

What we're still missing is process and automation for adding these domains to our config and issuing subordinate certs.

Proposal

Allowlisting

Let's start manual. We can use a pull-request based, "gitops-style" enrollment process. We'll create a config file in this repo to map to our production config. Users can open a pull request (or maybe issue first?) requesting that we add their domain to our production config.

We can do basic due-diligence that the requester is actually authorized and intends to enable this, and codify this process over time. This could be automated longer-term with something like ACME.

We can automatically "expire" these entries by setting them for removal after some time period unless the requester wants to remain in the list. Let's start with 6 months.

We'll need at least the following:

• Contact info (email address)
• Verify this email address
• OIDC endpoint
• Intended sub-domains or any other restriction on the SVIDs
• What else?

Subordinate Certs

Same as above, let's start manual. We can grant certs for 3 months and setup automation to renew. These should ONLY be used for signing certs with SVIDs matching the domain, similar to above. Let's look into how to enforce this.

We can do stronger proofs here like ACME, but this is probably a bigger challenge at first than manual issues. Here we'll need:

• Data for the CSR (public key)
• Contact info
• Domain to allow SVIDs under

[dlorenc]

cc @asraa - we need something similar for our TSA certs.

[dlorenc]

Let's create a directory (in this repo for now) that will contain entries. For each entry, let's have:

• A contact email
• The OIDC endpoint
• The expiration date for the entry (can be bumped)
• A text description of the use-case for certificates

[haydentherapper]

In addition to email verification, should we also verify proof of ownership over the domain? This avoids domain squatting issues. We could use DNS entries to verify domain ownership, like what Google Cloud Storage does to verify ownership.

[dlorenc]

ACME can work here too.