aac-cli 0.2.12__tar.gz → 0.2.13__tar.gz

{aac_cli-0.2.12/aac_cli.egg-info → aac_cli-0.2.13}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aac-cli
-Version: 0.2.12
+Version: 0.2.13
 Summary: The aac platform CLI — headless operator interface to the AAC control plane (tenant registration, chain audit).
 Author: Agent Authority Cloud Project
 License-Expression: Apache-2.0
@@ -184,7 +184,7 @@ never asks you to pick between GitHub and Google again.
   configuration references it by path.
 
 **By default everything `aac init` generates is development material.** The
-development CA lives seven days and the leaf certificates one day. Nothing
+development CA lives 365 days and the leaf certificates 90 days. Nothing
 there qualifies for production, whatever the tenant's domain. If your own
 issuer signs your agent's certificates instead, see "Two ways to get your
 agent's certificates" below; moving to production also means a tenant-admin
@@ -206,7 +206,7 @@ three commands look after it:
 
 ```bash
 aac agent status --agent orders   # what exists, what is due, and the next step
-aac agent renew --agent orders    # replace the short-lived certificates
+aac agent renew --agent orders    # replace the certificates
 aac agent list                     # every agent on this machine
 ```
 
@@ -430,11 +430,11 @@ tell you later and `aac agent renew` behaves accordingly.
 
 The laptop case. The CLI creates a certificate authority on this machine and signs the agent's identity, receipt and HTTPS certificates with it.
 
-**Flags.** No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` and `--ca-cert-file` together; neither one alone.
+**Flags.** No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` and `--ca-cert-file` together; neither one alone. A CA that expires before the certificates it would sign is refused.
 
 **Keys and signatures.** The CA and the two identity keys are Ed25519; the HTTPS key is EC P-256.
 
-**The CLI** creates a 7-day certificate authority and keeps its private key in the agent's keep/ folder; issues the workload, receipt and HTTPS certificates; publishes the CA certificate as a trust anchor named `<agent>-dev-ca`.
+**The CLI** creates a 365-day certificate authority and keeps its private key in the agent's keep/ folder; issues the workload, receipt and HTTPS certificates; publishes the CA certificate as a trust anchor named `<agent>-dev-ca`.
 
 **The CLI does not** ask you for anything from your own certificate authority.
 
@@ -518,10 +518,10 @@ signs instead of this tool — see
 | 2 | tenant_admin_session | `~/.aac/credentials/<tenant-id>.session` | CLI admin calls | hours; `aac sso login` | No. sign in again |
 | 3 | tenant_admin_signing_key | `~/.aac/tenants/<tenant-id>/tenant-admin.pem`, `~/.aac/tenants/<tenant-id>/tenant-admin.pub.pem` | the publisher signs trust-material uploads; the public half is registered with AAC | until rotated; `aac tenant rotate-admin-key` | **Recommended.** recommended for developer tenants (loss needs `aac tenant rotate-admin-key`; a lost public half is derived from the private key); production custody belongs in an HSM/KMS, not a password manager |
 | 4 | root_signing_key | `~/.aac/agents/<agent>/sidecar/root.pem`, `~/.aac/agents/<agent>/sidecar/root.pub.pem`, `~/.aac/tenants/<tenant-id>/root-keys/<agent>-root-v1.pub.pem` | the sidecar mints authority chains; the public half is published under the key id | until you retire its key id (root key ids are fixed per agent name) | No. never restore the private key: a replacement agent gets a new name and therefore a new key id, published alongside the old one until the old one is retired; its public copies are recreated from it |
-| 5 | development_ca | `~/.aac/agents/<agent>/keep/ca.key`, `~/.aac/agents/<agent>/sidecar/ca.crt`, `~/.aac/agents/<agent>/agent/ca.crt`, `~/.aac/tenants/<tenant-id>/spiffe-bundle/<agent>-dev-ca.ca.pem` | signs the workload, terminal and TLS certificates; peers trust it via the published bundle | 7 days; `aac agent renew --ca` | No. development only; reissue; a lost copy of the certificate is copied back from `sidecar/ca.crt` |
-| 6 | workload_svid | `~/.aac/agents/<agent>/sidecar/workload.key`, `~/.aac/agents/<agent>/sidecar/workload.crt` | the sidecar's SPIFFE identity: proves on every live request that this workload holds the key behind its certificate | 1 day; `aac agent renew` | No. reissue |
-| 7 | terminal_attestation | `~/.aac/agents/<agent>/sidecar/terminal.key`, `~/.aac/agents/<agent>/sidecar/terminal.crt` | signs the receipt (terminal attestation) the sidecar issues when this workload completes a delegated request; auditors verify it offline against your published CA; setup gives it its own key so the two signing jobs stay separate, but a receipt is verified against your published CA and the expected agent identity, which the workload certificate also satisfies — treat both keys as one blast radius | 1 day; `aac agent renew` | No. reissue |
-| 8 | https_tls | `~/.aac/agents/<agent>/sidecar/server.key`, `~/.aac/agents/<agent>/sidecar/server.crt` | the sidecar's HTTPS listener | 1 day; `aac agent renew` | No. reissue |
+| 5 | development_ca | `~/.aac/agents/<agent>/keep/ca.key`, `~/.aac/agents/<agent>/sidecar/ca.crt`, `~/.aac/agents/<agent>/agent/ca.crt`, `~/.aac/tenants/<tenant-id>/spiffe-bundle/<agent>-dev-ca.ca.pem` | signs the workload, terminal and TLS certificates; peers trust it via the published bundle | 365 days; `aac agent renew --ca` | No. development only; reissue; a lost copy of the certificate is copied back from `sidecar/ca.crt` |
+| 6 | workload_svid | `~/.aac/agents/<agent>/sidecar/workload.key`, `~/.aac/agents/<agent>/sidecar/workload.crt` | the sidecar's SPIFFE identity: proves on every live request that this workload holds the key behind its certificate | 90 days; `aac agent renew` | No. reissue |
+| 7 | terminal_attestation | `~/.aac/agents/<agent>/sidecar/terminal.key`, `~/.aac/agents/<agent>/sidecar/terminal.crt` | signs the receipt (terminal attestation) the sidecar issues when this workload completes a delegated request; auditors verify it offline against your published CA; setup gives it its own key so the two signing jobs stay separate, but a receipt is verified against your published CA and the expected agent identity, which the workload certificate also satisfies — treat both keys as one blast radius | 90 days; `aac agent renew` | No. reissue |
+| 8 | https_tls | `~/.aac/agents/<agent>/sidecar/server.key`, `~/.aac/agents/<agent>/sidecar/server.crt` | the sidecar's HTTPS listener | 90 days; `aac agent renew` | No. reissue |
 | 9 | outbound_ca_bundle | `~/.aac/agents/<agent>/sidecar/outbound-ca.pem` | the sidecar verifies TLS to AAC and configured peers | rebuilt by renew; `aac agent renew` | No. derived |
 | 10 | pairing_secret | `~/.aac/agents/<agent>/agent/pairing.secret` | the sidecar and its agent authenticate each other (same bytes in both) | until regenerated | No. regenerable; both processes must read the same file |
 | 11 | agent_record | `~/.aac/agents/<agent>/record.json` | the agent's identities and progress; every `aac agent` verb reads it first | for the life of the agent | **Recommended.** cannot be recreated by any command; without it start a new agent under a new name (see the new-computer setup procedure) |
