Add ACME Wire configuration #299
Conversation
step-ca/provisioners.mdx
Outdated
| } | ||
| ``` | ||
|
|
||
| - The `wire-oidc-01` and `wire-dpop-01` challenge types must both be enabled. |
There was a problem hiding this comment.
A small formatting request. I think this bulleted list should align with same style we use for other other provisioner config descriptions. See JWK for example. The field name in bold, followed by a description of the available options and any other operational notes related to how this field interacts with this provisioner.
There was a problem hiding this comment.
Hehe, I only looked at the SCEP one, which has this style. I'll update this; and likely also the SCEP one, if it makes sense.
There was a problem hiding this comment.
I've updated the style. I decided to not include all the new layers, and to only put the leaf level as the new bullets to keep it simple. Alternatively, could use dotted levels?
SCEP changes are in #303
| </Alert> | ||
|
|
||
| The `wire-oidc-01` and `wire-dpop-01` challenges enable `step-ca` to issue certificates to Wire clients. | ||
| Wire clients make use of a user and a device identity, both of which are challenged and verified, after which the identities are combined into a single X.509 certificate. |
There was a problem hiding this comment.
We have both broad (eg. OIDC) and narrow (eg. AWS) provisioner types. Where does Wire fit in? Could these new Wire challenge types offer a combined device + user identity certificate flow for any application? How useful are they outside of Wire clients? Would a user have to write their own ACME client from scratch for these challenge types, or is there a reference implementation available in open source?
If the Wire challenge types have a more broad potential, do we have the right names for them? And for this section of the docs?
There was a problem hiding this comment.
We have both broad (eg. OIDC) and narrow (eg. AWS) provisioner types. Where does Wire fit in?
The Wire integration uses ACME as the core protocol, with two new identifier types, and two new challenge types. It's a subtype of the ACME provisioner, similar to ACME for Device Attestation, so that's why it's on the same level as that. It uses both OIDC and DPoP, so there are some similarities to the OIDC provisioner, but it should be considered a separate thing.
Could these new Wire challenge types offer a combined device + user identity certificate flow for any application? How useful are they outside of Wire clients?
Potentially yes, and we've looked at doing so. There's some overlap with existing draft RFCs for extensions to ACME, as well as some other related ones. The verdict was that it would most probably take quite long to get to a place where we would have a "fully standard approach", so that's why this extension is now fairly tightly coupled to just Wire. We decided to put configuration in a new wire object, apart from enabling the challenge types, containing the configuration neatly together. This should make refactoring easier, if we were to reconsider the decision to make this Wire specific. That said, similar concepts as used in this integration would be nice candidates to generalize, and we can learn from this integration being used in practice to see what makes sense. Besides that, I think Wire would start the process of putting these new identifiers and challenges in the official registries.
Would a user have to write their own ACME client from scratch for these challenge types, or is there a reference implementation available in open source?
Wire is actively working on integrating this in their clients. I don't know the exact status, but I think the web client implementation is furthest along. They have an end-to-end testing framework that also performs the full ACME flow using the new identifier types written in Rust as part of rusty-jwt-tools. Maybe a core Rust library supporting these is an option. Outside of the Wire ecosystem, users would be pretty much on their own.
If the Wire challenge types have a more broad potential, do we have the right names for them? And for this section of the docs?
We decided to prefix everything with wire- now, so that things are namespaced and should be less of an issue if we were to generalize them.
There was a problem hiding this comment.
Just adding onto to what Herman said:
Regarding stable documentation of the ACME extensions in a neutral location, I'll have an internet draft by 4-Mar-2024 (draft-mahy-acme-wire-types), and I'll inform the ACME WG mailing list and request publication of an individual RFC.
Regarding ACME client implementations, all the Wire clients (web, iOS, Android) have implemented the full ACME flow with these identifiers and challenges. All this client code and the Wire crypto libraries are open source.
step-ca/provisioners.mdx
Outdated
| * **provider.signatureAlgorithms**<Reference id="star6" marker="*" />: sets the supported OIDC signature algorithms. Ignored if `discoveryBaseUrl` is set. | ||
| * **clientId**: sets the OIDC client ID used in OIDC token validation. | ||
| * **config.signatureAlgorithms**<Reference id="star6" marker="*" />: sets the OIDC signature algorithms to be used in validation. | ||
| * **transform**<Reference id="star6" marker="*" />: a Go template that can be used to map and/or transform properties in the OIDC token. Different SSO IdPs include different claims in their OIDC tokens. Using this `transform` template, the tokens are verified first, then transformed and persisted. Transformation uses the same engine as our certificate template engine. The properties from the transformed token can be referenced in the certificate template configured in the `x509` option. |
There was a problem hiding this comment.
Please consider adding a link to the Go template syntax.
Improve SCEP provisioner docs
|
@tashian the SCEP changes got merged into this one. Can you re-review the latest changes in this one? |
No description provided.