Apologies for not being clear.
Those are noted benefits of ACME over an alternative using CMPv2 – e.g. as chosen as the method in 5G for managing client certs – and likely EST as suggested in this thread as a reason to drop work on this draft. Matt Matt G1 – NCSC Telecoms Security Consultant (Standards) [email protected] From: Aaron Gable <[email protected]> Sent: 07 October 2025 21:45 To: Matt G1 <[email protected]> Cc: Kathleen Moriarty <[email protected]>; Michael Richardson <[email protected]>; [email protected] Subject: [Acme] Re: not publishing draft-ietf-acme-client Apologies because I may just be missing context, but I don't quite understand some of the point being made here: On Tue, Oct 7, 2025 at 4:16 AM Matt G1 <[email protected]<mailto:[email protected]>> wrote: - separating account management credentials from the certificate key pairs This has always been the case in ACME -- the account key and the certificate key are different objects. Adding new validation methods doesn't change the status quo here. 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. None of the ACME validation methods currently in use nor proposed by this draft involve using a previously-issued certificate to validate issuance of a new one. How is this related to the acme-client draft? Aaron
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
