On Wed, Oct 1, 2025 at 2:28 PM Kathleen Moriarty < [email protected]> wrote:
> Point is taken, but please try to be kinder in your posts. I see this on > the list I manage as well and do not want to see bashing escalate and then > see others blamed for their responses to your messages. > > I'm not pushing, I am waiting on real use cases as was stated in my last > message. I removed content that was unnecessary and will see if enough > comes in to justify a move forward. If Nancy and her team have a real need, > let's wait to see what it is, there's no rush. > > Best regards, > Kathleen > > On Wed, Oct 1, 2025 at 12:04 PM Michael Richardson <[email protected]> > wrote: > >> >> 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 have had different conversations, this reads as "what is being said behind your back". This type of sentence is why people wait several days before providing a fuller response. The draft is pending input and will work with that input. If people no longer see it as useful for investigating their use cases, then it won't go forward. It was based on a workflow from getting code signing certificates. At the time written, DigiCert said they were already doing what was described. > 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. >> > Code and document signing can require a person to be the client. This was written at a time where it was a year between issuance and that needed to go down. > 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) >> > We used to write concise standards that added a single point and this seems to be a hurdle for some reason these days. Concise additions can be very helpful. This addition of a radius would be in the implementation and it's already defined on how we do it, this is not something new. It's only a reference that's needed. For WebAuthn there is also single device mode and multi-device mode and these are distinct in how they are setup. The latter wasn't defined when this was written and I have a strong preference for single device mode when talking about something like certificate/key issuance and maintenance. Here's a blog describing a setup that follows this pattern for single device mode (which is what was top of mind as it's more secure than mult-device mode: https://blog.daknob.net/acme-end-user-client-certificates/ Maybe it isn't needed, but if it is, it would be good to understand. He allows access to the external token at the time periods when updates are needed of the ACME issued certificate and key. And NONE of these things are going to do IoT. >> > Let's see what Nancy comes back with as that's part of what her team is exploring. > >> *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. >> > W3C solved the use case they were exploring in another way. They do not need this draft. There were a few others that expressed interest. It's okay if this draft dies, but let's see what people need first. Best regards, Kathleen >> -- >> 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] >> > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
