- Feature Name: Rust Public Key Infrastructure (PKI)
- Start Date: 2024-02-27
- RFC PR: [rust-lang/rfcs#3579](https://github.com/rust-lang/rfcs/pull/3579)

# Summary
[summary]: #summary

This RFC proposes a plan and deployment for generating an initial set of Rust Project root and delegated cryptographic public/private key pairs, with associated X.509 certificate chains, to provide the proper hierarchy for deploying various signature validation techniques across the project.

Having an internal Certificate Authority and delegate keys for the Rust Project allows us to have the infrastructure in place for solving multiple problems currently in the ecosystem such as: signing mirrors, crate package signing and validation, signing binaries for OS security checks, infrastructure security, and future chains of trust for authors and organizations.

We propose the initial creation of a Rust Project Public Key hierarchy, with a root certificate authority and an initial set of single-purpose delegated certificates. For safety and oversight, this infrastructure mandates a quorum scheme (5-of-9) for root key operations, and mandates the use of Certificate Transparency for all subkey issuance *and* individual signature operations.

Finally, we propose an initial, basic architecture for using this public key infrastructure to create delegate keys, as well as signing additional keys for usage in other signing schemas and implementations. Note, these additional implementations and further work is out of scope of this RFC. This RFC strictly covers creating a singular, root Certificate Authority and delegate keys for the Rust Project.

## Out of Scope

This RFC does not attempt to solve:
- Identities or signing of Rust Project members
- Identities or signing of crate authors
- Answering open questions around the benefits or capabilities of any next-generation repository signing solutions (e.g. sigstore or the update framework (TUF))
- Specific design or implementation strategies around binary signing (e.g. for Windows or macOS binaries)

# Motivation
[motivation]: #motivation

The Rust Project currently lacks any official Public Key Infrastructure (PKI) required to perform proper package, mirror, code, and release signing across the project. There is high demand for capabilities that require such PKI infrastructure, such as mirroring and binary signing. This RFC provides the necessary cryptographic infrastructure to unblock such work, and an initial usage for cryptographic verification of Rust releases and `crates.io` downloads.

We have chosen this specific approach to give us the most flexibility in choosing implementations for cryptographic security in future RFCs and implementations. Multiple problem spaces currently exist which can leverage an internal PKI - the most visible and obvious being crate and release signing. However, other avenues also exist - such as mirror validation or internal and external services communication. We see a future in which this Certificate Authority can be leveraged for meeting the needs of these problems, and consider it the first stepping stone towards a solution.

## Threat Model

Detailed below are the specific threats we are addressing in this RFC pertaining to key ownership and distribution:

- **Threat**: Prevent the malicious usage of a compromised key by a known or unknown actor.
**Addressed**: by use of an HSM and quorum model
- **Threat**: Prevent compromise of key material by nation-state or corporate actor (whether by coercing the cooperation of an individual or obtaining the key material illicitly).
**Addressed**: by use of an HSM, quorum model, and geographically and politically distributed quorum members.
- **Threat**: Supply chain compromise of the Rust release process, such that Rust releases a signed binary containing malicious code
**Addressed**: Either by revocation and rotation of the key used, or by verifiers having a mechanism (not specified here) for finer-grained revocation of individual signed artifacts.
- **Threat**: Loss or compromise of key project members
**Addressed**: by use of a quorum model, and by a (loud and painful) process for out-of-cycle root key replacements in the event of quorum loss.
- **Threat**: Compromise of Rust services leading to compromise of root key
**Addressed**: Use of HSM; root key not used for anything except signing delegate keys; processes in place for revocation and rotation.
- **Threat**: Compromise of Rust services leading to compromise of delegate key
**Addressed**: Isolated signing service; process for revocation and reissue of delegate keys.
- **Threat**: Illegitimate use of root key by trusted actor
**Addressed**: Use of HSM and quorum model; no individual trusted actors have the root key. Transparency logging will additionally ensure that misuse would be detected.
- **Threat**: Illegitimate use of delegate key by trusted actor
**Addressed**: Transparency logging will ensure that misuse would be detected. Delegate keys can also be revoked and rotated.
- **Threat**: Compromise of HSM
**Addressed**: HSM hardware security mechanisms, and transparency logging mechanisms.
- **Threat**: Failure/destruction of HSM and/or key material
**Addressed**: HSM backups; (loud and painful) process for out-of-cycle root key replacements

## Mirroring

There is currently no way for end users to cryptographically guarantee, in isolation, that an index entry, crate package, or Rust release was definitively sourced from the Rust Project. Although the entirety of the current end-to-end system provides some protections (hashes in the index of crate files, and HTTPS for all communications), this precludes many out-of-band mirroring scenarios and is subject to multiple attack vectors.

This proposal adds cryptographic security for multiple mirroring scenarios:
- Rust releases (downloaded directly or via `rustup`)
- `crates.io` index
- `crates.io` packages

Today, for `crates.io` and official infrastructure, we strictly distribute from Rust Project controlled sources (our CDN network). This prevents us from leveraging mirroring offers from third parties, such as academic institutions, to host copies of crates.io packages as well as Rust releases. Having a set of root cryptographic keys gives us the tools to begin exploring multiple methods of securing both internal and external mirroring and propagation problems.

We leave the implementation of these solutions for a future RFC - however, this provides us with the first steps in having the available cryptographic keys to begin exploring and discussing solutions to these problems.

## Private Repositories

The technical details of this proposal involve the initial signing of the index and crate files utilizing the Rust Project root key for validation. However, the implementation of this in cargo will allow for private repositories to validate against additional certificates. This means all new security guarantees made with the new Rust keys can also be leveraged by private repositories for private certificate chains. (Cargo will not, however, allow the substitution of different keys for `crates.io` itself.)

## Provenance

Utilizing our PKI and certificate hierarchy, end users (manually or utilizing `rustup` and `cargo`) will be able to cryptographically verify the provenance of arbitrary files, regardless of source, as being from the Rust Project.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

We propose leveraging [AWS CloudHSM Quorum Authentication](https://docs.aws.amazon.com/cloudhsm/latest/userguide/quorum-authentication.html) for the management of the `Root Key`. See [Alternative Quorum Tools][alternative-quorum-tools] for other quorum models which were considered.

All operations using the root key or subkeys will be logged transparently, and will make use of Certificate Transparency / Binary Transparency infrastructure to ensure that no surreptitious signing operations can take place.

## Keys and Trust

**Key Algorithm:** The root key will use secp384r1, since this is supported by CloudHSM and a variety of other HSMs. Delegate keys may use other algorithms (e.g. ed25519) as appropriate and specified in the proposal for a delegate key. We should re-evaluate the algorithm strength each time we rotate the root key.

**Storage:** PKCS #11 Certificates Stored in CloudHSM. These are backed up in-cloud every 24 hours. In the event complete loss of key material occurs, it shall be treated as a full out-of-cycle rotation.

**Expiration:** Root and Top-Level Delegate keys shall follow a `7 year expiration` schedule, except for the first keys of this proposal, which shall have an expiration date of the expected release date of the Rust 2030 edition plus 1 year.

Expiration allows us to re-evaluate algorithm choice and algorithm strength, archive transparency logs, and have a well-tested path for root key replacement.

### First-Issue Expiration Plan

We shall schedule expiration on the key to match the `Rust Edition Cycle`, so any key expiration will also fall within the time frame of a new Rust edition. This cadence is chosen to ease the rotation and release and dissemination of a new `Root Key` aligning with an edition and thus, new releases of `cargo` and associated tooling.

The first key shall be created with an expiration of `2031`, or 8 years, allowing for rotation of the key with the `2030 Edition` of Rust.

All subsequent keys shall be created with a `7 year` expiration, aligning with the date of 2 Rust editions into the future, with 1 additional year allowed for key deployment prior to rotation.

- First Root Key: Generated 2024, 7 year expiration. Expires: 2031, Rotated with: `2030 Edition`
- Second Root Key: Generated 2030, 7 year expiration. Expires: 2037, Rotated with `2036 Edition`
- This schedule shall continue until the end of the universe.

### Rust Project Root Key

Shall delegate all trust to Rust Project child certificates. From this point, referenced as `Root Key`.

- This key shall be created in an AWS CloudHSM instance and shall reside exclusively in this instance.
- It shall not be exported or utilized in any other methods except by quorum (5 of 9) directly within the HSM.
- It will be managed by quorum authentication, preventing access, usage, or changes to quorum regarding this key except when a quorum authentication occurs.

#### Quorum Model

This HSM instance will be created within the Rust Project AWS account. After initial creation and configuration, the quorum shall be the only entity capable of administering or utilizing the root key in the HSM. Network access to the HSM shall be limited to a PKI bastion [Signing Console][signing-console], which shall only be powered on for scheduled signing events. See the reference-level [Signing Console][signing-console] description for further details on this system.

The root key shall follow a `5-of-9` authentication model for all operations. We consider this a reasonable middle ground of quorum to prevent malicious activity, while allowing for rapid response to an event requiring a quorum. These events are iterated below in [When the Quorum will be needed][when-the-quorum-will-be-needed].

This proposal delegates the authority of selecting and managing the quorum membership to the Rust Project's Leadership Council. We recommend they be selected from trusted individuals within the Project and Foundation. This is a position of trust, not one of authority over anything other than safe handling of key material; the 9 members are responsible for executing quorum operations, and providing transparency and trust (through their refusal to participate in any malicious operations), but not for deciding independently what key operations should happen.

Authentication to the CloudHSM instance shall be limited to only a [Signing Console][signing-console] at the network layer; at the application layer, we shall create IAM roles and accounts for all members of the quorum. These accounts will required two factor authentication and have restrictive password, timeout, and security policies applied. These roles shall only be used for Quorum signing events. There will be documentation for the quorum members on best practices for handling their credentials.

These individuals should be available in the event quorum is needed for root key operations. These roles can and should be reappointed as needed, but to simplify logistics, these roles should not require rotation more often than 2-3 years. (Operations requiring quorum are expected to be rare, and an annual rotation would make rotation of the quorum group the vast majority of quorum operations.)

##### When the Quorum will be needed
[when-the-quorum-will-be-needed]: #when-the-quorum-will-be-needed

- Changes to quorum membership or thresholds shall require a quorum (enforced by the HSM authentication)
- Replacement of the Root Key in the event of expiration or compromise
- Creation, signing, and issuance of a new Delegate Key
- Creation, signing, and issuance of a replacement Delegate Key in the event of expiration or compromise

##### Quorum Threat Mitigations

- To reduce the feasibility of coercion or collusion, we recommend that no more than 3 (M-2) of the 9 people be affiliated with any one company or institution, or be residents or citizens of the same country. (If in the future the quorum threshold is changed, this limit should be changed accordingly to remain M-2).
- If in the future a desire arises to modify the quorum, we strongly recommend growing the size of membership rather than reducing the quorum threshold. The quorum exists to mitigate against bad actors, and is not implemented to prove a majority.
- To reduce the feasibility of coercion or collusion, we recommend that members of the quorum be selected from within the Rust project, community, Foundation staff and/or Foundation Board. This allows us to spread trust and responsibility among socially and fiduciarily responsible parties.
- There is value in the members of the quorum generally residing in geographically and politically distributed locations most of the time. This RFC does not place any requirements regarding quorum member colocation for events or travel; the project and the quorum members can appropriately evaluate the value of such events and the corresponding risks.
- Hardware keys shall be utilized for two factor authentication for Quorum IAM accounts; phone-based or weaker methods of 2FA authentication cannot be used

### Delegate Keys

Delegate keys shall be used for purposes within the realms of their designated responsibility and team(s). It shall be up to the individual implementors using these keys to make sure to verify their trust up to the Rust root or to the appropriate delegate key for their usage. For example, it shall be an implementation detail for the crates.io and cargo teams on whether to verify signatures up to the Rust root key, or to their specific delegate keys for other purposes. This is done to allow for the greatest flexibility of users of the keys.

Delegate keys will use appropriate mechanisms within the key format to specify the purposes the key can be used for, and verifiers relying on delegate keys should then verify those purposes.

- Release Key
Used to sign Rust nightly and stable releases. rustup can verify that downloaded releases are signed by a key with this role that chains up to the root, and verify that the key and the release signature are recorded via Certificate Transparency / Binary Transparency authenticated logging mechanisms. Another subkey of this may be used for code signing.

- crates.io Key
Top-level key for the crates.io ecosystem and project. This will be an authoritative key for signing indexes, and potentially signing crate packages directly. (For logistics reasons, crates.io may choose to issue subkeys under this key to perform signing.) Note that even if crates.io signs package files, it still needs to sign indexes for verification as well, because cargo gets some information from the index rather than the crate.

- bors Key
bors will use per-repository subkeys of this key to sign all git commits it makes. This allows people to use mirrors of our git repositories and verify the authenticity of those mirrors. We will document a procedure to download and update Rust git repositories from a mirror, with verification, while working with the original for issues and pull requests. This delegate key shall be used to generate further subkeys to be used on a per-repository basis; the delegate key itself will not be used to sign git commits. See [using-github-bot-sign][using-github-bot-sign] for details on the threats posed by using built-in github bot signing.

### Key Transparency (`pki.rust-lang.org`)

All certificate operations on the Root Key and the top-level Delegate Keys will be logged via Certificate Transparency, on a domain [pki-rust-lang-org][pki-rust-lang-org]. (This prevents issuing or using a Delegate Key surreptitiously.) Each issued key must have proof of the Certificate Transparency record stapled to it.

Examples of certificate transparency logging technologies include the WebPKI infrastructure (<https://certificate.transparency.dev/>) and Rekor (<https://docs.sigstore.dev/logging/overview/>). We leave it up to the implementors of this RFC to determine self-hosted or public hosted solutions be utilized.

In addition, we recommend that binary signatures make use of Binary Transparency. (This prevents `crates.io` from serving a signed index or crate file to a subset of requests without logging it publicly.)

Some uses of delegate keys may also wish to make use of an OCSP service and OCSP stapling for revocation; we defer this to subsequent RFCs specifying individual delegate key usage.

### Rotation & Revocation

- Delegate Keys can be re-issued and re-signed by the Root Key
- Root Key rotation may require a Rust/Cargo/rustup update to update the local certificate
- Any rotation, especially any out-of-cycle rotation (e.g. compromise or infrastructure change) will by design be very *loud* and involve many people who can raise a red flag over any concerns of impropriety.
- Users who need to use toolchains older than 7 years old, *and* who still need to download from the network (rather than vendoring), can either disable signature verification or can use a documented procedure for updating the toolchain's included root key. (This may result in the toolchain printing an appropriate warning on network access so that the user is aware the key has been replaced.)

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

## Signing Console
[signing-console]: #signing-console

The Rust Infra Team will deploy a new SSH bastion host, `pki-bastion.rust-lang.org`, which shall be used for performing all PKI operations. This system will have available to it a suite of scripts for performing all the common scenarios mentioned in [When the Quorum will be needed][when-the-quorum-will-be-needed]. Current members of the quorum will authenticate to this system utilizing IAM roles via EC2 Instance Connect, which will force them to use their IAM role with two factor authentication (which will double as their role utilized for the actual quorum process).

- This system shall be isolated and powered down except for scheduled quorum events or regular security updates to the system.
- The Infra team will deploy monitoring for this system to alert on all logins and power events, allowing us central monitoring and control of the quorum bastion.
- Activity alerts shall be independently sent to all quorum members in the event of accessing or modifying the keys present on the HSM.
- The Infra team shall limit access to the HSM to only this Signing Console, preventing lateral movement or compromise of the CloudHSM instance from any other system within the Infrastructure.

## `pki.rust-lang.org`
[pki-rust-lang-org]: #pkirust-langorg

The Rust Infra Team shall stand up a new subdomain for the exposure of transparency logs and operational logs of the PKI. We leave the implementation details of such a system up to the Infra team and project. This system shall store and publicly serve all data which relates to the activities of the Rust CA, its delegate keys and quorum activities.

This publicly accessible data shall be:
- A write-only storage medium in which modification of past entries is not possible.
- Written documentation of this RFC and additional documentation on the services, scripts and processes for the quorum model.
- Access logs to the [Signing Console][signing-console] containing the username and datetime of access. This shall be signed by a verifiable delegate key which chains trust to the Rust Root.
- Access logs to the CloudHSM instance, containing IAM role and datetime of access. This shall be signed by a verifiable delegate key which chains trust to the Rust Root.
- Written records of all Quorum Events. These shall contain: Event Description, Quorum members present, date/time of beginning and ending the event, cryptographic fingerprints of keys modified, created or revoked. This written record shall be signed independently by each quorum member present for the event.

# Drawbacks
[drawbacks]: #drawbacks

This will add new complexity for the project to manage, though that new complexity will provide corresponding benefits.

This adds additional questions for future signing and PKI work to be done within the project; in the case of implementing TUF, sigstore, etc. we will have to make additional considerations for how this CA may play into those systems and how it can be included or excluded.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

In addition to signing index files, we could also sign crate files themselves. The signed index files will include a hash of the crate file, which will enable verification, but we should evaluate if there are any circumstances where direct crate file signatures would help.

### Foregoing a Root Certificate Authority

Other frameworks for providing additional security we might want within crates.io, such as TUF, implement other methodologies, such as multi-signer schemes. We consider this a separate problem space, and this initial certificate authority can be used independently or integrated with such a solutions. We do not dismiss this approach, and future plans may involve leveraging our CA for providing an additional level of security to such a solution (Rust signing of delegate keys which are used for signing repositories, for example). However, other uses for a CA exist which cannot directly leverage the multi-signer schema for security. The approach proposed in this RFC bridges from a quorum scheme to a CA model in order to allow the use of widespread existing implementations based on the CA model.

### The Update Framework

This RFC does not preclude deploying TUF as a solution for crate and mirror signing. However, one thing to keep in mind is TUF does not solve issues around the quorum, how it is managed, where signing occurs, or how it occurs; TUF provides a model hierarchy for signing and how trust among keys for a file index occurs, and easily rotatable keylists for hierarchical trust. We would still have the problems around how we select a qourum, how and where signing occurs, and where the trust lies. We would still need to determine how we select our TUF quorum, who they are, how and where they perform signing. All those problems are deferred but TUF - but iterated in this RFC.

Part of this approach is meeting our requirements in a model which is understood and applicable by a broader audiance - doing this for a CA is well understood and implemented, while within TUF is only understood and applicable in that context.

In a future where crates.io implements TUF, this CA and quorum would exist as the Root Role, where then we delegate Target roles to crates.io delegate key, and then utilize the TUF model underneath that. We'd still need to solve our quorum, ceremonies, etc. but it would only apply to TUF - a problem space addressed in this RFC. Said another way, a majority of this RFC applies to problems that we also need to solve in TUF, but at a broader scale utilizing a full CA and not strictly within the TUF model.

### Bearer Access to the Root Key (non-quorum, non-HSM)

Legacy Certificate Authorities have also followed a model which allows for the centralized storage and distribution of a root key directly, and its generation and access being based on ownership (Bearer Security). This model is vastly simpler than a quorum and delegate model, but comes with many historical issues currently present in many PKI solutions.

Given the highly distributed, global, and open operations of the Rust Project, and the possibility for coercion/compromise, it is within the spirit of the project to make sure to distribute control and access of the PKI. We hope for the quorum model to provide the project with the control and security of its PKI while not limiting its usage or further burdening the Leadership Council or Project members. Lastly, we are addressing multiple threats which exist for a singular bearer key environment - compromise, rogue actors, or forced coercion are real threats when a singular entity can be compromised to obtain the key.

### Relying solely on transparency logs

Given that we already need transparency logs to handle misuse of a delegate key, and to handle mis-issuance of a delegate key by the root key, we could rely solely on those transparency logs, and use a simpler scheme for handling the root key material. For example, we could use an HSM without the quorum model, or one or more offline physical HSMs, or a non-HSM-based system.

The explanations of the threat model include threats specifically mitigated by the quorum system and by the use of an HSM. In addition, the quorum system and the use of an HSM provide defense-in-depth protecting the root key by means more than just transparency logging, particularly since the transparency logs themselves will have a chain of trust leading up to the root key.

Lastly, strictly using transparency logs with quickly rotated private key material shifts the responsibility of implementing delegation and trust to the implementing user; we wish to provide this trust inherently in our implementation for easier use.

### Foregoing Delegate Keys

We shall utilize delegate keys for actual day-to-day operations within the project to mitigate the threat of broad compromise. This means that in the event of, for example, crates.io being compromised and its keys needing rotation, we will not impact other areas in which the PKI is utilized. This allows us to securely isolate the impact of incidents as well as be flexible in the duration and expiration of various delegate keys within the project. Said another way: delegate keys grant us more granular control of the use cases of the PKI while protecting the PKI as a whole from compromise.

### Utilizing a Multi-Signer schema for the Certificate Authority

Instead of a quorum authentication model for a legacy Certificate Authority set of Root Keys, we could move to a multi-signer scheme which will be validated for all the uses cases we expect this to cover. The drawback of such an approach is that most standard scenarios in which we will want to utilize such a set of key instances do not support such a model; it would be an approach to only solve the issue of repository and crate signing. We have legitimate cases which can benefit from an SSL CA (Infra internal services, code signing, etc.) which do not support multi-signer keys. We hope this RFC will be leveraged for future uses, but consider that question out of the scope of this RFC.

### Alternative Quorum Tools
[alternative-quorum-tools]: #alternative-quorum-tools

Other solutions exist for performing Quorum-based authentication for key access, which support various storage backends. The main alternative for such a standalone solution would be utilizing a quorum authentication plugin on a cloud-agnostic storage system (Such as Hashicorp Vault, or a cloud-agnostic authentication scheme atop a cloud key storage, such as AWS key store). These solutions would allow us to deploy and move independent of cloud providers; however, this comes with the added infrastructure overhead of the Infra team needing to implement and maintain such a solution. This choice was considered but thought prohibitive to implement and maintain for the current staffing available to the project. Finally, these solutions do not exist in hardware due to the need to remain cloud and hardware agnostic.

Given the majority of Rust Infrastructure currently resides on AWS and will for the near-to-medium term future, CloudHSM was chosen as the solution of choice for this given it meets all requirements. In the future, it is possible to extract our private keys and implement quorum authentication in another system. (Such private key extraction may have a higher quorum threshold.)

### Using the GitHub bot key to sign bors commits
[using-github-bot-sign]: #using-the-github-bot-key-to-sign-bors-commits

As an alternative to having a dedicated delegate key for bors that chains to the Rust Root, we could rely on GitHub's commit signatures for bot accounts. However, this would not allow users of git mirrors to be resilient against impersonation of rust-lang/rust. Any GitHb project that uses bors could push a branch that is a clone of rust-lang/rust and get bors to add and sign malicious commits. That history could then be pushed to a purported "mirror" and would appear the same as a legitimate mirror of rust-lang/rust, allowing for social engineering attacks. Using per-repository keys makes mirrors easier to verify and reduces attack surface area.

### Preventing Vendor Lock-in

This RFC attempts to limit our exposure to singular points of failure or compromise by relying on entities for the totality of our security. A choice was made to utilize Amazon CloudHSM as a hardware solution for key storage; but we have chosen not to use internal cloud-specific CA mechanisms in this case to avoid being further bound to a single providers ecosystem. The scheme described in this RFC can be moved to other HSM or storage backends with no other dependencies on a specific service.

# Prior art
[prior-art]: #prior-art

[IANA uses a quorum system and "signing ceremony" for the root keys of DNSSEC](https://www.iana.org/dnssec/).

[Sigstore performs a signing ceremony among multiple root signers](https://github.com/sigstore/root-signing).

`kernel.org` was compromised, which forced them to evaluate and address their threat model. They've assessed their threat model to include very well-funded security threats, as well as nation-state-level legal attacks and security threats. In this RFC, we're proposing an infrastructure that addresses comparable threat models.
https://lwn.net/Articles/464233/
https://www.theregister.com/2011/08/31/linux_kernel_security_breach/
https://arstechnica.com/information-technology/2013/09/who-rooted-kernel-org-servers-two-years-ago-how-did-it-happen-and-why/

Relevant past RFCs:

[RFC #3403: sigstore and cargo/crates.io](https://github.com/rust-lang/rfcs/pull/3403)
[TUF for crates.io discussion](https://github.com/withoutboats/rfcs/pull/7)
[Validate signatures of builds](https://github.com/rust-lang/rustup/issues/241)

# Unresolved questions
[unresolved-questions]: #unresolved-questions

- Who shall be members of the Quorum? This RFC leaves this question to the Leadership Council. The quorum could consist of Council members, or the Council can choose to delegate authority to trusted indivuals, such as the existing Security Response or Secure Code working groups; or the formation of a new Security/PKI working group with a limited scope of managing these keys and performing ceremonies.

# Future possibilities
[future-possibilities]: #future-possibilities

**Crate Signing / Mirroring**: A subsequent RFC will specify how we handle crates.io index signing, to enable mirroring and other requirements.

**Code Signing**: This RFC provides a chain of trust that can in the future be used for signing binaries for Apple/Microsoft binary authentication. (This would require generating a CSR for a key chaining to the Rust Root, and then getting that CSR signed by the appropriate Microsoft/Apple process.) However, this RFC does not specify a mechanism or process for such signing; establishing that is future work. A subsequent RFC will specify how we handle code signing.

**Git mirroring**: This RFC specifies a delegate key for bors to sign git commits, but does not specify any scheme for mirroring Rust git repositories. Future RFCs will specify how we handle git repository mirroring.

**OSCP/CRL/Transparency Log/Stapling**: Do we wish to set up an OCSP service, CRL, Transparency Logs, and/or perform stapling? Future implementations of these types of services can reside on [pki.rust-lang.org][pki-rust-lang-org], meeting its purpose of providing transparency to our PKI. We leave it to future implementation and RFCs to discuss the use cases of these systems.

**Internal Signing Service**: A microservice endpoint to provide authenticated signing of binary blobs with various keys for roles. This could be implemented in AWS via roles for allowing different teams to perform binary blob signing using their issued keys without disclosure of the keys.

**Infrastructure mTLS**: Rust infrastructure that wants to use mTLS could potentially use keys chaining to the Rust Root. This could include additional security for crater runners, build servers and databases.

**The Update Framework**: How can a root CA increase or decrease the complexity of a future TUF implementation? For example, the CA can be used to sign root keys; and validation of root keys could be done via the CA and its OCSP revocation service; this could allow central and easier management of root keys used for the multi-singing of a TUF repository for crates.io.

**Sigstore with TUF**: Should sigstore be implemented? How can this be leveraged with TUF - do we sign delegate signing keys to allow for central control & authorization of repository root keys? How does this play into revocation https://blog.sigstore.dev/sigstore-bring-your-own-stuf-with-tuf-40febfd2badd/