I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

The summary of the review is Ready With Nits

My concern remains with the privacy risks of CT logs with onion
services.  CT aims to improve TLS security but creates tensions with the
anonymity expected from onion services.  So let me suggest some possible
mitigation text for the Security Considerations section without fully
understanding ACME or Tor.

Use short-lived certificates: Request certificates with a short validity
period, such as 90 days or less. This reduces the window of exposure in
CT logs. You'll need to renew certificates more frequently, but it
limits the privacy impact.

Avoid unnecessary certificate requests: Only request publicly-trusted
certificates for onion services that truly need them, such as those
serving websites to the general public (e.g. SecureDrop or news
outlets). For internal or non-public services, consider using
self-signed or privately-trusted certificates that don't get logged to
public CT.

Use a separate domain/key pair: Register a distinct .onion address for
the specific purpose of obtaining a certificate, instead of using your
primary service's domain. This separates the publicly logged certificate
from your main onion service.

Obfuscate subscriber information: When requesting certificates, provide
minimal or obfuscated subscriber details to the CA if possible, such as
a pseudonymous email address or entity name. The CA/Browser Forum
Baseline Requirements allow some flexibility here.  But obfuscating
subscriber info with pseudonyms only reduces casual exposure but doesn't
guarantee anonymity, as CAs likely keep records mapping pseudonyms to
real identities.

Monitor CT logs: Proactively monitor CT logs for certificates issued for
your onion domain(s). This can help detect any mis-issuance or
unauthorized certificates. Some CAs and third-party services offer CT
monitoring.

Use ACME account key privacy: When using ACME, generate a new account
key pair for each .onion domain and avoid re-using keys across
domains. This reduces the ability to correlate multiple domains to a
single owner based on account keys.

Private certificate authorities: For clusters of related onion services,
consider setting up a private CA that isn't constrained by the CT
logging requirement of public trust. This avoids any exposure in public
CT logs.  Obvoiusly this is only viaable for larger onion service
deployments given the additional technical overhead.  They aren't
feasible for all clusters of related services.

Inform .onion Operators of CT Risks: ACME clients targeting .onion
domains should include explicit warnings about CT logging implications
to ensure operators make informed decisions.

CT Exemption Advocacy: Advocate for discussions within the CA/Browser
Forum on potential CT exemptions for .onion services, given their unique
anonymity requirements. This could be accompanied by alternative
transparency mechanisms tailored to .onion ecosystems.

Exploration of Private CT Logs: Research and development into private CT
logs or trusted third-party logging mechanisms for .onion services may
offer a compromise between transparency and privacy.