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]
