I understand less and less about ietf-acme-client. As it has been going, I do not think this document is useful to publish. 'Hallway" conversations tell me that I'm not alone. I don't have a way to fix this, as much as I would like far more use of mTLS and client certificates. But, we have passkeys instead.
ACME is a very specific kind of tool, it does best when applied to problems of defending an identity through an online challenge. What I see is that ietf-acme-client is trying to pound finishing nails in with the side of a precision calliper. Almost all of the mechanisms that I see in ietf-acme-client are authentication mechanisms; yet they are being presented as authorizations. They all require prior-setup between an authenticator and the client. Worse, some of these require maintenance of a critical secret by the ACME Server, and/or some kind of cross-enterprise protocol (radius?) to connect to an oracle that can verify the one-time-password. TOTP, HTOP, WebAuthn. (SecureID is just another TOTP, it does not need otp-01) And NONE of these things are going to do IoT. *IF* you have any of these things, you can use them to authenticate HTTPS today using existing infrastructure, then you can use EST. Another possibility is EAP-TEAP, with any of the above mechanisms as an inner method. I admit that TEAP is still a mess. -- 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]
