Allow CA interface to control validation of Client Identifiers for device-attest-01 acme requests

[mishaslavin]

author Venky Gopal vnktshgopalg@gmail.com 1693934844 -0400 committer mishaslavin 63741893+mishaslavin@users.noreply.github.com 1749672251 -0700

Name of feature:

(Duplicate of #1525)

Propagate attested client identifiers (serial and attestation object) to CA interface & allow global API level bypass of a) Client Identitifer to UUID/Serial association b) CSR CN to Client Identifier association.
This allows organizations to specify arbitrary values in Apple's ClientIdentifier field as part of the MDM ACME payload and defer validation of that identifier to the Certificate Authority.

The API level global bypass is not great, but I created to add more concreteness to the ask.

Pain or issue this feature alleviates:

Allows us to specify any arbitrary values (such as a one time token like JWT, etc in the ClientIdentifier field in the MDM payload. This is crucial for organizations to be able to use this payload for different types of attested certificates having different user authentication requirements.

Why is this important to the project (if not answered above):

Allows adoption of device-attest-01 in ACME for different types of Attested certificates in Enterprises.

Is there documentation on how to use this feature? If so, where?

In what environments or workflows is this feature supported?

In what environments or workflows is this feature explicitly NOT supported (if any)?

Supporting links/other PRs/issues:

(duplicate of #1525)
💔Thank you!

up-to-date test outputs:

mslavin@mslavin-wsl:~/certificates$ make test
✓  api/log (7ms) (coverage: 66.7% of statements)
✓  api/render (9ms) (coverage: 83.7% of statements)
∅  authority/admin (10ms) (coverage: 0.0% of statements)
∅  api/models (13ms) (coverage: 0.0% of statements)
✓  acme/wire (15ms) (coverage: 96.0% of statements)
✓  api/read (19ms) (coverage: 100.0% of statements)
✓  authority/config (30ms) (coverage: 67.0% of statements)
∅  authority/administrator (30ms) (coverage: 0.0% of statements)
✓  authority/admin/db/nosql (33ms) (coverage: 94.8% of statements)
✓  authority/admin/api (78ms) (coverage: 88.3% of statements)
✓  authority/internal/constraints (21ms) (coverage: 81.6% of statements)
✓  authority/policy (30ms) (coverage: 41.7% of statements)
✓  acme/db/nosql (695ms) (coverage: 96.7% of statements)
✓  acme/api (750ms) (coverage: 91.9% of statements)
✓  authority/provisioner/wire (65ms) (coverage: 90.4% of statements)
∅  ca/client (5ms) (coverage: 0.0% of statements)
✓  cas/apiv1 (6ms) (coverage: 97.6% of statements)
✓  cas (19ms) (coverage: 95.0% of statements)
✓  ca/identity (45ms) (coverage: 93.3% of statements)
✓  cas/cloudcas (185ms) (coverage: 96.4% of statements)
✓  authority (2.188s) (coverage: 47.5% of statements)
∅  cmd/step-ca (6ms) (coverage: 0.0% of statements)
✓  cas/vaultcas/auth/approle (9ms) (coverage: 86.4% of statements)
∅  commands (9ms) (coverage: 0.0% of statements)
✓  cas/vaultcas/auth/kubernetes (19ms) (coverage: 87.5% of statements)
✓  cas/vaultcas/auth/aws (25ms) (coverage: 82.8% of statements)
✓  cas/vaultcas (57ms) (coverage: 79.2% of statements)
✓  cas/softcas (872ms) (coverage: 91.6% of statements)
∅  examples/basic-federation/client (4ms) (coverage: 0.0% of statements)
∅  examples/basic-client (5ms) (coverage: 0.0% of statements)
∅  internal/metrix (5ms) (coverage: 0.0% of statements)
∅  examples/bootstrap-mtls-server (6ms) (coverage: 0.0% of statements)
∅  examples/bootstrap-tls-server (6ms) (coverage: 0.0% of statements)
∅  examples/bootstrap-client (6ms) (coverage: 0.0% of statements)
∅  examples/basic-federation/server (7ms) (coverage: 0.0% of statements)
✓  internal/cast (6ms) (coverage: 100.0% of statements)
∅  internal/httptransport (8ms) (coverage: 0.0% of statements)
∅  internal/userid (6ms) (coverage: 0.0% of statements)
✓  errs (11ms) (coverage: 36.4% of statements)
✓  db (19ms) (coverage: 26.5% of statements)
✓  middleware/requestid (4ms) (coverage: 95.2% of statements)
✓  logging (12ms) (coverage: 45.9% of statements)
∅  monitoring (40ms) (coverage: 0.0% of statements)
✓  api (3.428s) (coverage: 78.5% of statements)
∅  server (17ms) (coverage: 0.0% of statements)
✓  scep/api (17ms) (coverage: 26.8% of statements)
✓  templates (19ms) (coverage: 93.5% of statements)
✓  policy (24ms) (coverage: 93.0% of statements)
∅  scripts/badger-migration (33ms) (coverage: 0.0% of statements)
✓  pki (373ms) (coverage: 33.8% of statements)
✓  webhook (7ms) (coverage: 69.6% of statements)
∅  test/integration/scep/internal/x509 (8ms) (coverage: 0.0% of statements)
✓  scep (1.827s) (coverage: 36.6% of statements)
✓  test/integration (1.889s)
✓  acme (7.201s) (coverage: 68.3% of statements)
✓  cas/stepcas (9.893s) (coverage: 93.9% of statements)
✓  test/integration/scep (13.531s)
✓  authority/provisioner (24.883s) (coverage: 82.3% of statements)
✓  ca (29.187s) (coverage: 43.3% of statements)

=== Skipped
=== SKIP: acme Test_parseAndVerifyWireAccessToken (0.00s)
    challenge_wire_test.go:2126: skip until we can retrieve public key from e2e test, so that we can actually verify the token

DONE 4773 tests, 1 skipped in 31.102s
✓  acme (13.696s) (coverage: 75.1% of statements)

=== Skipped
=== SKIP: acme Test_parseAndVerifyWireAccessToken (0.00s)
    challenge_wire_test.go:2126: skip until we can retrieve public key from e2e test, so that we can actually verify the token

DONE 366 tests, 1 skipped in 13.696s

[mishaslavin]

hey all, hoping to restart the discussion from #1525 and see if this can be merged?