docs: adrs: Bootstrapping: Key Signing Ceremony: Secret To Secretless

[johnandersen777]

This clears secret usage for take off within centralized and decentralized cases

Luke 8:17

pip install --upgrade pip setuptools wheel \
  && pip install https://github.com/openai/whisper/archive/refs/heads/main.zip \
  && python -uc 'import sys, whisper; print(whisper.load_model("tiny.en").to("cpu").transcribe(sys.argv[-1])["text"])' ADR-bootstrapping-key-signing-ceremony.m4a \
  | tee ADR-bootstrapping-key-signing-ceremony.txt \
  | gh issue comment --body-file - https://github.com/publicdomainrelay/alice/issues/3

[johnandersen777]

Can you please write us a markdown format ADR for the following:

Alright, so this is the ADR for the abstract infrastructure for key signing ceremony. We have at a high level the concept is we need a clear for takeoff for the release of the initial secrets so that we can move from secrets to secret lists. Look 817. Alright, so within the repo we have maintainers slash keys slash keys by user. We're going to use GitHub secrets within the centralized case and within the policy engine case that we've implemented we're going to use Python key ring under a container with debuffs running for the decentralized case. We want to put the root keys within or the active root key within the secrets. You know either the centralized or decentralized secret. And then we put the revocation keys in infrast slash keys slash roots slash core slash revocation and the public key in infrast slash key slash roots slash core slash public. We use a GitHub issue within the centralized case or an activity pub thread within the decentralized case for call to call for core root sign or decrypt operation. We use the root core to decrypt a policy or to to authorize to figure out what maintainers we need for this operation. The policy is declared within infrast slash compute slash c s p slash by provider slash policy or slash operation slash policy.yaml the workflow slash agent workflow. We use the policy to do an alignment check to see if the secret that we're requesting a usage of or decryption of is allowed to do this operation on that CFP. So the format of the call for the key signing up is using a gammel or something. It uses yaml within description of the issue and that yaml needs a nuance within it. So that this key this key operation is unique. So the maintainers respond with the signature over the yaml and we use templates for is you know we use issue templates for different of these operations which have the operation which will be the path you know infrast slash key or that will be infrast slash compute slash c s p slash by provider slash operation slash policy so it's a full path to the policy. And then you know the yaml will also have a space for the non within the template. So the goal here is to unlock a c s p a p i key for which you know to get a valid set of signatures from maintainers over this non's which will then produce a statement which is basically the clear for takeoff for the usage of a specific secret. And the secrets that we want to use you know are also defined within that policy file. So the policy file clairs which maintainers can use which secrets for which operations. And so the operation should also be itself you know the path to the operation should itself be encoded within the policy file. Ideally. Yeah I think maybe eventually we would also include a your end on which would be a statement which has been the registration of that policy file but for now we can use the get repo. So yes the output of this first flow is the attestation that's produced by running the flow. for the soon until as case this is at the station within GitHub's environment which is backed by record I believe and then within the decentralized case this is going to be a you know skit transparent statement. And so we would then post the content address of this statement or yes we post the content address of the receipt and ideally you know the full statement into the thread and then we locked thread. So locking the thread is not necessarily important but you know for the the GitHub cases just make it clear that that's complete. So up until this point let's do a section break up until this point everything has been atomic for the key verify operations to produce this clever take off right so everything can be done atomically you know based on static content that's that's pre known. But now we have to move from an atomic situation to a dynamic situation because we're going to interact with the API using that secret right we're going to release the secret and use it to provision the infrastructure for the bootstrapping process. So let me call this go for alleyoop. So we now have two cases right so so we we have our clear for takeoff for secret usage right and now we need to go for alleyoop we need to do the dynamic part right so we have two cases we have one or n right so one is our centralized environment right so for GHA we can use a GitHub actions concurrency lock here and for the yeah we use a GitHub actions concurrency lock. And that needs to you know we're going to need to tie this to the workload ID right so basically we're going to commit you commit that transparent statement into the repo right and now your workload ID is going to be based off of the content address of the transparent statement right and in the state case you have a nice URL which is the kind of an address of your transparent statement which is you know that you look at skip for the properties of that but it's exactly what we want for that right. So then in the decentralized case we have to have some sort of decentralized locking mechanism and to facilitate that you basically either ID in an ideal case you have carry you know you're using carry watchers here so that you have duplicity detection it's built in there into your instances but either way what you can do is you define trust the trust the DCP layer concept right so you have to trust them to respect the concurrency lock within the decentralized case right so you want to tie the TCP to the policy so that you know that you trust the TCP to respect the concurrency lock for the usage of that clear for takeoff for that policy so the workload ID right is then tied to the TCP and the TCP is tied to the policy right so for so there's we have an open issue their GitHub has an open feature request to do runner pools run it okay don't worry about the GitHub thing so basically within the decentralized case we're going to have infrastash compute slash runners slash keys and so the other one then should be infrastash compute slash yeah I think it's already slash CSP so yes so this one is now infrastash compute slash runner slash keys and you're going to tie the workload ID to the runner pool right and then admission to the runner pool will be tied to the policy right so now you've you've effectively made sure that these runner pools will respect the concurrency lock across them right so you implement locking the runner pool level and out of mission control to the runner pool you're making sure that you know whatever locking mechanisms are in place in a decentralized environment will respect that

