1. Introduction (Einführung)

1. Introduction (Einführung)

Traditionell werden öffentliche Schlüssel von TLS-Clients und -Servern in PKIX-Containern In-Band als Teil des TLS-Handshake-Verfahrens erhalten und unter Verwendung von Vertrauensankern (trust anchors) validiert, die auf einer [PKIX] Zertifizierungsstelle (CA) basieren. Diese Methode kann eine komplizierte Vertrauensbeziehung hinzufügen, die schwer zu validieren ist. Beispiele für eine solche Komplexität sind in [Defeating-SSL] zu sehen. TLS wird jedoch auch häufig mit selbstsignierten Zertifikaten (self-signed certificates) in kleineren Bereitstellungen verwendet, bei denen die selbstsignierten Zertifikate Out-of-Band (außerband) an alle beteiligten Protokollendpunkte verteilt werden. Diese Praxis erfordert jedoch immer noch den Overhead der Zertifikatserstellung, obwohl keine der im Zertifikat gefundenen Informationen tatsächlich verwendet wird.

Es stehen alternative Methoden zur Verfügung, die es einem TLS-Client/Server ermöglichen, den öffentlichen Schlüssel des TLS-Servers/-Clients zu erhalten:

• Der TLS-Client kann den öffentlichen Schlüssel des TLS-Servers aus einem DNSSEC-gesicherten Ressourcendatensatz unter Verwendung der DNS-basierten Authentifizierung benannter Entitäten (DANE) [RFC6698] erhalten.

• Der öffentliche Schlüssel des TLS-Clients oder -Servers wird aus einer [PKIX] Zertifikatskette von einem Lightweight Directory Access Protocol [LDAP] Server oder einer Webseite erhalten.

• Der öffentliche Schlüssel des TLS-Clients und -Servers wird im Firmware-Image des Betriebssystems bereitgestellt und über Software-Updates aktualisiert. Zum Beispiel:

  Einige intelligente Objekte (smart objects) verwenden das UDP-basierte Constrained Application Protocol [CoAP], um mit einem Webserver zu interagieren und Sensordaten in regelmäßigen Abständen hochzuladen, wie z. B. Temperaturmesswerte. CoAP kann DTLS zur Sicherung der Client-zu-Server-Kommunikation nutzen. Als Teil des Herstellungsprozesses kann das eingebettete Gerät mit der Adresse und dem öffentlichen Schlüssel eines dedizierten CoAP-Servers sowie einem öffentlichen/privaten Schlüsselpaar für den Client selbst konfiguriert werden.

Dieses Dokument führt die Verwendung von rohen öffentlichen Schlüsseln (raw public keys) in TLS/DTLS ein. Bei rohen öffentlichen Schlüsseln wird nur eine Teilmenge der Informationen verwendet, die in typischen Zertifikaten zu finden sind: nämlich die SubjectPublicKeyInfo-Struktur eines PKIX-Zertifikats, die die Parameter enthält, die zur Beschreibung des öffentlichen Schlüssels erforderlich sind. Andere in PKIX-Zertifikaten gefundene Parameter werden weggelassen. Durch das Weglassen verschiedener zertifikatsbezogener Strukturen bleibt der resultierende rohe öffentliche Schlüssel im Vergleich zum ursprünglichen Zertifikat recht klein, und der Code zur Verarbeitung der Schlüssel kann einfacher sein. Es wird nur ein minimalistischer ASN.1-Parser benötigt; Code für die Zertifikatspfadvalidierung und andere PKIX-bezogene Verarbeitung ist nicht erforderlich. Beachten Sie jedoch, dass die SubjectPublicKeyInfo-Struktur immer noch im ASN.1-Format vorliegt. Um die Größe der ausgetauschten Informationen weiter zu reduzieren, kann diese Spezifikation mit der TLS Cached Info-Erweiterung [CACHED-INFO] kombiniert werden, die es TLS-Peers ermöglicht, nur Fingerabdrücke ihrer öffentlichen Schlüssel auszutauschen.

Der hier definierte Mechanismus bietet nur dann eine Authentifizierung, wenn auch ein Out-of-Band-Mechanismus verwendet wird, um den öffentlichen Schlüssel an die Entität zu binden, die den Schlüssel präsentiert.

Section 3 definiert die Struktur der beiden neuen TLS-Erweiterungen, client_certificate_type und server_certificate_type, die als Teil eines erweiterten TLS-Handshakes verwendet werden können, wenn rohe öffentliche Schlüssel verwendet werden sollen. Section 4 definiert das Verhalten des TLS-Clients und des TLS-Servers. Beispielhafte Austausche werden in Section 5 beschrieben. Section 6 beschreibt Sicherheitsüberlegungen bei diesem Ansatz. Schließlich registriert dieses Dokument in Section 7 einen neuen Wert im IANA-Subregister "TLS Certificate Types" (TLS-Zertifikatstypen) für die Unterstützung von rohen öffentlichen Schlüsseln.