Hi all, I'm supportive of splitting the `pk` identifier type and the `pk-01` challenge into a separate draft. I think there's a lot to discuss even with a scope that small, including alternative challenge types like performing a tls-alpn-01-style handshake using the keypair. I also freely admit that this is the portion of the draft that I both care about (as someone who has been promoting the idea of a pubkey identifier type for a while) and that I actually understand.
I've been failing to understand the motivation and details of the other parts of this draft for a long time now, and had essentially given up. Grace and Geng Feng, thank you so much for the detailed description of how you envision this being used; it feels like the first time I've truly understood the end-goal here. With this additional context, I'm also supportive of continuing development of this ACME-OPAQUE mode in a separate draft from the above. Thanks again, Aaron On Sun, Mar 8, 2026 at 7:23 PM Mike Ounsworth <[email protected]> wrote: > Hello Geng Feng, > > Thank you for the excellent background context on the application > motivations that are driving this draft. > > In particular, I understand now why you want to to issue certificates for > password-derived OPAQUE keys. As I understand it: this is for cases where a > user is connecting from a public machine: they will either enter a > password, or personal meeting code, or something of that nature, which is > derived into a asymmetric key, and then the system needs to issue a > certificate to them (presumably linking the OPAQUE-derived public key to > the user's name or account info that the system already knows). In this > case, the pk-01 check is actually filling the role of proving that the > applicant knows the password. This is extremely interesting, and I > understand now the value of this use case. It is certainly new and > different from traditional uses of the ACME protocol, so I expect that this > use case will receive a fair amount of scrutiny about Security > Considerations and how an ACME-OPAQUE mode interacts with other ACME modes, > identifiers, and challenge types. For example, what happens if the ACME > Client uses ACME-OPAQUE mode and also specifies other identifiers that > require http-01, dns-01 or email-reply-00 (RFC8823)? Maybe there are no > interactions and the pk-01 and other challenges are ok to work > independently in parallel, but I think questions like this will need to be > explored. > > I think for now it is ok for you to have a big draft that combines all use > cases into one draft, but you might find it easier to progress through the > WG process if you split into multiple drafts: > * a draft specifying the pk-01 mechanism > * a draft specifying the ACME-OPAQUE mode, which normatively references > the pk-01 draft. > * a draft specifying how to use an existing certificate from a different > PKI (for example a different enterprise, or an initial device ID (IDevID) > cert, which normatively references the pk-01 draft. > > Or maybe not. Maybe it will turn out that there is not enough to say about > ACME-OPAQUE and ACME-Client-Cert to be worth separate drafts? (There also > exist a few other ACME drafts trying to and client cert modes, so there may > be overlap). > > > About this comment: > > > We have spent considerable time discussing proof of private key > possession in previous meetings. ... security improvements as a welcome > side effect. > > I think my point is that proof-of-possession is not universally > acknowledged as adding security. So just beware that if you make this > claim, you are setting yourself up for a lengthy (and largely pointless) > debate 😉 > > > On Sun, 8 Mar 2026 at 21:04, wupanyuuu <[email protected]> wrote: > >> Hi all, >> Due to the email restriction issue of Feng Geng, I am forwarding this >> email to ACME. >> ---- Forwarded Message ---- >> From 皮皮猪<[email protected]> <[email protected]> >> Date 03/08/2026 20:09 >> To Mike Ounsworth<[email protected]> <[email protected]>, >> Yoav Nir<[email protected]> <[email protected]>, >> aaron<[email protected]> <[email protected]> >> Cc 779788384<[email protected]> <[email protected]>, >> palos.chen<[email protected]> <[email protected]>, >> 吴攀雨<[email protected]> <[email protected]>, >> >> draft-geng-acme-public-key.authors<[email protected]> >> <[email protected]>, >> davidcadrian<[email protected]> <[email protected]>, >> acme<[email protected]> <[email protected]>, >> d<[email protected]> <[email protected]>, >> hugokraw<[email protected]> <[email protected]>, >> lewi.kevin.k<[email protected]> <[email protected]>, >> caw<[email protected]> <[email protected]> >> Subject Re: [Acme] Update to the draft-geng-acme-public-key-04 >> Hello Mike, Yoav, Aaron >> >> I'm geng feng, one of the authors, this is my personal email in the >> weekend. >> >> I fully support Mike’s personal comment that we should focus on a few key >> use cases. We intend to align on the draft’s goals moving forward to >> address this issue.Before that, I’d like to first introduce background and >> recap this work. >> >> Starting in 2021, together with other authors including Palos Chen, we >> have been working on the design of end-to-end encryption (E2EE) for >> on-premises video conferencing systems. Unlike mainstream cloud-based >> conferencing solutions, on-premises conferencing systems are primarily >> deployed in government and enterprise environments. They adopt a >> centralized server-side identity management architecture. Besides client >> applications, a large number of public conference room terminals are also >> deployed. >> >> At that time, we identified three key challenges： >> >> 1. How individual users can securely join end-to‑end encrypted >> meetings using public devices—for example, using temporary personal >> identities on such devices—while achieving forward secrecy. >> 2. The interoperability challenge of on-premises video conferencing >> systems: when users employ an internal on-premises end-to-end encrypted >> conferencing system, how to support the requirement for external guests to >> join the conference, and establish temporary end-to-end encrypted >> communication between different identity trust anchors.Similar >> interoperability issues are being standardized for cloud-based >> conferencing >> solutions in the IETF MIMI working group. >> 3. We also face the challenge of secure recovery of end-to-end >> encrypted backup data in the event of key loss. Related problems have been >> actively discussed recently within IACR. >> >> >> The first two issues are related to zero-trust identity, which inspired >> the initial idea behind our PK-01. >> >> Since then, we have been closely following the work of the IETF ACME WG. >> We have recognized that the ACME WG should provide automation not only for >> Web encryption, but for securing all forms of communication. A recent >> excellent blog post by Brocas("ACME, a brief history of one of the >> protocols which has changed the Internet Security") has further >> strengthened our commitment to this goal. Morden zero-trust architectures >> are built on a public-key-identity-centric foundation, and much excellent >> work has emerged over the past few years. In addition to ACME challenge >> mechanisms for proving resource ownership, there is a clear need to design >> new ACME challenges tightly integrated with public-key identities. >> >> Two pieces of work have greatly inspired us in addressing the first two >> issues. >> >> 1. The Opaque protocol (RFC9807 by IRTF). >> Opaque is the first saPAKE, constructed and enabled via OPRF. The >> versatility of Opaque renders it particularly valuable in practical >> deployments. See the report presented by Hugo Krawczyk at NIST "The OPAQUE >> Password Protocol: Authentication, Secret Retrieval, End-to-end security". >> 2. The paper "Let's Authenticate: Automated Certificates for User >> Authentication". >> When I first read about it, I was immediately drawn to the idea. >> Furthermore, we can design PK-01 challenges to automate certificate >> issuance for public-key identities that users and devices have already >> registered with an IDP. >> >> >> Thus, we can address the first issue as summarized below: >> >> First, a user MAY register a temporary conference public-key identity >> with an IDP for participation in the current conference. As an example >> implementation, OPAQUE can be used, in which case the user obtains a >> temporary conference password established for themselves. Using this >> password, the user can securely retrieve the temporary conference >> public-key identity and its corresponding private key from the IDP. From >> any device, at any time. >> >> Second, the user MAY apply to a CA for the issuance of a temporary >> conference certificate for this temporary conference public-key identity. >> As an example implementation, the PK-01 challenge can be used, allowing the >> user to obtain a temporary conference credential in the form of a >> certificate issued by the conference system. Based on an OPAQUE-based >> implementation, this certificate and its corresponding private key MAY be >> backed up on the IDP server with end-to-end encryption prior to use. >> >> When the conference is in session, the user MAY temporarily use a public >> conference device, enter their pre-established temporary conference >> password, and securely retrieve from the IDP the temporary conference >> certificate identity under their control and its corresponding private key. >> The credential is then securely provisioned onto the public device, >> enabling the device to perform end-to-end encrypted communication on behalf >> of the user with other conference participants. This scheme provides >> forward secrecy using one-time identities on public devices. >> >> And, we can address the second issue as summarized below: >> >> Similarly to the first issue, an internal user Alice of Enterprise A may >> register a temporary conference public key or certificate credential for an >> external conference guest Bob from Enterprise B before the meeting. As an >> example implementation, the OPAQUE protocol may be used. Alice then >> securely notifies Bob of the temporary conference password she has set for >> him via an out-of-band mechanism such as a conference invitation. Bob may >> later join Enterprise A’s end-to-end encrypted conference using the >> procedure described above. Alternatively, assuming Enterprise A and >> Enterprise B mutually trust each other’s CA certificates, fine-grained >> temporary session access control can be supported. In this case, based on >> PK-01, Bob may present his Enterprise B identity certificate to the CA of >> Enterprise A to apply for a temporary conference identity certificate. All >> devices and network nodes of Enterprise A can then identify and verify >> Bob’s temporary identity and access permissions. This scenario is analogous >> to a traveler using a Chinese passport to apply for a short-term tourist >> visa at a U.S. embassy. In either approach, public-key identities from >> different identity trust domains are converted into manageable public-key >> identities within a single identity trust domain based on ACME PK-01, >> greatly reducing the administrative overhead of cross-domain >> interoperability. In this sense, ACME PK-01 also serves as an important >> tool with significant interoperability benefits. >> >> It was these two practical issues we encountered in our work that >> motivated us to start exploring the ACME PK‑01 extension, standardize it >> into a more general-purpose mechanism, we have been working on it since >> 2021. Beyond the examples above, we believe there are many other broad >> non‑Web application scenarios that can benefit from ACME PK‑01. Our >> ultimate goal is to extend ACME to all encryption use cases and achieve >> universal automation. >> >> Thank Aaron's suggestion that the CSR under the PK-01 challenge >> mechanism, enabling the ACME server to issue certificates directly upon >> successful public key verification. I agree with this. Thank David Adrian >> for his supporting comments at IETF 123 that Regardless of whether the >> client is trusted, we believe that binding the public key in the challenge >> is valuable. David also pointed out the use case of PKI resellers that need >> to binding the public key in the challenge. Personally, I am very fond of >> OPAQUE and frequently use it in practical deployments. The cryptography >> community also faces the challenge of promoting and applying PAKE in >> real-world scenarios. Therefore, I took the initiative to add >> OPAQUE-related content to this draft. >> >> We have spent considerable time discussing proof of private key >> possession in previous meetings. However, I do not believe this is our >> primary motivation. As I have tried to explain in this email, our main goal >> is functional, to advance ACME from server-side to client-side, Public key >> identity-centric automation of certificate issuance to users, security >> improvements as a welcome side effect. >> >> I second Mike’s point again. We have indeed included far too much in the >> current version. Perhaps in the next revision we should first focus on >> extending the basic PK‑01 mechanism before discussing other extensions and >> motivations. >> >> This email is also copied to the authors of RFC 9807. We welcome >> discussions and suggestions on use cases for integrating OPAQUE into ACME >> PK‑01. >> >> Best regards, >> Geng Feng >> >> >> 原始邮件 >> ------------------------------ >> 发件人：吴攀雨 <[email protected]> >> 发件时间：2026年3月8日 15:23 >> 收件人：Mike Ounsworth <[email protected]> >> 抄送：皮皮猪 <[email protected]>, 779788384 <[email protected]>, palos.chen < >> [email protected]>, Yoav Nir <[email protected]> >> 主题：Re: [Acme] Update to the draft-geng-acme-public-key-04 >> >> Hello Mike, >> >> Thank you very much for the detailed and thoughtful review of the draft. >> We really appreciate the time you spent reading it and providing such >> specific feedback. >> >> Your main point that the draft currently tries to address too many >> mechanisms and use cases is very helpful. We agree that the scope should >> likely be narrowed to make the proposal clearer and easier to evaluate >> within the ACME framework. >> >> Your comments regarding the motivation for proof-of-possession, the >> relationship with CSR, and the device / IoT use cases are particularly >> valuable. We will review these sections carefully and work on simplifying >> the document, likely by focusing on a more specific problem statement. >> >> We will attend IETF 125, and before that, we will update version 05 of >> the draft, providing more explanation on Opaque use cases and streamlining >> the use cases and mechanisms. >> Thank you again for the constructive feedback. >> >> Best regards, >> Grace >> >> Mike Ounsworth <*[email protected] <ounsworth%[email protected]>*> >> 于2026年3月7日周六 19:43写道： >> >> Hello Grace, >> >> I have reviewed your draft. I find the motivation is extremely confusing >> because I think this draft is trying to do way too much. I count four >> different mechanisms and use cases that this draft is trying to introduce: >> >> 1. Add two separate proof-of-possession checks: the normal CSR, and a >> second, independent, PoP check of the same key via a new ACME Challenge. >> The draft claims that this is a security improvement, but as I note below, >> I am not convinced that it is because I don't believe that "public key >> substitution attack" is a meaningful attack. >> >> 2. Authenticate with a client key such as one in WebAuthn or OPAQUE, and >> then issue a certificate for that key -- I don't understand the motivation >> for this because webauthn keys are dynamically-derived per-host and OPAQUE >> are password-based keys and really should not be reused outside of the >> webauthn or OPAQUE protocols, so I don't understand the value in issuing >> certificates for those keys, and in many cases may be dangerous to do so. I >> think this use case needs to be much further explained, or removed. >> >> 3. You mention using an existing certificate (for example, device >> manufacture certificate) to enroll in ACME. This seems like it could be a >> good goal, but then I think this is actually not supported by your proposed >> mechanism since in fact you only support self-signed certificates, so in >> fact maybe you don't support this use case? >> >> 4. Remove / replace the CSR from the ACME protocol. This has been >> discussed on-and-off for a long time, and I think that the: >> "identifier": { >> "type": "pk", >> "value":"MIGfMA0GC***GbQIDAQAB" >> } >> is a great proposal for this. >> >> >> Section "3.2.2. IoT and Device Enrollment" says: >> "While ACME identifier validation ensures control over an identifier >> (e.g., device domain name or device identifier)" >> But you have noted above that client devices that are not servers are not >> compatible with the http-01 or dns-01 challenge types, so I think this use >> case needs more explanation. >> >> Section 3.2.2 also says: >> "If private key ownership is not verified during the challenge phase, the >> device's identity integrity cannot be enforced." >> I don't understand what this is referring to. To me, a "device identity" >> is a serial number or equivalent. I don't understand how proving private >> key ownership does anything to prove device identity integrity. >> >> I have the same problem with Section 3.2.3: if you assume that some >> entity in the cross-domain ecosystem is malicious or compromised; I don't >> understand how asking for a second PoP (in addition to the existing >> self-signed CSR) does anything to help this situation. >> >> >> Section "4.1.1. Self-Signed Certificate Binding Mode" >> Having the certificate requester create a self-signed certificate >> containing the requested identifiers. Isn't that just a more complicated >> version of a CSR? >> >> Section "4.1.2. CSR Binding Mode" >> You want to add a second mechanism for carrying a CSR in the ACME >> protocol, in the order step instead of the usual finalize step? Why? >> >> >> I am not convinced that this draft offers any security improvement for >> the ACME protocol. >> The draft lists as one motivation that the CSR is not coupled to the ACME >> order, and therefore could be substituted by a malicious ACME Client acting >> as a proxy between the private key holder and the ACME Server. However, >> from my own research, I am not convinced that proof-of-key-possession is >> important for PKI security -- imagine you get a certificate with your name >> in the SANs and someone else's public key, so what? You can't use the >> certificate because you don't have the private key, so what bad thing can >> you do with that certificate? Also, if we are assuming a malicious or >> compromised ACME Client, why couldn't it substitute a public key that it >> does have the private key for? In that case, it could fully satisfy your >> new pk-01 challenge. And more generally, if we expand the ACME threat model >> to include a compromised or malicious ACME Client, then we will have much >> bigger security problems than proof-of-possession of the subscriber key. In >> summary, I am not convinced that this draft actually does increase the >> security of the ACME protocol because I am not convinced that "public key >> substitution attack" is a meaningful attack. >> >> I would like to use the discussion time during IETF 125 to have a >> discussion on whether proof-of-possession is actually valuable in ACME, or >> whether simply providing the subscriber public key in JSON (without that >> key ever performing a signature) would provide the same protocol security >> properties as we have today with the CSR. >> >> >> >> In summary, I think this draft is trying to cover way too many different >> use cases with many different mechanisms. This makes the draft complicated >> to read and think about. >> I say this as an individual, not as WG Chair: I think your draft would be >> significantly improved if you cut it down to only focus on one use case, >> for example removing / replacing the CSR in the ACME protocol, or issuing >> certificates to WebAuthn or OPAQUE keys. >> >> On Mon, 2 Mar 2026 at 23:06, 吴攀雨 <*[email protected] >> <[email protected]>*> wrote: >> >> Hi All, >> >> We have updated the draft-geng-acme-public-key-04, primarily adding >> supplementary information on the motivation, threat model, and practical >> application scenarios. >> >> abstract: >> This document implements automated certificate provisioning through >> "public key identity challenge + private key ownership verification" by >> introducing the pk-01 challenge to the ACME protocol. It serves as a >> valuable complement to existing external resource verification challenge >> types such as DNS/HTTP, extending the ACME protocol's applicability beyond >> Web-PKI to other scenarios. This enables automated certificate issuance for >> devices and accounts. The core design objective of this document's >> extension to ACME's pk-01 challenge is to introduce a trusted identity >> provider (IdP) during the digital certificate application process. This >> provider verifies the certificate applicant's identity and obtains the >> corresponding identity public key. It enables the ACME server to use public >> key identity authentication protocols (e.g., WebAuthn and Opaque) to verify >> whether the genuine application behind the ACME client controls the public >> key. It ensures strong consistency between the public key used during the >> challenge phase and the public key ultimately used to sign the certificate, >> preventing tampering with the public key during the CSR submission phase. >> This enhances the security of the digital certificate issuance process. >> Similar related work can be found in RFC9883. >> >> This document also defines an optional process extension that allows >> removal of the CSR under the pk-01 challenge, enabling the ACME server to >> issue a certificate directly after successful public key verification. >> >> This document provides an example of practical application at the end, >> illustrating the integration of the OPAQUE, strong asymmetric password >> authenticated key exchange (saPAKE) protocol with the pk-01 challenge. >> >> >> ----------------------------------------------------------------------------------------------------------------- >> Title: Automated Certificate Management Environment (ACME) Extension for >> Public Key Challenges >> Draft link: >> *https://www.ietf.org/archive/id/draft-geng-acme-public-key-04.html >> <https://www.ietf.org/archive/id/draft-geng-acme-public-key-04.html>* >> >> Thanks, >> Grace >> >> >> _______________________________________________ >> Acme mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] >> <[email protected]>* >> >> >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
