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]
