Hi Richard, Hi Mike, Hi Yoav, Hi Aaron
First thanks again.
Based on the consensus on IETF125, before starting IDP/Opaque-01, I thought
about the motivation and value of this draft again.
Before that, I have seen exist experimental draft
(acme-service-provider/acme-token-challenge/acme-sso etc). I like the ideas
behind these drafts, So I'm curious about why acme wg haven't continued to
explore the automation certificate requirements in the enterprise
communication/collaboration? Especially after the popularization of E2EE, shift
the focus of ACME challenge verification from domain name/identifier to public
key identity.
In my opinion, 1) although the mainstream business architecture has been
completely cloudized, it still retains a number of OnPrems, most of which are
still traditional SIP stacks. 2) to people, the Internet is moving towards
end-to-end security, from E2EE to E2EP(privacy), Decentralised or distributed,
they don't need a certificate(or anonymous certificates) to identify themselves
but with temporary public key by Signal or MLS with transparency. 3) 2B,
whatever OnPrems or cloud based, there is a centralised ID trust anchor in the
enterprise, and it is natural to think of the architecture of IdP+ACME+CA,
let's E2E authenticate based on Certificate, register an enterprise account
(long-term or temporary) first, and then obtain a authorisation certificate
(long-term or temporary), access the enterprise network, access enterprise
services (zero trust) or conduct meetings and communication with other
enterprise users (E2EE).
So I ask and initiate a discussion:
1) In addition to the rfc8555 Web-PKI framework (proof domain
name/identifier), is there need another IdP+ACME+CA framework for non Web-PKI
(automatically issuing certificates to device or people under the
guarantee of authoritative identity trust anchor)？ Different from the previous
draft, it mainly proves the identity of the public key.
2) If IDP/Opaque-01 had the motivation and value, issuing temporary or
anonymous certificates to people (the retrieve func of Opaque makes it
unnecessary for people to carry their private keys). Whether it has enough
other universal scenarios and standardised value？
3) IETF MIMI WG is solving the problem of encryption interoperability on the
Internet. So does our ACME WG also need to try to solve the interoperability
problem of cross-domain certificates between different enterprises?
Best regards,
GengFeng
原始邮件
发件人：吴攀雨 <[email protected]>
发件时间：2026年4月2日 22:15
收件人：IETF ACME <[email protected]>
抄送：[email protected]
<[email protected]>
主题：[Acme] Update: draft-geng-acme-public-key-05
Hi all,
We’ve just published an updated version of the draft:
https://www.ietf.org/archive/id/draft-geng-acme-public-key-05.html
Thanks again for all the valuable feedback and discussions during IETF 125 —
especially thanks to Aaron Gable, Ilari Liusvaara, David Benjamin,
Richard Barnes, and others for the insightful comments.
Here’s a summary of the main changes from -04 to -05:
1. Challenge type consolidation
The six challenge types in -04 (pk-dns-01, pk-http-01, pk-tls-alpn-01,
pk-email-01, pk-csr-01, pk-cert-01) are now unified into a single pk-01
challenge. Delivery is negotiated via supported_delivery / delivery fields in
the challenge object.
2. newOrder restructuring
The pk_binding object has been split into three top-level fields:
public_key (SPKI), pop_mode ("async" / "sync"), and csr_less.
3. Unified PoP signing formula
All delivery methods now use a consistent signature construction with domain
separation and identifier binding:
to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier
4. New ALPN identifier “acme-pk/1”
Defined a new TLS ALPN protocol identifier independent of RFC 8737
(“acme-tls/1”).
In sync mode, the TLS handshake directly returns the raw proof bytes as
application data, without requiring a self-signed X.509 certificate with the
acmeValidation extension. An IANA registration has been requested per RFC 7301.
5. Security enhancements
Added defenses against:
•Unknown Key Share (UKS) via identifier binding
•Cross-protocol attacks via “ACME-pk-01\x00” domain separation
•Authorization reuse via SPKI-level binding checks
6. Post-quantum (PQC) considerations
Added motivation for PQC transition. Noted that PQ signatures may exceed DNS
TXT limits, and recommend using sync mode (pop_mode: "sync", TLS-ALPN delivery)
for PQ scenarios.
7. Removal of IdP-based authentication mode
Removed non-Web PKI IdP-based authentication (pk-csr-01, pk-cert-01) and
related WebAuthn/OPAQUE integration. These will be addressed in a separate
document following prior feedback.
As always, comments and feedback are very welcome!
Best regards,
Grace_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
