[v1.17] docs: Sentry Ed25519 workload identity keys

daprdocs/content/en/concepts/security-concept.md

@@ -71,7 +71,34 @@ Unless you've provided existing root certificates, the Sentry service automatica
 
 When root certificates are replaced (secret in Kubernetes mode and filesystem for self-hosted mode), Sentry picks them up and rebuilds the trust chain, without restart and with zero downtime to Sentry.
 
-When a new Dapr sidecar initializes, it checks if mTLS is enabled. If so, an ECDSA private key and certificate signing request are generated and sent to Sentry via a gRPC interface. The communication between the Dapr sidecar and Sentry is authenticated using the trust chain certificate, which is injected into each Dapr instance by the Dapr Sidecar Injector system service.
+When a new Dapr sidecar initializes, it checks if mTLS is enabled. If so, a private key and certificate signing request are generated and sent to Sentry via a gRPC interface. The communication between the Dapr sidecar and Sentry is authenticated using the trust chain certificate, which is injected into each Dapr instance by the Dapr Sidecar Injector system service.
+
+### Workload identity key algorithm
+
+Starting with Dapr **1.18**, Sentry generates workload identity keys using **Ed25519** instead of ECDSA P-256.
+
+| Scope | Algorithm (pre-1.18) | Algorithm (1.18+) |
+|---|---|---|
+| Root CA and issuer CA keys | ECDSA P-256 (`ECDSAWithSHA256`) | Ed25519 (`PureEd25519`) |
+| Workload (sidecar) X.509 certificates | ECDSA P-256 | Ed25519 |
+| Injector / Operator webhook serving certs | ECDSA P-256 | **RSA** (intentional — see below) |
+| JWT / OIDC signing | RSA-2048 | RSA-2048 (unchanged) |
+
+**Why Ed25519?** Ed25519 keys are smaller than P-256 (32-byte private key; 32-byte public key vs. 65 bytes uncompressed for P-256), signatures are 64 bytes (vs. ~72 bytes for P-256 DER), signing and verification are faster, and the curve design eliminates several known side-channel attack surfaces.
+
+**What stays RSA?** The Dapr injector and operator use RSA keys for their webhook serving certificates. Some managed Kubernetes distributions (including certain versions of GKE, EKS, and AKS) reject Ed25519 TLS certificates on admission webhook endpoints. RSA is retained there to ensure the sidecar injector and CRD conversion webhook remain reachable on all target environments. See [dapr/dapr#9873](https://github.com/dapr/dapr/pull/9873) for details.
+
+**JWT signing** remains RSA-2048 for compatibility with cloud provider OIDC implementations, which have broad RSA support but inconsistent Ed25519 support.
+
+**Mixed-version rolling upgrades** are fully supported. Sentry signs workload CSRs from any algorithm client — the signature algorithm on the issued cert is determined by Sentry's issuer key, not the CSR. A 1.17.x sidecar submitting an ECDSA CSR receives an Ed25519-signed workload cert from a 1.18 Sentry during a rolling upgrade.
+
+{{% alert title="FIPS / regulated environments" color="warning" %}}
+Ed25519 (Curve25519) may not satisfy FIPS 140 requirements; consult your compliance scope. FIPS 140-2 does not include Ed25519. FIPS 140-3 has provisional EdDSA support but approval status varies by module and jurisdiction. If your environment requires FIPS 140 compliance, supply your own root and issuer certificates generated with an approved algorithm (RSA or ECDSA P-256/P-384) using the [bring-your-own-certificates]({{% ref "mtls#bringing-your-own-certificates" %}}) path. When you bring your own CA, Sentry signs workload CSRs using the algorithm of the issuer key you provide, not Ed25519.
+{{% /alert %}}
+
+{{% alert title="Downgrade floor: 1.17.7" color="warning" %}}
+Sentry writes the Ed25519-keyed CA bundle to the `dapr-trust-bundle` Kubernetes secret. Sentry versions **before 1.17.7** cannot parse this bundle and crash on startup. Do not roll back from 1.18 to a version earlier than 1.17.7 without first rotating the CA. See the [1.18 release notes](https://github.com/dapr/dapr/releases/tag/v1.18.0) for the safe rollback path.
+{{% /alert %}}
 
 ### Configuring mTLS
 

daprdocs/content/en/operations/security/mtls.md

@@ -12,6 +12,16 @@ Dapr allows operators and developers to bring in their own certificates, or inst
 
 For detailed information on mTLS, read the [security concepts section]({{% ref "security-concept.md" %}}).
 
+## Workload identity key algorithm (Ed25519, Dapr 1.18+) {#workload-identity-key-algorithm}
+
+Starting with Dapr **1.18**, Sentry generates workload identity keys using **Ed25519** instead of ECDSA P-256. On a normal install or upgrade this is transparent — no configuration change is needed.
+
+For a full explanation of what changed, why, and the compatibility matrix (including FIPS requirements and the 1.17.7 downgrade floor), see [Workload identity key algorithm]({{% ref "security-concept.md#workload-identity-key-algorithm" %}}) in the security concepts page.
+
+{{% alert title="Bringing your own CA" color="primary" %}}
+When you supply your own root and issuer certificates, Sentry signs workload CSRs using the algorithm of the **issuer key you provide**, not Ed25519. If your CA key is RSA or ECDSA, workload certs will be signed with that algorithm. This is the recommended path for FIPS-compliant environments.
+{{% /alert %}}
+
 If custom certificates have not been provided, Dapr automatically creates and persist self-signed certs valid for one year.
 In Kubernetes, the certs are persisted to a secret that resides in the namespace of the Dapr system pods, accessible only to them.
 In self-hosted mode, the certs are persisted to disk.
@@ -129,6 +139,10 @@ basicConstraints = critical, CA:true, pathlen:0
 
 Run the following to generate the root cert and key
 
+{{% alert title="Dapr 1.18+" color="primary" %}}
+The example below generates an ECDSA P-256 key. RSA keys (`openssl genrsa`) are also accepted. When you supply your own CA, Sentry signs workload CSRs using the algorithm of the issuer key you provide. ECDSA P-256 and RSA are the recommended choices for FIPS-compliant environments.
+{{% /alert %}}
+
 ```bash
 # skip the following line to reuse an existing root key, required for rotating expiring certificates
 openssl ecparam -genkey -name prime256v1 | openssl ec -out root.key
@@ -445,7 +459,7 @@ In order to start Sentry service with a custom config, use the following flag:
 
 ### Bringing your own certificates
 
-In order to provide your own credentials, create ECDSA PEM encoded root and issuer certificates and place them on the file system.
+In order to provide your own credentials, create PEM encoded root and issuer certificates (RSA, ECDSA, or Ed25519) and place them on the file system.
 Tell the Sentry service where to load the certificates from using the `--issuer-credentials` flag.
 
 The next examples creates root and issuer certs and loads them with the Sentry service.