feat(agent): device identity enrollment and channel

[Benoît Cortier (CBenoit)]

Devolutions Agent can obtain its own device identity from a management server such as Devolutions Server: a server-issued device ID and an X.509 certificate whose private key never leaves the machine.
One reusable enrollment token, deployable through msiexec or Microsoft Intune, enrolls any number of machines.
After enrolling, the agent renews its certificate on its own and keeps an authenticated, bidirectional gRPC channel to the server, so the server can reach the agent (for example, to ask it to renew).

This draft contains the product-neutral contract and its conformance suite; the agent implementation follows in the same PR:

• docs/agent-identity/CONTRACT.md: the agent-facing HTTP API, the RFC 9421 request-signature profile, the gRPC channel and its proof-of-possession handshake, and the agent's local files and configuration.
• docs/agent-identity/test-vectors.json: shared signature, channel-proof and CSR vectors for every implementation.
• agent-identity-channel-proto: the channel schema for Rust, also published as the Devolutions.AgentIdentity.Channel NuGet package for server implementers.
• agent-identity-mock and agent-identity-conformance: a mock server and a conformance tester that checks a server (the mock, or a real DVLS) and the agent against the contract; the testsuite runs both.

[Benoît Cortier (CBenoit)]

Implementation notes (Phase 1: contract and conformance suite)

Contents

• docs/agent-identity/CONTRACT.md v0.3 (approved), including the §10.1 clarification that extra_trusted_root is a PEM bundle.
• docs/agent-identity/test-vectors.json, produced by a throwaway generator that builds the signature bases by hand and signs deterministically (RFC 6979).
  It was cross-checked with Python cryptography and includes RFC 9421 Appendix B.2.4.
• agent-identity-channel-proto: tonic/prost code generated with vendored protoc, passed through prost_build::Config::protoc_executable rather than set_var.
  The same .proto builds the Devolutions.AgentIdentity.Channel NuGet package (net10.0, Google.Protobuf + Grpc.Core.Api).
  CI builds the package and publish-libraries.yml publishes it; the new package ID may need nuget.org trusted-publishing setup.
• agent-identity-mock: the conformance oracle.
  It verifies the RFC 9421 profile by hand with p256, without an RFC 9421 library, applying the §6 checks in contract order and committing each nonce only after its signature verifies.
  Authenticated handlers take an AuthenticatedDevice that only the verifier can construct.
  A unit test runs every entry of test-vectors.json through the server's own verifier.
• agent-identity-conformance: a custom harness that exits non-zero on failure.
  • Protocol tests act as a raw client, with their own signer written independently of the mock.
  • Agent tests spawn devolutions-agent run with DAGENT_CONFIG_PATH and stand in for the MSI through the pending file (Unix 0600; Windows DPAPI machine scope with a protected DACL).
  • Observation order: admin API first, agent files second, logs last.
  • Mock-only tests are skipped with --target dvls.
  • Rotation tests against DVLS need --disposable-dvls-target.
• The testsuite starts two mocks under /mock and runs the tester against them.

Current results (Windows, local)

• 47/47 protocol tests pass against the mock (about 15 s).
• Expected to fail until the agent implementation lands: the 22 a_* tests below, which need devolutions-agent identity support.
  a_file_backend_permissions is Unix-only and skips on Windows.
  Until then, the testsuite test agent_identity::conformance is red in CI; fmt, clippy, the existing tests and the protocol tests are green.
  • a_pending_file_enroll_success, a_pending_file_deleted_on_permanent_error, a_pending_file_kept_on_transient_error, a_token_never_logged
  • a_same_token_no_enrollment, a_same_token_rejected_identity_no_enrollment, a_different_token_replaces_identity, a_cli_identity_enroll_writes_pending_file
  • a_renewal_happy_path, a_renewal_lost_response_retried, a_channel_connected_and_metadata, a_make_before_break_on_renewal
  • a_request_renewal_connected, a_request_renewal_while_offline, a_reconnect_make_before_break, a_revocation_stops_agent
  • a_device_unknown_recorded, a_no_channel_when_absent, a_multi_authority, a_key_non_exportable
  • a_rotation_migrates_connected_agent, a_rotation_migrates_on_schedule

Dependencies

• The workspace resolves p256 0.14.0-rc.14 and ecdsa 0.17.0-rc.22, because ironrdp-connector 0.10 → sspi 0.21 → picky =7.0.0-rc.25 pins those release candidates.
  The mock and tester therefore pin p256 =0.14.0-rc.14.
• The agent's signing layer, in the next phase, holds httpsig at =0.0.24 for the same reason.
  httpsig is used only to build and sign the agent's own requests, never to parse incoming headers, because 0.0.24 can panic on malformed Signature-Input.
• Follow-up: once IronRDP releases on sspi 0.22 (picky rc.26), bump the picky pins to rc.26 and httpsig to 0.0.26, and drop the duplicate p256/ecdsa generation.

Suite decisions

• Enroll idempotence is checked before token expiry and exhaustion, so a lost response on a maxUses = 1 token can be retried.
• Chain checks:
  • The last chain element must equal a published root byte for byte.
  • Links are checked by name, and their signatures are verified for P-256 issuers.
  • Validity is checked at evaluation time.
  • There's no full RFC 5280 path validation (§4, invariant 10).
• Windows test cleanup deletes a machine key only when the key didn't exist before the test, its name matches the contract pattern, and its authority is the server-issued authority_id.

Review
Each suite task went through a coder ↔ reviewer loop using the repository code-review skill.
The tester task ended after 3 rounds (19 → 14 → 8 findings); a follow-up fix task addressed the remaining 8 and was approved in round 2.

Note

LLM-assisted content (no human feedback).