Zum Hauptinhalt springen

RFC 8555 Kapitel 9–12 Zusammenfassung

Hinweis: Dieses Dokument enthält eine Zusammenfassung der wichtigsten Punkte aus den Kapiteln 9–12 von RFC 8555. Vollständige technische Details finden Sie im offiziellen RFC-8555-Dokument.

9. IANA Considerations (IANA-Überlegungen)​

9.1 Medientypregistrierung​

  • application/pem-certificate-chain: PEM-Format für Zertifikatsketten

9.2 Well-Known URI​

  • /.well-known/acme-challenge: Standardpfad für HTTP-Herausforderungen

9.3 HTTP-Headerfelder​

  • Replay-Nonce: Anti-Replay-Nonce-Headerfeld

9.4–9.5 JWS-Headerparameter​

  • url: URL-Parameter im JWS
  • nonce: Nonce-Parameter im JWS

9.6 URN-Namensraum​

  • urn:ietf:params:acme: URN-Namensraum für das ACME-Protokoll

9.7 Neue Register​

IANA hat für ACME die folgenden Register erstellt:

  1. Account Object Fields (Kontoobjektfelder)
  2. Order Object Fields (Bestellungsobjektfelder)
  3. Authorization Object Fields (Autorisierungsobjektfelder)
  4. Error Types (Fehlertypen)
  5. Resource Types (Ressourcentypen)
  6. Directory Metadata Fields (Verzeichnis-Metadatenfelder)
  7. Identifier Types (Identifikatortypen)
  8. Validation Methods (Validierungsmethoden)

10. Security Considerations (Sicherheitsüberlegungen)​

10.1 Bedrohungsmodell​

Die zwei wichtigsten Sicherheitsziele von ACME:

  1. Nur die Entität, die einen Identifikator kontrolliert, kann eine Autorisierung für diesen Identifikator erhalten.
  2. Nach der Autorisierung kann die Autorisierung eines Kontoschlüssels nicht von einem anderen Konto missbräuchlich verwendet werden.

Kommunikationskanäle:

  • ACME-Kanal: HTTPS-Anforderungen zwischen Client und Server
  • Validierungskanal: Der Kanal, über den der Server Validierungsabfragen durchführt

10.2 Integrität der Autorisierung​

Schlüsselbindung: Alle Herausforderungen binden den privaten Kontoschlüssel über Schlüsselautorisierungen an die Validierungsabfrage.

Mögliche Angriffe:

  • MitM-Angriffe: CDNs oder Reverse-Proxys können als Man-in-the-Middle fungieren
  • DNS-Angriffe: Angreifer können die Validierung durch DNS-Hijacking beeinflussen
  • Risiken durch Hosting-Anbieter: Hosting-Dienstanbieter könnten die Validierung manipulieren

Schutzmaßnahmen:

  • Verwendung von DNSSEC-validierenden Resolvern
  • DNS-Abfragen von mehreren Netzwerkstandorten aus
  • Anwendung von DNS-Schutzmaßnahmen (z. B. DNS0x20)

10.3 Denial-of-Service-Überlegungen​

CAs SOLLTEN implementieren:

  • Ratenbegrenzung
  • Ressourcenkontingente
  • Zeitüberschreitungseinstellungen für Validierungsabfragen

10.4 Server-Side Request Forgery (SSRF)​

HTTP-01-Herausforderungen können für SSRF-Angriffe missbraucht werden. CAs SOLLTEN:

  • Private IP-Adressen ablehnen
  • Weiterleitungen einschränken
  • Angemessene Zeitüberschreitungen festlegen

10.5 CA-Richtlinienüberlegungen​

CAs SOLLTEN Richtlinien zu folgenden Aspekten festlegen:

  • Auswahl der Validierungsmethoden
  • Zertifikatsgültigkeitsdauer
  • Widerrufsbedingungen

11. Operational Considerations (Betriebliche Überlegungen)​

11.1 Schlüsselauswahl​

Empfohlene Schlüsseltypen:

  • ECDSA P-256 oder P-384
  • RSA 2048 Bit oder höher

11.2 DNS-Sicherheit​

Bei Verwendung von DNS-01-Herausforderungen:

  • DNS-Infrastruktur absichern
  • Einsatz von DNSSEC in Betracht ziehen
  • DNS-Verwaltungsschnittstellen schützen

11.3 Token-Entropie​

Herausforderungstoken MÜSSEN ausreichend Entropie aufweisen:

  • Mindestens 128 Bit Entropie
  • Kryptografisch sicheren Zufallszahlengenerator verwenden

11.4 Fehlerhafte Zertifikatsketten​

Clients SOLLTEN:

  • Die Integrität heruntergeladener Zertifikatsketten überprüfen
  • Die Gültigkeitsdauer von Zertifikaten prüfen
  • Den Vertrauenspfad der Zertifikatskette validieren

12. References (Referenzen)​

12.1 Normative Referenzen (Auswahl)​

  • RFC2119: Schlüsselwortdefinitionen (MUST, SHOULD, MAY usw.)
  • RFC5280: X.509-Zertifikate und CRL-Profil
  • RFC7515: JSON Web Signature (JWS)
  • RFC7518: JSON Web Algorithms (JWA)
  • RFC8259: JSON-Datenformat
  • RFC2818: HTTPS
  • RFC3339: Datums- und Zeitformat
  • RFC7807: Problemdetails für HTTP-APIs

12.2 Informative Referenzen (Auswahl)​

  • RFC3552: Leitfaden für Sicherheitsüberlegungen in Internetprotokollen
  • RFC6844: DNS Certification Authority Authorization (CAA) Resource Record
  • RFC7525: Empfehlungen für die sichere Verwendung von TLS und DTLS

Anhang​

Acknowledgements (Danksagungen)​

Die Entwicklung von RFC 8555 wurde durch Beiträge zahlreicher Mitglieder der IETF-Community ermöglicht.

Authors' Addresses (Autorenanschriften)​

Hauptautoren:

  • Richard Barnes (Cisco)
  • Jacob Hoffman-Andrews (EFF)
  • Daniel McCarney (Let's Encrypt)
  • James Kasten (University of Michigan)

Verwandte Ressourcen​

Letztes Update am