8000 Allow CA interface to control validation of Client Identifiers for device-attest-01 acme requests by mishaslavin · Pull Request #2306 · smallstep/certificates · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

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

wants to merge 1 commit into from

Conversation

mishaslavin
Copy link

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

@venkyg-sec @mishaslavin
squashing commits
06b47e1 
author Venky Gopal <vnktshgopalg@gmail.com> 1693934844 -0400
committer mishaslavin <63741893+mishaslavin@users.noreply.github.com> 1749672251 -0700
@github-actions github-actions bot added the needs triage Waiting for discussion / prioritization by team label Jun 12, 2025
@mishaslavin mishaslavin changed the title squashing commits Allow CA interface to control validation of Client Identifiers for device-attest-01 acme requests #1525 Jun 12, 2025
@mishaslavin mishaslavin changed the title Allow CA interface to control validation of Client Identifiers for device-attest-01 acme requests #1525 Allow CA interface to control validation of Client Identifiers for device-attest-01 acme requests Jun 12, 2025
@mishaslavin
Copy link
Author
mishaslavin commented 823B Jun 12, 2025

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

@venkyg-sec venkyg-sec mentioned this pull request Jun 16, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
needs triage Waiting for discussion / prioritization by team
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@mishaslavin @venkyg-sec
0