Summary

  • The ACME working group submitted draft-ietf-acme-profiles-02 to the IESG on 21 September 2026. Its state is Publication Requested, not IESG approval or RFC publication.
  • The extension moves certificate-feature selection into newOrder.profile, but the protocol deliberately permits local advertisement, private exceptions, eligibility checks and later invalidProfile failure. A profile name is therefore a selector, not an issuance receipt.

Imagine three orders carrying the same short profile name. In the first, the name appears in the CA’s current ACME Directory. In the second, it is absent there but accepted under a private agreement. In the third, the server accepted it when the order was created, then returns invalidProfile at finalization because the CA is no longer willing to issue under it.

All three paths fit the proposed ACME Profiles extension. That is its operational strength: the protocol gives clients and servers a clean control for certificate features without pretending that every policy decision is static or public. It is also the reason an operator cannot treat the name alone as proof of what was authorized, completed or deployed.

A publication request, not a finished standard

On 21 September, the ACME working group moved revision 02 from Working Group Last Call to “Submitted to IESG for Publication.” The IESG state is “Publication Requested,” the intended status is Proposed Standard, Deb Cooley is the responsible Area Director and no telechat date is listed. Document shepherd Mike Ounsworth sent the publication request after the working-group last call passed.

That record is a procedural milestone. It is not an IESG approval and the draft is not an RFC. The shepherd write-up describes weak consensus: the extension was considered simple and received few responses strongly in favor, with no reported controversy or appeal. The draft also lists implementations and says Let’s Encrypt has deployed the mechanism. Those are useful implementation signals, not evidence of industry-wide adoption.

What moves from finalization to the order

Under RFC 8555, an ACME client creates an order and later submits a certificate signing request at finalize. The draft adds an optional profiles object to Directory metadata. Each key is a short profile identifier; each value is a URL containing a human-readable description. A data URL is allowed.

The client may put a profile string in newOrder. If the server accepts it, the returned Order echoes the selected name. Feature selection therefore occurs before the CSR. The draft’s security analysis says this can simplify CA policy and reduce ASN.1 parsing and copying because the CSR can remain focused on the public key and subjectAltName.

The extension does not replace account management or identifier validation. Nor does it define one global vocabulary of profile names. The Directory is an endpoint-specific advertisement, and the description URL supplies prose rather than a cryptographically versioned semantics object.

Selection, eligibility and completion are separate decisions

The draft requires a server to return invalidProfile when the requested profile is incompatible with the order. Its examples include asking for a TLS server-authentication profile with an email identifier, or using an account that is not permitted by a profile allowlist.

That means seeing a name and selecting it do not establish account eligibility. The Directory can describe an available product surface while policy still decides which accounts and identifiers may use it.

Advertisement is also not a complete allowlist. A client should not request a name that the Directory does not advertise, and the server should reject it. Yet the server may accept it in exceptional cases. The draft names a private profile agreed out of band and replacement of a legacy certificate after mass revocation as examples. An audit that records only the Directory would miss a valid private path; one that records only the accepted name would miss why it was permitted.

Omission is not neutral either. If the client sends no profile, a server implementing the extension is recommended to choose and associate one. The Order response, rather than the request alone, becomes the evidence of which selector governed the order.

Finally, acceptance is not completion. If the CA becomes unwilling to issue under the profile before finalization, it must return invalidProfile. The draft recommends avoiding this outcome by letting existing orders expire before discontinuing a profile, but still defines the failure because policy and availability can change during the order’s life.

A name belongs to its operating context

Let’s Encrypt’s current profile documentation makes this locality concrete. It tells clients to use the current Directory endpoint as the canonical list and notes that profiles can differ between staging and production or be restricted by an allowlist. Its published profiles have different authorization reuse periods, order lifetimes, certificate lifetimes, identifier types and certificate fields.

Availability and meaning also evolve. Let’s Encrypt says its former tlsclient profile has been unavailable since 8 July 2026. It moved tlsserver to 45-day certificates on 13 May 2026 and has published later lifetime changes planned for classic. This is evidence about one operator’s names and schedule. It does not show that another CA uses the same names, or that any shared name has identical semantics.

For automation, the practical conclusion is narrower and more useful: profile names should be scoped to the Directory URL, retrieval time and account context. A configuration entry such as tlsserver is not self-describing once detached from those facts.

Keep the evidence chain in layers

A defensible issuance record starts with the Directory response bytes and retrieval time. It then preserves the profile-description URL and a hash of the content reviewed at that time. These two records show what the endpoint advertised and what its human-readable description said; neither proves that a specific account was eligible.

The next layer records the CA endpoint, account reference, requested name and identifiers, followed by the server’s eligibility result and the Order response with its echoed profile. A distinct finalization record keeps the CSR fingerprint, response status and any ACME problem type. If issuance succeeds, the certificate fingerprint and parsed properties establish what the CA actually signed.

Deployment is yet another event. A certificate can be issued without being installed on the intended service. Where deployment matters, observation of the live certificate belongs in its own record with time, vantage point and fingerprint.

This chain avoids two opposite errors. It does not promote an advertisement into an entitlement. It also does not erase private or time-dependent behavior that the draft expressly permits. The profile name remains valuable—as a stable join key inside one recorded transaction—without being asked to carry more authority than the protocol gives it.

Sources

  1. IETF Datatracker: ACME Profiles current state
  2. IETF Datatracker: document history
  3. Draft text: draft-ietf-acme-profiles-02
  4. Publication request to the ACME list
  5. Document shepherd write-up
  6. RFC 8555: Automatic Certificate Management Environment
  7. Let’s Encrypt profile documentation
  8. Let’s Encrypt: ACME Profiles announcement
  9. Let’s Encrypt certificate-lifetime roadmap
  10. ACME Working Group Last Call announcement
  11. Working Group Last Call conclusion
  12. Boulder implementation tracker
  13. IETF 126 ACME minutes