@@ -537,15 +537,15 @@ the machine is healthy. Everything else is regenerated.
 ```bash
 aac agent status --agent orders --output table   # what exists, expiry, permissions, next command
 aac agent status --agent orders --remote         # also: is the public trust material visible?
-aac agent renew --agent orders                   # replace the short-lived certificates; old ones archived
+aac agent renew --agent orders                   # replace the certificates; old ones archived
 aac agent list                                    # every agent on this machine, with its case
 aac init --profile stage --agent orders --layout container   # write the settings again, container paths
 ```
 
 `status` works offline by default and exits with code 3 when material is
-missing, expired or unsafely permissioned. `renew` reissues the one-day
+missing, expired or unsafely permissioned. `renew` reissues the 90-day
 certificates with fresh keys, and reissues the development CA only when it
-is expired or within a day of expiry (or when `--ca` is given); a new CA is
+is expired or within 90 days of expiry (or when `--ca` is given); a new CA is
 published under the next anchor id and needs the publisher restarted. For an
 agent whose own issuer signed its certificates, `renew` cannot reissue
 anything: it takes the replacements your issuer produced, through the same
@@ -578,20 +578,23 @@ id.
 
 It is the certificates that expire, and renewing replaces their keys with
 them. `aac agent status` shows when each certificate runs out and flags
-it before it does: six hours ahead for the one-day certificates, a day
-ahead for the development CA.
+it before it does: seven days ahead for the 90-day certificates, 90 days
+ahead for the development CA. That CA window covers a whole leaf lifetime, so
+a renewal never issues a certificate that would outlive its CA. Certificates
+your own issuer signed get the seven-day heads-up for the CA as well.
 
 | Material | Lasts | When it runs out | What to do |
 |---|---|---|---|
-| Workload, terminal-attestation and HTTPS certificates | 1 day | the sidecar can no longer prove its identity, sign receipts or serve HTTPS | `aac agent renew --agent <name>`, then restart the sidecar so it loads them |
-| Development CA | 7 days | certificates it signed stop being trusted, and no new ones can be issued | `renew` also replaces the CA when it is expired or within a day of expiry, or when `--ca` is given, and then reissues every certificate under it: restart the publisher so the new CA is published, restart the sidecar and anything else that trusted the old CA, and confirm with `aac agent status --agent <name> --remote` |
+| Workload, terminal-attestation and HTTPS certificates | 90 days | the sidecar can no longer prove its identity, sign receipts or serve HTTPS | `aac agent renew --agent <name>`, then restart the sidecar so it loads them |
+| Development CA | 365 days | certificates it signed stop being trusted, and no new ones can be issued | `renew` also replaces the CA when it is expired or within 90 days of expiry, or when `--ca` is given, and then reissues every certificate under it: restart the publisher so the new CA is published, restart the sidecar and anything else that trusted the old CA, and confirm with `aac agent status --agent <name> --remote` |
 | Tenant-admin session | hours | administration commands ask you to sign in again | `aac sso login` |
 | Tenant API key, tenant-admin signing key, root signing key | do not expire | — | replaced only on purpose: see "Keys" and "Setting up aac-cli on a new computer" |
 
 A simple routine: when you start work, run
 `aac agent status --agent <name>`, and when it names renewal, run
