Not to steal the chairs' ability to reply. This draft was adopted by the wg in late 2022. If you take a peek at the history, you can see when that occurred. So the name is correct as it stands.
Deb Sec AD (former acme chair) On Thu, Sep 11, 2025 at 6:42 PM Michael Richardson <[email protected]> wrote: > > [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] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
