Hi all,
Due to the email restriction issue of Feng Geng, I am forwarding this email to
ACME.
---- Forwarded Message ----
From皮皮猪<[email protected]>Date03/08/2026 20:09 ToMike
Ounsworth<[email protected]>,
Yoav Nir<[email protected]>,
aaron<[email protected]> Cc779788384<[email protected]>,
palos.chen<[email protected]>,
吴攀雨<[email protected]>,
draft-geng-acme-public-key.authors<[email protected]>,
davidcadrian<[email protected]>,
acme<[email protected]>,
d<[email protected]>,
hugokraw<[email protected]>,
lewi.kevin.k<[email protected]>,
caw<[email protected]>SubjectRe: [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：
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.
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.
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.
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".
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]> 于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]> 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
Thanks,
Grace
_______________________________________________
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]
