Hej Michael, Thanks for the feedback from reading the draft. I have created a GitHub issue to track this and address your points below: https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/issues/7
We will work on the draft addressing this and share the updates. Kindly, Sven Rajala International PKI Man of Mystery M: +1 540 687 0761 [email protected]<https://www.keyfactor.com/> From: Michael Richardson <[email protected]> Date: Thursday, 2025 September 11 at 23:42 To: [email protected] <[email protected]> Subject: [Acme] Re: I-D Action: draft-acme-device-attest-05.txt [email protected] wrote: > Title: Automated Certificate Management Environment (ACME) Device Attestation Extension > Authors: Brandon Weeks > Ganesh Mallaya > Sven Rajala > Name: draft-acme-device-attest-05.txt The posting reminded me to re-read this document. [Next time, please use draft-AUTHOR-acme-device-attest, to make it clearer that this document has not been adopted] I found the description in section on how the ACME Server validates that the constructed WebAuthN inadequately described. The w3c WebAuthN reference does not seem to be enough. That describes the how, and the what, but not the why. How does the ACME Server know that some public key is associated with a particular hwSerialNum? Is that's something that's in the WebAuthN credential? Maybe it's part of the FIDO2 connection? Or is that something that is in the ACME Account key that the ACME Server has? On the whole, this seems like the a better mechanism for assigning identities to certificates used for TLS Client authentication than the methods in ietf-acme-client. I would not call this Device Attestation, btw. It's more like Device Authenticated identity to me. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
