[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
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