[johnandersen777]

ADR: Bootstrapping: Key Signing Ceremony

This ADR takes us from secrets to secretless

Context and Problem Statement

We require a process for a secure and auditable key signing ceremony for releasing initial secrets and transitioning from individual secrets to managed secret lists. This will facilitate both centralized and decentralized workflows while ensuring policy compliance for cryptographic operations.

The atomic workflow for clear for takeoff is implemented, with alley-oop dynamic interactions using workload IDs and decentralized locking mechanisms under development.

This ADR establishes a foundation for secure, transparent, and policy-driven infrastructure management across centralized and decentralized environments.

Status

Accepted

Decision Drivers

• Atomic Execution: Clear separation between atomic and dynamic operations.
• Decentralized Compatibility: Flexibility for centralized (using GitHub Secrets) and decentralized (using Python keyring) cases.
• Policy-Based Control: Centralized location for policies governing key use and signing.
• Transparency and Auditability: Content-addressed transparency for signed statements and receipts.

Considered Options

1. GitHub Actions, GitHub Rekor, and GitHub Secrets for centralized operations.
2. Decentralized environment using SCITT Policy Engine and Python keyring implementation.

Decision Outcome

We will create a two-stage process with distinct clear for takeoff and go for alley-oop (C&C Generals Zero-Hour) phases to ensure atomicity in initial checks and allow dynamic API interaction.

Stage 1: Clear for Takeoff

File Structure

• Keys Directory: maintainers/keys/$USER

  • Stores maintainers' individual keys.

• Secrets Storage:

  • Active root key
  • Centralized Case: GitHub Secrets.
  • Decentralized Case: Python keyring in a container for secure key handling.

• Revocation and Public Keys:

  • Revocation Keys: infra/keys/roots/core/revocation
  • Public Keys: infra/keys/roots/core/public

Operation and Workflow

• Invocation: For centralized operations, a GitHub issue serves as the request; for decentralized, an ActivityPub thread initiates the operation.
• Root Core Decryption: Core root key decrypts the policy to determine the maintainers needed for this action.

• Policy Path: Policies are defined in:

  • infra/compute/csp/$provider/$operation/policy.yml

  These files specify allowed maintainers and secrets for operations and include unique nonce values for operation uniqueness.

Authorization Check

1. Issue Template and YAML Description: Issue templates ensure each operation follows a set path and provides space for nonces.
2. Maintainer Signatures: Maintainers sign the YAML description with nonce to validate operation requests.
3. Output: A signed attestation (clear for takeoff) for the use of specific secrets, meeting policy requirements.

Attestation Posting

• Centralized Case: GitHub environment backed by signed records.
• Decentralized Case: Content-addressed transparency statement posted to the thread.

Stage 2: Go for Alley-oop (Dynamic Execution)

This is our next phase, the usage of the secret by a workload id authenticated subsequent execution (callee potentially for reusable workflows). We want to commit the URN into the workflow to be executed or something to ensure that we can

With the clear for takeoff complete, dynamic secret use begins with an API call for infrastructure provisioning. Here we implement locking mechanisms for concurrency and workload management.

Execution Scenarios

1. Centralized (1):

   • GitHub Actions concurrency lock is tied to a workload ID based on the content address of the transparency statement.
   • Transparent statements provide a stable reference for workload tracking.

2. Decentralized (n):

   • Decentralized locking with ideally KERI based SCITT for duplication detection and TCB trust levels.
   • Workload ID linked to TCP layer policies and policies linked to resource access constraints.

   File Paths:

   • Runners: infra/compute/runner/keys
   • Policy-driven admission controls for runner pools maintain consistency across decentralized instances.

[johnandersen777]

Can this all be done in git with orphan branches?

• semver branching for release