-`aac agent renew --agent <name>` and restart the sidecar. About once
-a week that renewal also replaces the development CA (`renew` then reports
+`aac agent renew --agent <name>` and restart the sidecar. About every nine
+months, once the CA is within 90 days of expiry, that renewal also replaces
+the development CA (`renew` then reports
 `republication_required: true`): restart the publisher, the sidecar and the
 agent, and anything else that trusted the old CA. Renewing is safe to
 repeat, but it is not a no-op: every run issues fresh keys and moves the old

{aac_cli-0.2.12 → aac_cli-0.2.13}/README.md

@@ -157,7 +157,7 @@ never asks you to pick between GitHub and Google again.
   configuration references it by path.
 
 **By default everything `aac init` generates is development material.** The
-development CA lives seven days and the leaf certificates one day. Nothing
+development CA lives 365 days and the leaf certificates 90 days. Nothing
 there qualifies for production, whatever the tenant's domain. If your own
 issuer signs your agent's certificates instead, see "Two ways to get your
 agent's certificates" below; moving to production also means a tenant-admin
@@ -179,7 +179,7 @@ three commands look after it:
 
 ```bash
 aac agent status --agent orders   # what exists, what is due, and the next step
-aac agent renew --agent orders    # replace the short-lived certificates
+aac agent renew --agent orders    # replace the certificates
 aac agent list                     # every agent on this machine
 ```
 
@@ -403,11 +403,11 @@ tell you later and `aac agent renew` behaves accordingly.
 
 The laptop case. The CLI creates a certificate authority on this machine and signs the agent's identity, receipt and HTTPS certificates with it.
 
-**Flags.** No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` and `--ca-cert-file` together; neither one alone.
+**Flags.** No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` and `--ca-cert-file` together; neither one alone. A CA that expires before the certificates it would sign is refused.
 
 **Keys and signatures.** The CA and the two identity keys are Ed25519; the HTTPS key is EC P-256.
 
-**The CLI** creates a 7-day certificate authority and keeps its private key in the agent's keep/ folder; issues the workload, receipt and HTTPS certificates; publishes the CA certificate as a trust anchor named `<agent>-dev-ca`.
+**The CLI** creates a 365-day certificate authority and keeps its private key in the agent's keep/ folder; issues the workload, receipt and HTTPS certificates; publishes the CA certificate as a trust anchor named `<agent>-dev-ca`.
 
 **The CLI does not** ask you for anything from your own certificate authority.
 
@@ -491,10 +491,10 @@ signs instead of this tool — see
 | 2 | tenant_admin_session | `~/.aac/credentials/<tenant-id>.session` | CLI admin calls | hours; `aac sso login` | No. sign in again |
 | 3 | tenant_admin_signing_key | `~/.aac/tenants/<tenant-id>/tenant-admin.pem`, `~/.aac/tenants/<tenant-id>/tenant-admin.pub.pem` | the publisher signs trust-material uploads; the public half is registered with AAC | until rotated; `aac tenant rotate-admin-key` | **Recommended.** recommended for developer tenants (loss needs `aac tenant rotate-admin-key`; a lost public half is derived from the private key); production custody belongs in an HSM/KMS, not a password manager |
 | 4 | root_signing_key | `~/.aac/agents/<agent>/sidecar/root.pem`, `~/.aac/agents/<agent>/sidecar/root.pub.pem`, `~/.aac/tenants/<tenant-id>/root-keys/<agent>-root-v1.pub.pem` | the sidecar mints authority chains; the public half is published under the key id | until you retire its key id (root key ids are fixed per agent name) | No. never restore the private key: a replacement agent gets a new name and therefore a new key id, published alongside the old one until the old one is retired; its public copies are recreated from it |
-| 5 | development_ca | `~/.aac/agents/<agent>/keep/ca.key`, `~/.aac/agents/<agent>/sidecar/ca.crt`, `~/.aac/agents/<agent>/agent/ca.crt`, `~/.aac/tenants/<tenant-id>/spiffe-bundle/<agent>-dev-ca.ca.pem` | signs the workload, terminal and TLS certificates; peers trust it via the published bundle | 7 days; `aac agent renew --ca` | No. development only; reissue; a lost copy of the certificate is copied back from `sidecar/ca.crt` |
-| 6 | workload_svid | `~/.aac/agents/<agent>/sidecar/workload.key`, `~/.aac/agents/<agent>/sidecar/workload.crt` | the sidecar's SPIFFE identity: proves on every live request that this workload holds the key behind its certificate | 1 day; `aac agent renew` | No. reissue |
-| 7 | terminal_attestation | `~/.aac/agents/<agent>/sidecar/terminal.key`, `~/.aac/agents/<agent>/sidecar/terminal.crt` | signs the receipt (terminal attestation) the sidecar issues when this workload completes a delegated request; auditors verify it offline against your published CA; setup gives it its own key so the two signing jobs stay separate, but a receipt is verified against your published CA and the expected agent identity, which the workload certificate also satisfies — treat both keys as one blast radius | 1 day; `aac agent renew` | No. reissue |
-| 8 | https_tls | `~/.aac/agents/<agent>/sidecar/server.key`, `~/.aac/agents/<agent>/sidecar/server.crt` | the sidecar's HTTPS listener | 1 day; `aac agent renew` | No. reissue |
+| 5 | development_ca | `~/.aac/agents/<agent>/keep/ca.key`, `~/.aac/agents/<agent>/sidecar/ca.crt`, `~/.aac/agents/<agent>/agent/ca.crt`, `~/.aac/tenants/<tenant-id>/spiffe-bundle/<agent>-dev-ca.ca.pem` | signs the workload, terminal and TLS certificates; peers trust it via the published bundle | 365 days; `aac agent renew --ca` | No. development only; reissue; a lost copy of the certificate is copied back from `sidecar/ca.crt` |
+| 6 | workload_svid | `~/.aac/agents/<agent>/sidecar/workload.key`, `~/.aac/agents/<agent>/sidecar/workload.crt` | the sidecar's SPIFFE identity: proves on every live request that this workload holds the key behind its certificate | 90 days; `aac agent renew` | No. reissue |
+| 7 | terminal_attestation | `~/.aac/agents/<agent>/sidecar/terminal.key`, `~/.aac/agents/<agent>/sidecar/terminal.crt` | signs the receipt (terminal attestation) the sidecar issues when this workload completes a delegated request; auditors verify it offline against your published CA; setup gives it its own key so the two signing jobs stay separate, but a receipt is verified against your published CA and the expected agent identity, which the workload certificate also satisfies — treat both keys as one blast radius | 90 days; `aac agent renew` | No. reissue |
+| 8 | https_tls | `~/.aac/agents/<agent>/sidecar/server.key`, `~/.aac/agents/<agent>/sidecar/server.crt` | the sidecar's HTTPS listener | 90 days; `aac agent renew` | No. reissue |
 | 9 | outbound_ca_bundle | `~/.aac/agents/<agent>/sidecar/outbound-ca.pem` | the sidecar verifies TLS to AAC and configured peers | rebuilt by renew; `aac agent renew` | No. derived |
 | 10 | pairing_secret | `~/.aac/agents/<agent>/agent/pairing.secret` | the sidecar and its agent authenticate each other (same bytes in both) | until regenerated | No. regenerable; both processes must read the same file |
 | 11 | agent_record | `~/.aac/agents/<agent>/record.json` | the agent's identities and progress; every `aac agent` verb reads it first | for the life of the agent | **Recommended.** cannot be recreated by any command; without it start a new agent under a new name (see the new-computer setup procedure) |
@@ -510,15 +510,15 @@ the machine is healthy. Everything else is regenerated.
 ```bash
 aac agent status --agent orders --output table   # what exists, expiry, permissions, next command
 aac agent status --agent orders --remote         # also: is the public trust material visible?
-aac agent renew --agent orders                   # replace the short-lived certificates; old ones archived
+aac agent renew --agent orders                   # replace the certificates; old ones archived
 aac agent list                                    # every agent on this machine, with its case
 aac init --profile stage --agent orders --layout container   # write the settings again, container paths
 ```
 
 `status` works offline by default and exits with code 3 when material is
-missing, expired or unsafely permissioned. `renew` reissues the one-day
+missing, expired or unsafely permissioned. `renew` reissues the 90-day
 certificates with fresh keys, and reissues the development CA only when it
-is expired or within a day of expiry (or when `--ca` is given); a new CA is
+is expired or within 90 days of expiry (or when `--ca` is given); a new CA is
 published under the next anchor id and needs the publisher restarted. For an
 agent whose own issuer signed its certificates, `renew` cannot reissue
 anything: it takes the replacements your issuer produced, through the same
@@ -551,20 +551,23 @@ id.
 
 It is the certificates that expire, and renewing replaces their keys with
 them. `aac agent status` shows when each certificate runs out and flags
-it before it does: six hours ahead for the one-day certificates, a day
-ahead for the development CA.
+it before it does: seven days ahead for the 90-day certificates, 90 days
+ahead for the development CA. That CA window covers a whole leaf lifetime, so
+a renewal never issues a certificate that would outlive its CA. Certificates
+your own issuer signed get the seven-day heads-up for the CA as well.
 
 | Material | Lasts | When it runs out | What to do |
 |---|---|---|---|
-| Workload, terminal-attestation and HTTPS certificates | 1 day | the sidecar can no longer prove its identity, sign receipts or serve HTTPS | `aac agent renew --agent <name>`, then restart the sidecar so it loads them |
-| Development CA | 7 days | certificates it signed stop being trusted, and no new ones can be issued | `renew` also replaces the CA when it is expired or within a day of expiry, or when `--ca` is given, and then reissues every certificate under it: restart the publisher so the new CA is published, restart the sidecar and anything else that trusted the old CA, and confirm with `aac agent status --agent <name> --remote` |
+| Workload, terminal-attestation and HTTPS certificates | 90 days | the sidecar can no longer prove its identity, sign receipts or serve HTTPS | `aac agent renew --agent <name>`, then restart the sidecar so it loads them |
+| Development CA | 365 days | certificates it signed stop being trusted, and no new ones can be issued | `renew` also replaces the CA when it is expired or within 90 days of expiry, or when `--ca` is given, and then reissues every certificate under it: restart the publisher so the new CA is published, restart the sidecar and anything else that trusted the old CA, and confirm with `aac agent status --agent <name> --remote` |
 | Tenant-admin session | hours | administration commands ask you to sign in again | `aac sso login` |
 | Tenant API key, tenant-admin signing key, root signing key | do not expire | — | replaced only on purpose: see "Keys" and "Setting up aac-cli on a new computer" |
 
 A simple routine: when you start work, run
 `aac agent status --agent <name>`, and when it names renewal, run
-`aac agent renew --agent <name>` and restart the sidecar. About once
-a week that renewal also replaces the development CA (`renew` then reports
+`aac agent renew --agent <name>` and restart the sidecar. About every nine
+months, once the CA is within 90 days of expiry, that renewal also replaces
+the development CA (`renew` then reports
 `republication_required: true`): restart the publisher, the sidecar and the
 agent, and anything else that trusted the old CA. Renewing is safe to
 repeat, but it is not a no-op: every run issues fresh keys and moves the old

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/__init__.py

@@ -10,4 +10,4 @@ entrypoint (`aac_cli.cli:entrypoint`).
 # test in bin/tests/test_cli_version_parity.py. A literal keeps the
 # shipped code free of import-time metadata lookups (and their
 # not-installed failure mode).
-__version__ = "0.2.12"
+__version__ = "0.2.13"

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/agent_cli.py

@@ -8,7 +8,7 @@ tenants:
   domain, which of the two certificate cases the agent uses, and the single
   next command. ``--remote`` adds trust-publication visibility through the
   public trust endpoints.
-* ``renew`` — in "The CLI creates a development CA" mode, reissues the one-day
+* ``renew`` — in "The CLI creates a development CA" mode, reissues the
   workload, receipt and HTTPS certificates with fresh keys, and the CA only
   when it is expired or inside its renewal window. With supplied certificates
   it cannot reissue what it did not sign: it takes replacements from your
@@ -698,11 +698,12 @@ def add_agent_parser(nouns: argparse._SubParsersAction) -> None:
 
     renew = verbs.add_parser(
         "renew",
-        help="Replace the short-lived certificates; archive the old material.",
+        help="Replace the agent's certificates; archive the old material.",
         description=(
             f'In "{case_for(MATERIAL_ISSUED_HERE).name}" mode, reissues the workload, receipt and '
             "HTTPS certificates with new keys; the development CA is reissued only when "
-            "expired or within one day of expiry, or with --ca, and a new CA needs the "
+            f"expired or within {dev_material.describe_lifetime(dev_material.CA_RENEWAL_WINDOW)} "
+            "of expiry, or with --ca, and a new CA needs the "
             f'publisher to publish the new anchor. In "{case_for(MATERIAL_SUPPLIED).name}" mode nothing is '
             "reissued: pass the replacement certificates your issuer produced, each with its "
             "key file, and --ca-cert-file if your CA certificate changed too."

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/agent_health.py

@@ -100,7 +100,11 @@ def _certificate_reports(
 ) -> dict[str, CertificateReport]:
     reports: dict[str, CertificateReport] = {}
     for label, path, window in (
-        (ca_report_label(material_source), agent.ca_certificate, dev_material.CA_RENEWAL_WINDOW),
+        (
+            ca_report_label(material_source),
+            agent.ca_certificate,
+            dev_material.ca_renewal_window(material_source),
+        ),
         ("workload", agent.workload_certificate, dev_material.LEAF_RENEWAL_WINDOW),
         ("terminal", agent.terminal_certificate, dev_material.LEAF_RENEWAL_WINDOW),
         ("tls_server", agent.server_certificate, dev_material.LEAF_RENEWAL_WINDOW),

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/agent_layout.py

@@ -25,6 +25,7 @@ from aac_cli.config import (
     CliUsageError,
     cli_home,
 )
+from aac_cli.dev_material import DEV_CA_VALIDITY, LEAF_VALIDITY, describe_lifetime
 from aac_cli.material_cases import MATERIAL_ISSUED_HERE, MATERIAL_SUPPLIED
 
 TENANTS_DIRECTORY = "tenants"
@@ -303,6 +304,7 @@ def material_inventory(
         if supplied
         else "aac agent renew"
     )
+    leaf_lifetime = describe_lifetime(LEAF_VALIDITY)
     return (
         InventoryItem(
             role="tenant_api_key",
@@ -364,7 +366,7 @@ def material_inventory(
                 "the sidecar's SPIFFE identity: proves on every live request that this workload "
                 "holds the key behind its certificate"
             ),
-            lifetime="1 day" if not supplied else "your issuer decides",
+            lifetime=leaf_lifetime if not supplied else "your issuer decides",
             backup=BACKUP_NO,
             backup_note="reissue" if not supplied else "your issuer holds the original",
             renew_with=leaf_renewal,
@@ -382,7 +384,7 @@ def material_inventory(
                 "which the workload certificate also satisfies — treat both keys as one blast "
                 "radius"
             ),
-            lifetime="1 day" if not supplied else "your issuer decides",
+            lifetime=leaf_lifetime if not supplied else "your issuer decides",
             backup=BACKUP_NO,
             backup_note="reissue" if not supplied else "your issuer holds the original",
             renew_with=leaf_renewal,
@@ -393,7 +395,7 @@ def material_inventory(
             kind="certificate",
             paths=(agent.server_key, agent.server_certificate),
             used_for="the sidecar's HTTPS listener",
-            lifetime="1 day" if not supplied else "your issuer decides",
+            lifetime=leaf_lifetime if not supplied else "your issuer decides",
             backup=BACKUP_NO,
             backup_note="reissue" if not supplied else "your issuer holds the original",
             renew_with=leaf_renewal,
@@ -496,7 +498,7 @@ def _ca_inventory_item(
             tenant.published_ca_certificate(anchor_id),
         ),
         used_for="signs the workload, terminal and TLS certificates; peers trust it via the published bundle",
-        lifetime="7 days",
+        lifetime=describe_lifetime(DEV_CA_VALIDITY),
         backup=BACKUP_NO,
         backup_note=(
             "development only; reissue; a lost copy of the certificate is copied back "

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/dev_material.py

@@ -3,13 +3,15 @@
 Everything here is DEVELOPMENT material for a local workload whose sidecar,
 publisher and CLI run on one machine. It is generated in-process with the
 `cryptography` dependency the CLI already carries, with the same algorithms
-and lifetimes as the public starter guide's OpenSSL recipe:
+as the public starter guide's OpenSSL recipe:
 
 * Ed25519 for the development CA, the workload SVID key, the terminal
   attestation key, the root-signing key and the tenant-admin key;
 * P-256 for the configured HTTPS server key (browsers and Go's TLS stack both
   accept it without configuration);
-* a seven-day CA and one-day leaf certificates.
+* a 365-day CA and 90-day leaf certificates (B337), long enough that an
+  evaluator who comes back weeks later finds the agent still usable; the
+  guide's hand-built OpenSSL recipe keeps its own shorter figures.
 
 None of this qualifies for production regardless of the tenant's hosted
 domain (CLI Config+Profile Spec, B241 amendment §B). Production promotion is
@@ -32,14 +34,17 @@ from cryptography.hazmat.primitives.asymmetric import ec, ed25519
 from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID
 
 from aac_cli.config import CliConfigError
+from aac_cli.material_cases import MATERIAL_ISSUED_HERE
 from aac_cli.secure_files import read_private_file, write_private_file
 
-DEV_CA_VALIDITY = timedelta(days=7)
-LEAF_VALIDITY = timedelta(days=1)
+DEV_CA_VALIDITY = timedelta(days=365)
+LEAF_VALIDITY = timedelta(days=90)
 # Renewal windows: `agent renew` reissues material that is expired or
 # expires within these windows; `agent status` warns at the same point.
-LEAF_RENEWAL_WINDOW = timedelta(hours=6)
-CA_RENEWAL_WINDOW = timedelta(days=1)
+# The CA window is at least the leaf lifetime (test_readme_facts asserts it),
+# so a renewal that is about to issue leaves replaces a CA they would outlive.
+LEAF_RENEWAL_WINDOW = timedelta(days=7)
+CA_RENEWAL_WINDOW = timedelta(days=90)
 # Certificates are backdated slightly so a sidecar whose clock trails the
 # workstation by a few seconds does not reject a just-issued certificate.
 CLOCK_SKEW_ALLOWANCE = timedelta(minutes=5)
@@ -54,6 +59,25 @@ def now_utc() -> datetime:
     return datetime.now(timezone.utc)
 
 
+def describe_lifetime(duration: timedelta) -> str:
+    """A whole-day lifetime as the README and the inventory state it: '1 day', '90 days'."""
+    assert duration % timedelta(days=1) == timedelta(0), duration
+    return "1 day" if duration.days == 1 else f"{duration.days} days"
+
+
+def ca_renewal_window(material_source: str) -> timedelta:
+    """How far ahead of expiry a CA counts as due.
+
+    The CLI's own development CA is replaced a whole leaf lifetime ahead, so the
+    leaves `renew` is about to issue never outlive it. A supplied CA signs leaves
+    whose lifetime the CLI does not know and cannot reissue; it gets the same
+    heads-up as the leaves themselves.
+    """
+    if material_source == MATERIAL_ISSUED_HERE:
+        return CA_RENEWAL_WINDOW
+    return LEAF_RENEWAL_WINDOW
+
+
 # --- keys -----------------------------------------------------------------
 
 
@@ -184,6 +208,9 @@ def _leaf_builder(
     ca_certificate: x509.Certificate, subject_key: PrivateKey, subject: x509.Name
 ) -> x509.CertificateBuilder:
     not_before, not_after = _validity(LEAF_VALIDITY)
+    # A leaf never outlives its CA, whatever the clock did between the CA check and
+    # this issuance (external review S1): the encoded expiry is bounded by the CA's.
+    not_after = min(not_after, ca_certificate.not_valid_after_utc)
     return (
         x509.CertificateBuilder()
         .subject_name(subject)
@@ -228,7 +255,7 @@ def issue_identity_certificate(
     subject_key: IdentityKey,
     spiffe_id: str,
 ) -> x509.Certificate:
-    """A one-day SVID-style certificate: empty subject, critical SPIFFE URI SAN.
+    """A `LEAF_VALIDITY` SVID-style certificate: empty subject, critical SPIFFE URI SAN.
 
     Only the CA key has to be Ed25519 (the development CA signs with it); the
     subject key may be either type the sidecar accepts.
@@ -255,7 +282,7 @@ def issue_server_certificate(
     server_key: ec.EllipticCurvePrivateKey,
     names: list[str],
 ) -> x509.Certificate:
-    """A one-day TLS server certificate for the configured connection names."""
+    """A `LEAF_VALIDITY` TLS server certificate for the configured connection names."""
     subject = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "AAC HTTPS listener")])
     sans: list[x509.GeneralName] = []
     for name in names:
@@ -435,6 +462,10 @@ def issuer_unfitness_reasons(
 
 
 def validate_supplied_ca(key: ed25519.Ed25519PrivateKey, certificate: x509.Certificate) -> None:
+    """A reused development CA (`aac init --ca-key-file --ca-cert-file`) must be able to
+    sign now AND outlast the leaves `init` is about to issue under it; a leaf that
+    outlives its CA loses its chain long before its own expiry (external review M1).
+    """
     if certificate.public_key() != key.public_key():
         raise CliConfigError("--ca-cert-file does not match the key in --ca-key-file")
     reasons = ca_unfitness_reasons(certificate)
@@ -443,6 +474,14 @@ def validate_supplied_ca(key: ed25519.Ed25519PrivateKey, certificate: x509.Certi
             "--ca-cert-file cannot issue development certificates: "
             + "; ".join(reason.text for reason in reasons)
         )
+    _, leaf_not_after = _validity(LEAF_VALIDITY)
+    if certificate.not_valid_after_utc < leaf_not_after:
+        raise CliConfigError(
+            f"--ca-cert-file expires at {certificate.not_valid_after_utc.isoformat()}, before "
+            f"the {describe_lifetime(LEAF_VALIDITY)} the certificates it would sign now last "
+            f"(until {leaf_not_after.isoformat()}); pass a CA that lasts at least that long, "
+            "or leave both CA flags off and let aac init create one"
+        )
 
 
 def validate_pairing_secret(secret: bytes, *, source: str) -> bytes:

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/init_cli.py

@@ -1391,7 +1391,11 @@ def certificate_expiries(
 ) -> dict[str, str]:
     expiries = {}
     for label, path, window in (
-        (ca_report_label(material_source), agent.ca_certificate, dev_material.CA_RENEWAL_WINDOW),
+        (
+            ca_report_label(material_source),
+            agent.ca_certificate,
+            dev_material.ca_renewal_window(material_source),
+        ),
         ("workload", agent.workload_certificate, dev_material.LEAF_RENEWAL_WINDOW),
         ("terminal", agent.terminal_certificate, dev_material.LEAF_RENEWAL_WINDOW),
         ("tls_server", agent.server_certificate, dev_material.LEAF_RENEWAL_WINDOW),

{aac_cli-0.2.12 → aac_cli-0.2.13}/aac_cli/material_cases.py

@@ -52,11 +52,12 @@ ISSUED_HERE = MaterialCase(
     flags=("--ca-key-file", "--ca-cert-file"),
     flags_note=(
         "No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` "
-        "and `--ca-cert-file` together; neither one alone."
+        "and `--ca-cert-file` together; neither one alone. A CA that expires before the "
+        "certificates it would sign is refused."
     ),
     key_profile="The CA and the two identity keys are Ed25519; the HTTPS key is EC P-256.",
     cli_does=(
-        "creates a 7-day certificate authority and keeps its private key in the agent's keep/ folder",
+        "creates a 365-day certificate authority and keeps its private key in the agent's keep/ folder",
         "issues the workload, receipt and HTTPS certificates",
         "publishes the CA certificate as a trust anchor named `<agent>-dev-ca`",
     ),

{aac_cli-0.2.12 → aac_cli-0.2.13/aac_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aac-cli
-Version: 0.2.12
+Version: 0.2.13
 Summary: The aac platform CLI — headless operator interface to the AAC control plane (tenant registration, chain audit).
 Author: Agent Authority Cloud Project
 License-Expression: Apache-2.0
@@ -184,7 +184,7 @@ never asks you to pick between GitHub and Google again.
   configuration references it by path.
 
 **By default everything `aac init` generates is development material.** The
-development CA lives seven days and the leaf certificates one day. Nothing
+development CA lives 365 days and the leaf certificates 90 days. Nothing
 there qualifies for production, whatever the tenant's domain. If your own
 issuer signs your agent's certificates instead, see "Two ways to get your
 agent's certificates" below; moving to production also means a tenant-admin
@@ -206,7 +206,7 @@ three commands look after it:
 
 ```bash
 aac agent status --agent orders   # what exists, what is due, and the next step
-aac agent renew --agent orders    # replace the short-lived certificates
+aac agent renew --agent orders    # replace the certificates
 aac agent list                     # every agent on this machine
 ```
 
@@ -430,11 +430,11 @@ tell you later and `aac agent renew` behaves accordingly.
 
 The laptop case. The CLI creates a certificate authority on this machine and signs the agent's identity, receipt and HTTPS certificates with it.
 
-**Flags.** No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` and `--ca-cert-file` together; neither one alone.
+**Flags.** No flags are needed. To reuse a development CA across agents, pass `--ca-key-file` and `--ca-cert-file` together; neither one alone. A CA that expires before the certificates it would sign is refused.
 
 **Keys and signatures.** The CA and the two identity keys are Ed25519; the HTTPS key is EC P-256.
 
-**The CLI** creates a 7-day certificate authority and keeps its private key in the agent's keep/ folder; issues the workload, receipt and HTTPS certificates; publishes the CA certificate as a trust anchor named `<agent>-dev-ca`.
+**The CLI** creates a 365-day certificate authority and keeps its private key in the agent's keep/ folder; issues the workload, receipt and HTTPS certificates; publishes the CA certificate as a trust anchor named `<agent>-dev-ca`.
 
 **The CLI does not** ask you for anything from your own certificate authority.
 
@@ -518,10 +518,10 @@ signs instead of this tool — see
 | 2 | tenant_admin_session | `~/.aac/credentials/<tenant-id>.session` | CLI admin calls | hours; `aac sso login` | No. sign in again |
 | 3 | tenant_admin_signing_key | `~/.aac/tenants/<tenant-id>/tenant-admin.pem`, `~/.aac/tenants/<tenant-id>/tenant-admin.pub.pem` | the publisher signs trust-material uploads; the public half is registered with AAC | until rotated; `aac tenant rotate-admin-key` | **Recommended.** recommended for developer tenants (loss needs `aac tenant rotate-admin-key`; a lost public half is derived from the private key); production custody belongs in an HSM/KMS, not a password manager |
 | 4 | root_signing_key | `~/.aac/agents/<agent>/sidecar/root.pem`, `~/.aac/agents/<agent>/sidecar/root.pub.pem`, `~/.aac/tenants/<tenant-id>/root-keys/<agent>-root-v1.pub.pem` | the sidecar mints authority chains; the public half is published under the key id | until you retire its key id (root key ids are fixed per agent name) | No. never restore the private key: a replacement agent gets a new name and therefore a new key id, published alongside the old one until the old one is retired; its public copies are recreated from it |
-| 5 | development_ca | `~/.aac/agents/<agent>/keep/ca.key`, `~/.aac/agents/<agent>/sidecar/ca.crt`, `~/.aac/agents/<agent>/agent/ca.crt`, `~/.aac/tenants/<tenant-id>/spiffe-bundle/<agent>-dev-ca.ca.pem` | signs the workload, terminal and TLS certificates; peers trust it via the published bundle | 7 days; `aac agent renew --ca` | No. development only; reissue; a lost copy of the certificate is copied back from `sidecar/ca.crt` |
-| 6 | workload_svid | `~/.aac/agents/<agent>/sidecar/workload.key`, `~/.aac/agents/<agent>/sidecar/workload.crt` | the sidecar's SPIFFE identity: proves on every live request that this workload holds the key behind its certificate | 1 day; `aac agent renew` | No. reissue |
-| 7 | terminal_attestation | `~/.aac/agents/<agent>/sidecar/terminal.key`, `~/.aac/agents/<agent>/sidecar/terminal.crt` | signs the receipt (terminal attestation) the sidecar issues when this workload completes a delegated request; auditors verify it offline against your published CA; setup gives it its own key so the two signing jobs stay separate, but a receipt is verified against your published CA and the expected agent identity, which the workload certificate also satisfies — treat both keys as one blast radius | 1 day; `aac agent renew` | No. reissue |
-| 8 | https_tls | `~/.aac/agents/<agent>/sidecar/server.key`, `~/.aac/agents/<agent>/sidecar/server.crt` | the sidecar's HTTPS listener | 1 day; `aac agent renew` | No. reissue |
+| 5 | development_ca | `~/.aac/agents/<agent>/keep/ca.key`, `~/.aac/agents/<agent>/sidecar/ca.crt`, `~/.aac/agents/<agent>/agent/ca.crt`, `~/.aac/tenants/<tenant-id>/spiffe-bundle/<agent>-dev-ca.ca.pem` | signs the workload, terminal and TLS certificates; peers trust it via the published bundle | 365 days; `aac agent renew --ca` | No. development only; reissue; a lost copy of the certificate is copied back from `sidecar/ca.crt` |
+| 6 | workload_svid | `~/.aac/agents/<agent>/sidecar/workload.key`, `~/.aac/agents/<agent>/sidecar/workload.crt` | the sidecar's SPIFFE identity: proves on every live request that this workload holds the key behind its certificate | 90 days; `aac agent renew` | No. reissue |
+| 7 | terminal_attestation | `~/.aac/agents/<agent>/sidecar/terminal.key`, `~/.aac/agents/<agent>/sidecar/terminal.crt` | signs the receipt (terminal attestation) the sidecar issues when this workload completes a delegated request; auditors verify it offline against your published CA; setup gives it its own key so the two signing jobs stay separate, but a receipt is verified against your published CA and the expected agent identity, which the workload certificate also satisfies — treat both keys as one blast radius | 90 days; `aac agent renew` | No. reissue |
+| 8 | https_tls | `~/.aac/agents/<agent>/sidecar/server.key`, `~/.aac/agents/<agent>/sidecar/server.crt` | the sidecar's HTTPS listener | 90 days; `aac agent renew` | No. reissue |
 | 9 | outbound_ca_bundle | `~/.aac/agents/<agent>/sidecar/outbound-ca.pem` | the sidecar verifies TLS to AAC and configured peers | rebuilt by renew; `aac agent renew` | No. derived |
 | 10 | pairing_secret | `~/.aac/agents/<agent>/agent/pairing.secret` | the sidecar and its agent authenticate each other (same bytes in both) | until regenerated | No. regenerable; both processes must read the same file |
 | 11 | agent_record | `~/.aac/agents/<agent>/record.json` | the agent's identities and progress; every `aac agent` verb reads it first | for the life of the agent | **Recommended.** cannot be recreated by any command; without it start a new agent under a new name (see the new-computer setup procedure) |
@@ -537,15 +537,15 @@ the machine is healthy. Everything else is regenerated.
 ```bash
 aac agent status --agent orders --output table   # what exists, expiry, permissions, next command
 aac agent status --agent orders --remote         # also: is the public trust material visible?
-aac agent renew --agent orders                   # replace the short-lived certificates; old ones archived
+aac agent renew --agent orders                   # replace the certificates; old ones archived
 aac agent list                                    # every agent on this machine, with its case
 aac init --profile stage --agent orders --layout container   # write the settings again, container paths
 ```
 
 `status` works offline by default and exits with code 3 when material is
-missing, expired or unsafely permissioned. `renew` reissues the one-day
+missing, expired or unsafely permissioned. `renew` reissues the 90-day
 certificates with fresh keys, and reissues the development CA only when it
-is expired or within a day of expiry (or when `--ca` is given); a new CA is
+is expired or within 90 days of expiry (or when `--ca` is given); a new CA is
 published under the next anchor id and needs the publisher restarted. For an
 agent whose own issuer signed its certificates, `renew` cannot reissue
 anything: it takes the replacements your issuer produced, through the same
@@ -578,20 +578,23 @@ id.
 
 It is the certificates that expire, and renewing replaces their keys with
 them. `aac agent status` shows when each certificate runs out and flags
-it before it does: six hours ahead for the one-day certificates, a day
-ahead for the development CA.
+it before it does: seven days ahead for the 90-day certificates, 90 days
+ahead for the development CA. That CA window covers a whole leaf lifetime, so
+a renewal never issues a certificate that would outlive its CA. Certificates
+your own issuer signed get the seven-day heads-up for the CA as well.
 
 | Material | Lasts | When it runs out | What to do |
 |---|---|---|---|
-| Workload, terminal-attestation and HTTPS certificates | 1 day | the sidecar can no longer prove its identity, sign receipts or serve HTTPS | `aac agent renew --agent <name>`, then restart the sidecar so it loads them |
-| Development CA | 7 days | certificates it signed stop being trusted, and no new ones can be issued | `renew` also replaces the CA when it is expired or within a day of expiry, or when `--ca` is given, and then reissues every certificate under it: restart the publisher so the new CA is published, restart the sidecar and anything else that trusted the old CA, and confirm with `aac agent status --agent <name> --remote` |
+| Workload, terminal-attestation and HTTPS certificates | 90 days | the sidecar can no longer prove its identity, sign receipts or serve HTTPS | `aac agent renew --agent <name>`, then restart the sidecar so it loads them |
+| Development CA | 365 days | certificates it signed stop being trusted, and no new ones can be issued | `renew` also replaces the CA when it is expired or within 90 days of expiry, or when `--ca` is given, and then reissues every certificate under it: restart the publisher so the new CA is published, restart the sidecar and anything else that trusted the old CA, and confirm with `aac agent status --agent <name> --remote` |
 | Tenant-admin session | hours | administration commands ask you to sign in again | `aac sso login` |
 | Tenant API key, tenant-admin signing key, root signing key | do not expire | — | replaced only on purpose: see "Keys" and "Setting up aac-cli on a new computer" |
 
 A simple routine: when you start work, run
 `aac agent status --agent <name>`, and when it names renewal, run
-`aac agent renew --agent <name>` and restart the sidecar. About once
-a week that renewal also replaces the development CA (`renew` then reports
+`aac agent renew --agent <name>` and restart the sidecar. About every nine
+months, once the CA is within 90 days of expiry, that renewal also replaces
+the development CA (`renew` then reports
 `republication_required: true`): restart the publisher, the sidecar and the
 agent, and anything else that trusted the old CA. Renewing is safe to
 repeat, but it is not a no-op: every run issues fresh keys and moves the old

{aac_cli-0.2.12 → aac_cli-0.2.13}/pyproject.toml

@@ -32,7 +32,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "aac-cli"
-version = "0.2.12"
+version = "0.2.13"
 description = "The aac platform CLI — headless operator interface to the AAC control plane (tenant registration, chain audit)."
 readme = "README.md"
 requires-python = ">=3.11"