Allow External Validation of Identifiers for device-attest-01 certificates

[venkyg-sec]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

For requests of type device-attest-01 there is an expectation in step-ca that the Client Identifier (aka permanent identifier) be either the Serial or the UDID, during the challenge validation phase. This constraint also applies to the Common Name in the CSR during the Order finalization phase. This constraint makes it challenging to quickly adopt & migrate Enterprise Certificate issuances to ACME based attestation as different certificates have different requirements.
For instance, Enterprises might want to include one-time tokens or JWTs to prove user authentication before having them connect to WIFI networks, but still want those client Certificates to be attested. Therefore the core ask in this ticket is to a) remove the serial (or) UUID constraint for ClientIdentifiers and Common Name b) and instead let validation be controlled either by propagating the AttestationData to the CA CertificateRequest (or) potentially doing this through a attestation specific Webhooks and pass all of the Attestation Data (serial, UUID, other information from here)

A draft/example PR is in #1525 to add more concreteness to this ask, but is not mature enough.

Why is this needed?

Promotes broader adoption of attested ACME certificate issuance for Enterprises.
Another aspect worth calling out is while this request is focussed on the "apple" attestation ClientIdentifier, this will also apply to the "tpm" attestation requests eventually as we'd want to include some form of user authentication object. As I learn from @hslatman , this could potentially also be an extension on the ACME DA RFC (or) maybe another ACME extension all-together (or) we end up deciding that Enterprises just perform the User validation portion of this through web-hooks or similar means and always asynchronously validate any user authN/presence. But reaching a decision is crucial to allow enterprises to decide how much of their Certificate issuance can be actually moved to an ACME based workflow.

This ticket has been created to start the discussion. Thanks to @hslatman who's been very helpful throughout this process.

[jamesez]

I asked for something similar over on Discord, which is sending a webhook get all the attestation data, so it can make a decision on whether to permit the certificate issuance or not.

[jessepeterson]

I'd just like to add that the Client Identifier/permanent identifier in ACME parlance is very similar to the CSR challenge in the SCEP protocol. I tend to think of them as analogous.

To that end the same sorts of workflows ought to be enabled by using them in similar ways: i.e. embedding one-time tokens (JWTs, HMACs, or other unknown tokens) in the challenge/permanent identifier. Perhaps the same web hook could be utilized for either protocol (with a property handed over as to which protocol the request came in through). This would be input to how I want to check/validate a CSR and incoming certificate request to make the decision on whether to issue the cert.

[venkyg-sec]

Hello folks( cc: @hslatman) - just wanted to check if this is still in the works and/or of is interest for inclusion in any of the future releases.

[hslatman]

Hey @venkyg-sec, it's been on my list for a while to talk to you about this. Short answer is yes, but details to be discussed. I'll be in touch in chat.

[venkyg-sec]

Hey @venkyg-sec, it's been on my list for a while to talk to you about this. Short answer is yes, but details to be discussed. I'll be in touch in chat.

Sure thing - let me know if you want to chat sometime. Feel free to also bring up in our channel (or) setup some time (add @jessepeterson as well :-) we were chatting about some more interesting features to have)