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

[venkyg-sec]

Name of feature:

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.

Supporting links/other PRs/issues:

Tests

[certificates]$ make test
✓  api/render (9ms) (coverage: 83.7% of statements)
✓  api/read (16ms) (coverage: 100.0% of statements)
✓  api/log (28ms) (coverage: 52.9% of statements)
✓  acme/db/nosql (64ms) (coverage: 97.0% of statements)
✓  acme/api (699ms) (coverage: 92.4% of statements)
∅  authority/admin
✓  authority/admin/api (61ms) (coverage: 88.3% of statements)
∅  authority/administrator
✓  authority/admin/db/nosql (35ms) (coverage: 94.8% of statements)
✓  authority/config (21ms) (coverage: 67.5% of statements)
✓  authority/policy (19ms) (coverage: 41.7% of statements)
✓  authority/internal/constraints (40ms) (coverage: 81.6% of statements)
✓  authority (1.234s) (coverage: 46.4% of statements)
✓  api (2.249s) (coverage: 76.9% of statements)
✓  cas/apiv1 (14ms) (coverage: 97.4% of statements)
✓  cas (21ms) (coverage: 95.0% of statements)
✓  ca/identity (57ms) (coverage: 93.3% of statements)
✓  cas/cloudcas (135ms) (coverage: 96.4% of statements)
✓  cas/vaultcas/auth/approle (20ms) (coverage: 86.4% of statements)
✓  cas/vaultcas (24ms) (coverage: 79.7% of statements)
✓  cas/softcas (542ms) (coverage: 91.3% of statements)
✓  cas/vaultcas/auth/kubernetes (10ms) (coverage: 87.5% of statements)
∅  commands
∅  cmd/step-ca
∅  examples/basic-client
∅  examples/basic-federation/client
✓  errs (6ms) (coverage: 7.6% of statements)
✓  db (9ms) (coverage: 26.6% of statements)
∅  examples/basic-federation/server
∅  examples/bootstrap-client
∅  examples/bootstrap-mtls-server
∅  examples/bootstrap-tls-server
∅  monitoring
✓  logging (10ms) (coverage: 31.1% of statements)
∅  scep
✓  policy (35ms) (coverage: 93.0% of statements)
✓  pki (188ms) (coverage: 17.3% of statements)
∅  scripts/badger-migration
∅  server
✓  scep/api (26ms) (coverage: 15.4% of statements)
✓  templates (25ms) (coverage: 93.5% of statements)
✓  webhook (8ms) (coverage: 71.1% of statements)
✓  acme (6.517s) (coverage: 64.4% of statements)
✓  cas/stepcas (5.343s) (coverage: 95.9% of statements)
✓  authority/provisioner (17.583s) (coverage: 81.4% of statements)
✓  ca (27.536s) (coverage: 43.0% of statements)

DONE 4318 tests in 31.048s
✓  acme (9.128s) (coverage: 73.1% of statements)

DONE 302 tests in 10.734s

💔Thank you!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

:white_check_mark: venkyg-sec
:x: Venkatesh Gopal

---

Venkatesh Gopal seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}