Zusammenfassung

  • Die ACME-Arbeitsgruppe übermittelte draft-ietf-acme-profiles-02 am 21. September 2026 an die IESG. „Publication Requested“ ist weder IESG-Genehmigung noch RFC-Veröffentlichung.
  • newOrder.profile verschiebt die Merkmalswahl in den Auftrag. Anzeige, Kontoberechtigung, Auftragsannahme, Finalisierung und tatsächlicher Einsatz bleiben dennoch getrennte Belege.

Automatisierung bevorzugt einen stabilen Schlüssel. Genau einen solchen liefert der neue Profilname. Gefährlich wird er erst, wenn aus dem Schlüssel eine Zusage abgeleitet wird: gleiche Zeichenfolge, gleiche Bedeutung, gleiche Berechtigung und gleiches Zertifikat.

Der Entwurf beschreibt selbst drei unterschiedliche Fälle. Ein Profil kann aktuell angekündigt sein. Ein nicht angekündigtes privates Profil kann ausnahmsweise angenommen werden. Ein bei Auftragserstellung akzeptiertes Profil kann bei finalize mit invalidProfile scheitern. Die richtige Schlussfolgerung ist daher nicht, den Namen zu ignorieren, sondern seinen Kontext zu protokollieren.

Verfahrensstand ohne Überhöhung

Am 21. September wechselte der Datatracker-Status von Working Group Last Call zu „Submitted to IESG for Publication“. Auf IESG-Seite steht „Publication Requested“, als zuständige Area Director ist Deb Cooley genannt, ein Telechat-Termin fehlt. Mike Ounsworth stellte den Antrag im Namen der Arbeitsgruppe.

Revision 02 zielt auf Proposed Standard, bleibt aber ein Internet-Draft. Das Shepherd Write-up spricht von schwachem Konsens: Die Erweiterung galt als einfach, und nur wenige Antworten unterstützten sie ausdrücklich; Streit oder Berufung werden nicht berichtet. Genannte Implementierungen und der Einsatz bei Let’s Encrypt belegen begrenzte Betriebserfahrung, keine flächendeckende Einführung.

Was sich im ACME-Ablauf verschiebt

Nach RFC 8555 wird zunächst ein Auftrag angelegt und später am finalize-Endpunkt der CSR eingereicht. Der Entwurf ergänzt das Directory um ein optionales Objekt profiles. Seine Schlüssel sind kurze, für den Server eindeutige Bezeichner; die Werte verweisen auf menschenlesbare Beschreibungen, auch als Data-URL.

Der Client kann den Namen in newOrder.profile senden. Bei Annahme gibt das Order-Objekt ihn zurück. Die Merkmalswahl liegt damit vor dem CSR, während dieser öffentlichen Schlüssel und subjectAltName trägt. Der Entwurf erwartet dadurch weniger ASN.1-Parsing und Kopieren in der CA-Policy.

Kontoverwaltung und Identifikatorvalidierung ändern sich nicht. Ebenso wenig entsteht ein globales Namensregister. Ein Profil erhält seine Bedeutung durch den konkreten Directory-Endpunkt, dessen Beschreibung und den Zeitpunkt der Abfrage.

Sichtbarkeit ist nicht Berechtigung

Ist das Profil mit dem Auftrag unvereinbar, muss der Server invalidProfile liefern. Als Beispiele nennt der Text ein TLS-Serverprofil mit E-Mail-Identifikator sowie ein Konto außerhalb einer Profil-Allowlist. Eine sichtbare Bezeichnung ist folglich noch keine Nutzungsberechtigung.

Umgekehrt ist Unsichtbarkeit nicht ausnahmslos Ablehnung. Client und Server sollen nicht angekündigte Namen normalerweise vermeiden. Der Server darf sie aber in Ausnahmefällen annehmen, etwa für ein außerhalb des Protokolls vereinbartes privates Profil oder für den Ersatz eines alten Zertifikats nach einer Massenwiderrufung.

Sendet der Client keinen Namen, wird dem Server empfohlen, selbst ein Profil zu wählen und dem Auftrag zuzuordnen. Nicht nur die Anfrage, sondern auch die Order-Antwort gehört deshalb in die Akte.

Selbst ein angenommener Auftrag garantiert die Ausstellung nicht. Ist die CA bei der Finalisierung nicht mehr bereit, nach dem Profil auszustellen, muss sie invalidProfile melden. Der Entwurf empfiehlt, bestehende Aufträge vor einer Einstellung auslaufen zu lassen, hält den Fehlerpfad aber ausdrücklich offen.

Zeit gehört zur Semantik

Let’s Encrypt bezeichnet das aktuelle Directory als maßgebliche Liste und weist auf Unterschiede zwischen Umgebungen sowie Allowlist-Beschränkungen hin. classic, tlsserver und shortlived unterscheiden sich bei Wiederverwendung von Autorisierungen, Auftrags- und Zertifikatslaufzeit, Identifikatortypen und Zertifikatsfeldern.

tlsclient ist seit dem 8. Juli 2026 nicht mehr verfügbar. tlsserver wechselte am 13. Mai zu 45-Tage-Zertifikaten; für classic sind weitere Verkürzungen geplant. Diese Daten zeigen die Entwicklung eines Betreibers. Sie definieren keine Bedeutung für andere CAs.

Eine prüfbare Kette statt eines starken Etiketts

Zu speichern sind zunächst rohe Directory-Antwort, URL und Abrufzeit. Es folgen Beschreibungs-URL und Hash des gelesenen Inhalts. Danach werden CA-Endpunkt, Konto, Identifikatoren, angeforderter Name, Berechtigungsentscheidung und Order-Antwort mit zurückgegebenem Profil verbunden.

Für finalize braucht es CSR-Fingerabdruck, Antwortstatus und möglichen ACME-Problemtyp. Nach Ausstellung belegen Zertifikatsfingerabdruck und analysierte Eigenschaften das signierte Ergebnis. Soll auch der Einsatz nachgewiesen werden, ist eine eigene Beobachtung des produktiven Dienstes erforderlich.

Directory ist kein Anspruch, Order kein Zertifikat und Zertifikat keine Einsatzbestätigung. Wer diese Ebenen trennt, kann den Profilnamen als wertvollen Join-Key nutzen, ohne ihn zum unbelegten Vertrag zu machen.

Quellen

  1. Aktueller Datatracker-Stand
  2. Dokumenthistorie
  3. draft-ietf-acme-profiles-02
  4. Publikationsantrag
  5. Shepherd Write-up
  6. RFC 8555
  7. Profil-Dokumentation von Let’s Encrypt
  8. Ankündigung von ACME Profiles
  9. Fahrplan für Zertifikatslaufzeiten
  10. Ankündigung des Working Group Last Call
  11. Abschluss des Working Group Last Call
  12. Boulder-Implementierungstracker
  13. ACME-Protokoll der IETF 126