Hi all, having looked at certificate management for client, and other uses, in 3GPP, I think there is merit in pursuing the ideas in this draft further, and in keeping the work in the ACME WG.
Drilling into the 5G specs, they have an old normative section using CMPv2 and a recently added informative section on ACME. The ACME annex uses 3GPP defined extensions to the TKAuth RFC. It could also be improved upon further, but such work is better done here as it not 3GPP specific, and if done here it is easier to account for related work on e.g. the RATS ACME draft. When evaluating those two mechanisms for cert management the ACME version has 2 clear benefits over the CMPv2 solution - up-to-date point in time proof of something - separating account management credentials from the certificate key pairs Issuing a new certificate based on control/use of the key of a previous certificate presents obvious headaches if that key has been compromised as well as the potential for cross-protocol attacks to be introduced. Decoupling the credentials also allows for a cleaner separation of roles. These observations would likely apply if EST were used rather than CMPv2. Matt G1 – NCSC Telecoms Security Consultant (Standards) [email protected] From: Kathleen Moriarty <[email protected]> Sent: 04 October 2025 12:41 To: Michael Richardson <[email protected]> Cc: [email protected] Subject: [Acme] Re: not publishing draft-ietf-acme-client On Wed, Oct 1, 2025 at 2:28 PM Kathleen Moriarty <[email protected]<mailto:[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]<mailto:mcr%[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]<mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Acme mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Best regards, Kathleen -- Best regards, Kathleen
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
