In der Geheimschrift ist X.509 ein ITU-T Standard für eine öffentliche Schlüsselinfrastruktur (PKI) und Privilege Management Infrastructure (PMI). X.509, gibt unter anderen Dingen, Standardformaten für öffentliche Schlüsselzertifikate, Zertifikat-Revokationslisten, Attribut-Zertifikate und einen Zertifikat-Pfad-Gültigkeitserklärungsalgorithmus an.

Geschichte und Gebrauch

X.509 wurde am 3. Juli 1988 am Anfang ausgegeben und wurde in Verbindung mit dem X.500 Standard begonnen. Es nimmt ein strenges hierarchisches System von Zertifikat-Behörden (CAs) an, für die Zertifikate auszugeben. Das hebt sich vom Web von Vertrauensmodellen wie PGP ab, wo jeder (nicht nur spezieller CAs) unterzeichnen und so für die Gültigkeit der Schlüsselzertifikate der anderen zeugen kann. Die Version 3 von X.509 schließt die Flexibilität ein, um andere Topologien wie Brücken und Ineinandergreifen (RFC 4158) zu unterstützen. Es kann in einem Gleicher-zu-Gleicher-, OpenPGP ähnlichen Web des Vertrauens verwendet werden, aber wurde dieser Weg bezüglich 2004 selten verwendet. Das X.500 System ist nur jemals von souveränen Nationen für die Zustandidentitätsinformation durchgeführt worden, die Vertrag-Erfüllungszwecke und die Infrastruktur des Öffentlichen Schlüssels des IETF (X.509) oder PKIX teilt, Arbeitsgruppe hat den Standard an die flexiblere Organisation des Internets angepasst. Tatsächlich bezieht sich der Begriff X.509 Zertifikat gewöhnlich auf das PKIX Zertifikat des IETF und CRL Profil des Zertifikat-Standards von X.509 v3, der so in RFC 5280, allgemein angegeben ist, verwiesen auf wie PKIX für die Öffentliche Schlüsselinfrastruktur (X.509).

Zertifikate

Im X.509 System gibt eine Zertifikat-Autorität ein Zertifikat aus, das einen öffentlichen Schlüssel zu einem besonderen ausgezeichneten Namen in der X.500 Tradition, oder zu einem alternativen Namen wie eine E-Mail-Adresse oder ein DNS-Zugang bindet.

Vertraute Wurzelzertifikate einer Organisation können allen Angestellten verteilt werden, so dass sie die Gesellschaft PKI System verwenden können. Browser wie Internet Explorer, Netscape/Mozilla, Oper, Safari und Chrom kommen mit vorinstallierten Wurzelzertifikaten, so werden SSL Zertifikate von größeren Verkäufern sofort arbeiten; tatsächlich bestimmen die Entwickler der Browser, welche CAs vertraute Dritte für die Benutzer der Browser sind.

X.509 schließt auch Standards für Durchführungen der Zertifikat-Revokationsliste (CRL), einen häufig verwahrlosten Aspekt von PKI Systemen ein. Die IETF-genehmigte Weise, eine Gültigkeit eines Zertifikats zu überprüfen, ist Online Certificate Status Protocol (OCSP). Firefox 3 ermöglicht OCSP, der standardmäßig zusammen mit Versionen von Windows einschließlich der Aussicht und später überprüft.

Struktur eines Zertifikats

Die durch die Standards vorausgesehene Struktur wird auf einer formellen Sprache, nämlich Abstrakte Syntax-Notation Ein ausgedrückt.

Die Struktur von X.509 v3 Digitalzertifikat ist wie folgt:

• Zertifikat
• Version
• Seriennummer
• Algorithmus-Personalausweis
• Aussteller
• Gültigkeit
• Nicht vorher
• Nicht danach
• Thema
• Unterwerfen Sie öffentliches Schlüsselinfo
• Öffentlicher Schlüsselalgorithmus
• Unterwerfen Sie öffentlichen Schlüssel
• Aussteller einzigartiger Bezeichner (fakultativer)
• Unterwerfen Sie einzigartigen Bezeichner (fakultativer)
• Erweiterungen (fakultativer)
• ...
• Zertifikat-Unterschrift-Algorithmus
• Zertifikat-Unterschrift

Jede Erweiterung hat seinen eigenen id, ausgedrückt als Gegenstand-Bezeichner, der eine Reihe von Werten zusammen entweder mit einer kritischen oder mit nichtkritischen Anzeige ist. Ein Zertifikat verwendendes System MUSS das Zertifikat zurückweisen, wenn es auf eine kritische Erweiterung stößt, die es, oder eine kritische Erweiterung nicht anerkennt, die Information enthält, die es nicht bearbeiten kann. Eine nichtkritische Erweiterung KANN ignoriert werden, wenn sie nicht anerkannt wird, aber bearbeitet werden MUSS, wenn sie anerkannt wird.

Die Struktur der Version 1 wird RFC 1422 gegeben.

ITU-T hat Aussteller vorgestellt, und unterwerfen Sie einzigartige Bezeichner in der Version 2, um zu erlauben, dass der Wiedergebrauch des Ausstellers oder Themas nach einer Zeit nennt. Ein Beispiel des Wiedergebrauchs wird sein, wenn ein CA Bankrott macht und sein Name von der öffentlichen Liste des Landes gelöscht wird. Nach einer Zeit kann ein anderer CA mit demselben Namen sich einschreiben, wenn auch es zum ersten ohne Beziehung ist. Jedoch empfiehlt IETF, dass kein Aussteller und unterworfene Namen wiederverwendet werden. Deshalb wird Version 2 im Internet nicht weit aufmarschiert.

Erweiterungen wurden in der Version 3 eingeführt. Ein CA kann Erweiterungen verwenden, um ein Zertifikat nur zu einem spezifischen Zweck (z.B auszugeben, um nur Digitalgegenstand zu unterzeichnen). Jede Erweiterung kann kritisch oder nichtkritisch sein. Wenn eine Erweiterung kritisch ist und das System, das das Zertifikat bearbeitet, die Erweiterung nicht anerkennt oder sie nicht bearbeiten kann, MUSS das System das komplette Zertifikat zurückweisen. Eine nichtkritische Erweiterung kann andererseits ignoriert werden, während das System den Rest des Zertifikats bearbeitet.

In allen Versionen MUSS die Seriennummer für jedes Zertifikat einzigartig sein, das durch einen spezifischen CA (wie erwähnt, in RFC 2459) ausgegeben ist.

Erweiterungen, die einen spezifischen Gebrauch eines Zertifikats informieren

RFC 5280 (und seine Vorgänger) definiert mehrere Zertifikat-Erweiterungen, die anzeigen, wie das Zertifikat verwendet werden sollte. Die meisten von ihnen sind Kreisbogen vom OID. Einige der allgemeinsten, definierten im Abschnitt 4.2.1, sind:

• Grundlegende Einschränkungen werden verwendet, um anzuzeigen, ob das Zertifikat einem CA gehört.
• Schlüsselgebrauch stellt einem bitmap das Spezifizieren der kryptografischen Operationen zur Verfügung, die mit dem öffentlichen im Zertifikat enthaltenen Schlüssel durchgeführt werden können; zum Beispiel konnte es anzeigen, dass der Schlüssel für Unterschriften, aber nicht für encipherment verwendet werden sollte.
• Verlängerter Schlüsselgebrauch wird normalerweise auf einem Blatt-Zertifikat verwendet, um den Zweck des öffentlichen im Zertifikat enthaltenen Schlüssels anzuzeigen. Es enthält eine Liste von OIDs, von denen jeder einen erlaubten Gebrauch anzeigt. Zum Beispiel, zeigt an, dass der Schlüssel auf dem Server-Ende eines TLS oder SSL Verbindung verwendet werden kann; zeigt an, dass der Schlüssel verwendet werden kann, um E-Mail zu sichern.

Im Allgemeinen, wenn ein Zertifikat mehrere Erweiterungen hat, die seinen Gebrauch einschränken, müssen alle Beschränkungen für einen gegebenen Gebrauch zufrieden sein, um passend zu sein. RFC 5280 führt das spezifische Beispiel eines Zertifikats an, das sowohl keyUsage als auch extendedKeyUsage enthält: In diesem Fall müssen beide bearbeitet werden, und das Zertifikat kann nur verwendet werden, wenn beide Erweiterungen im Spezifizieren des Gebrauchs eines Zertifikats zusammenhängend sind. Zum Beispiel verwendet NSS beide Erweiterungen, um Zertifikat-Gebrauch anzugeben.

Zertifikat-Dateiformate

Allgemeine Dateiformate für X.509 Zertifikate sind:

• - (Gemütlichkeit Erhöhte Post) Base64 hat DER Zertifikat verschlüsselt, eingeschlossen zwischen "-----BEGINNEN ZERTIFIKAT-----" und "-----ENDZERTIFIKAT-----"

• - gewöhnlich in der binären DER-Form, aber den Base64-verschlüsselten Zertifikaten sind auch üblich (sieh oben)

• - PKCS#7 Struktur von SignedData ohne Daten, gerade Zertifikat (E) oder CRL (s)

• - PKCS#12, kann Zertifikat (E) (öffentliche) und private Schlüssel (Kennwort geschützt) enthalten

• - PFX, Vorgänger PKCS#12 (enthält gewöhnlich Daten in PKCS#12 Format z.B mit PFX Dateien, die in IIS erzeugt sind)

PKCS#7 ist ein Standard für das Unterzeichnen oder encrypting (offiziell genannt "das Einschlagen") Daten. Da das Zertifikat erforderlich ist, um unterzeichnete Daten nachzuprüfen, ist es möglich, sie in die Struktur von SignedData einzuschließen. Eine Datei ist eine degenerierte Struktur von SignedData ohne irgendwelche Daten, um zu unterzeichnen.

PKCS#12 entwickelt vom persönlichen Informationsaustausch (PFX) Standard und wird verwendet, um öffentliche und private Gegenstände in einer einzelnen Datei auszutauschen.

X.509 Beispielzertifikate

Das ist ein Beispiel eines decodierten X.509 Zertifikats für, erzeugt mit OpenSSL — das wirkliche Zertifikat ist ungefähr 1 Kilobyte in der Größe. Es wurde von Thawte (da erworben von VeriSign), wie festgesetzt, im Aussteller-Feld ausgegeben. Sein Thema enthält viele persönliche Details, aber der wichtigste Teil ist gewöhnlich die gemeinsame Bezeichnung (CN), wie das der Teil ist, der den Gastgeber vergleichen muss, der wird beglaubigt. Auch eingeschlossen ist ein RSA öffentlicher Schlüssel (Modul und öffentliche Hochzahl), gefolgt von der Unterschrift, die durch die Einnahme eines MD5 Kuddelmuddels des ersten Teils des Zertifikats und das Unterzeichnen davon (Verwendung der Verschlüsselungsoperation) der RSA private Schlüssel von verwendendem Thawte geschätzt ist.

Zertifikat:

Daten:

Version: 1 (0x0)

Seriennummer: 7829 (0x1e95)

Unterschrift-Algorithmus: md5WithRSAEncryption

Aussteller: C=ZA, ST=Western Kap, L=Cape Stadt, O=Thawte Beratencc,

OU=Certification Dienstleistungsabteilung,

CN=Thawte Server

CA/emailAddress=server-certs@thawte.com

Gültigkeit

Nicht Vorher: Am 9. Juli 1998-WEZ der 16:04:02 Uhr

Nicht Danach: Am 9. Juli 1999-WEZ der 16:04:02 Uhr

Thema: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,

OU=FreeSoft,

CN=www.freesoft.org/emailAddress=baccala@freesoft.org

Unterworfenes öffentliches Schlüsselinfo:

Öffentlicher Schlüsselalgorithmus: rsaEncryption

RSA Publikum-Schlüssel: (1024 Bit)

Modul (1024 Bit):

00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: 33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1: 66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66: 70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17: 16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b: c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3: d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:

e8:35:1c:9e:27:52:7e:41:8f

Hochzahl: 65537 (0x10001)

Unterschrift-Algorithmus: md5WithRSAEncryption

93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: 92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92: ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67: d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1: 5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7: 8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:

68:9f

Um dieses Zertifikat gültig zu machen, braucht man ein zweites Zertifikat, das den Aussteller (Thawte Server CA) vom ersten Zertifikat vergleicht. Erstens prüft man nach, dass das zweite Zertifikat einer CA Art ist; d. h. dass es verwendet werden kann, um andere Zertifikate auszugeben. Das wird durch das Kontrollieren eines Werts des CA-Attributes in der X509v3 Erweiterungsabteilung getan. Dann wird der RSA öffentliche Schlüssel aus dem CA Zertifikat verwendet, um die Unterschrift auf dem ersten Zertifikat zu decodieren, um ein MD5 Kuddelmuddel zu erhalten, das ein wirkliches MD5 über den Rest des Zertifikats geschätztes Kuddelmuddel vergleichen muss. Ein Beispiel CA Zertifikat folgt:

Zertifikat: Daten:

Version: 3 (0x2)

Seriennummer: 1 (0x1)

Unterschrift-Algorithmus: md5WithRSAEncryption Aussteller: C=ZA, ST=Western Kap, L=Cape Stadt, O=Thawte Beratencc, OU=Certification Dienstleistungsabteilung, CN=Thawte Server CA/emailAddress=server-certs@thawte.com

Gültigkeit

Nicht Vorher: Am 1. Aug 1996-WEZ der 0:00:00 Uhr

Nicht Danach: Am 31. Dez 20:20 Uhr GMT der 23:59:59 Uhr

Thema: C=ZA, ST=Western Kap, L=Cape Stadt, O=Thawte Beratencc,

OU=Certification Dienstleistungsabteilung,

CN=Thawte Server

CA/emailAddress=server-certs@thawte.com Unterworfenes öffentliches Schlüsselinfo: Öffentlicher Schlüsselalgorithmus: rsaEncryption RSA Publikum-Schlüssel: (1024 Bit) Modul (1024 Bit): 00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c: 68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da: 85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06: 6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2: 6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b: 29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90: 6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f: 5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:

3a:c2:b5:66:22:12:d6:87:0d

Hochzahl: 65537 (0x10001)

X509v3 Erweiterungen:

X509v3 Grundlegende Einschränkungen: kritischer

CA:TRUE

Unterschrift-Algorithmus: md5WithRSAEncryption 07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9: a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48: 3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88: 4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9: 8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5: e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9: b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:

70:47

Das ist ein Beispiel eines selbstunterzeichneten Zertifikats, weil der Aussteller und das Thema dasselbe sind. Es gibt keine Weise, dieses Zertifikat außer durch die Überprüfung davon gegen sich nachzuprüfen; statt dessen werden diese Zertifikate auf höchster Ebene durch WWW-Browser manuell versorgt. Thawte ist einer der Wurzelzertifikat-Behörden, die sowohl von Microsoft als auch von Netscape anerkannt sind. Dieses Zertifikat kommt mit dem WWW-Browser und wird standardmäßig vertraut. Als ein langlebiges, allgemein vertrautes Zertifikat, das irgendetwas unterzeichnen kann (weil gibt es keine Einschränkungen in der X509v3 Grundlegenden Einschränkungsabteilung), sein Zusammenbringen privaten Schlüssels muss nah geschützt werden.

Sicherheit

Es gibt mehrere Veröffentlichungen über PKI Probleme durch Bruce Schneier, Peter Gutmann und andere Sicherheitsexperten.

Spezifizierung: Kompliziertheit und fehlt der Qualität

Der X.509 Standard wurde in erster Linie entworfen, um die X.500 Struktur, aber das heutige Gebrauch-Fall-Zentrum um das Web zu unterstützen. Viele Eigenschaften sind wenig oder keiner Relevanz heute. Die X.509 Spezifizierung leidet darunter, überfunktionell und underspecified zu sein, und die normative Information wird über viele Dokumente von verschiedenen Standardisierungskörpern ausgebreitet. Mehrere Profile wurden entwickelt, um das zu lösen, aber diese führen Zwischenfunktionsfähigkeitsprobleme ein und haben das Problem nicht befestigt.

Architektonische Fehler

• Gebrauch, ungültige Zertifikate auf die schwarze Liste zu setzen (CRLs und OCSP verwendend), statt whitelisting
• CRLs sind wegen der Größe und Vertriebsmuster besonders schwach
• Zweideutige OCSP Semantik und fehlt vom historischen Revokationsstatus
• Revokation von Wurzelzertifikaten nicht gerichteter
• Ansammlungsproblem: Identitätsanspruch (beglaubigen mit einem Bezeichner), schreiben Sie Anspruch zu (legen Sie eine Tasche von untersuchten Attributen vor), und Politikanspruch wird in einem einzelnen Behälter verbunden. Das erhebt Gemütlichkeit, Politik kartografisch darstellend und Wartungsprobleme.
• Delegationsproblem: CAs kann subCAs nicht technisch einschränken, um nur Zertifikate innerhalb eines beschränkten namespaces und Attribut-Satzes auszugeben - diese Eigenschaft von X.509 ist nicht im Gebrauch. Deshalb besteht eine Vielzahl von CAs im Internet, und das Klassifizieren von ihnen und ihren Policen ist eine unüberwindliche Aufgabe. Die Delegation der Autorität innerhalb einer Organisation kann überhaupt, als in der allgemeinen Geschäftspraxis nicht behandelt werden.
• Föderationsproblem: Zertifikat-Ketten, die das Ergebnis von sub-CAs, Brücke - und das Quer-Unterzeichnen sind, machen Gültigkeitserklärung kompliziert und teuer in Bezug auf die Verarbeitungszeit. Pfad-Gültigkeitserklärungssemantik kann zweideutig sein. Die Hierarchie mit der vertrauten 3.-Parteienpartei ist das einzige Modell. Das ist ungünstig, wenn eine bilaterale Vertrauensbeziehung bereits im Platz ist.

Probleme von kommerziellen Zertifikat-Behörden

• Fehlerhaftes Geschäftsmodell: Das Thema, nicht die vertrauende Partei, kauft Zertifikate. Der RA wird gewöhnlich für das preiswerteste Angebot gehen; Qualität wird für auf dem konkurrierenden Markt nicht bezahlt.
• CAs verweigern fast alle Garantien dem Benutzer.
• Verfallsdatum: Sollte verwendet werden, um die Zeit zu beschränken, die Schlüsselkraft wird genügend gehalten. Missbraucht durch CAs, um den Kunden eine Erweiterungsgebühr zu beladen. Legt unnötige Last auf dem Benutzer mit der Schlüsselüberlappenden Eingabe.
• In Browsern ist die Sicherheit die der schwächsten CA. Es gibt sehr schwachen CAs.
• "Benutzer verwenden ein unbestimmtes Zertifikat-Bitte-Protokoll, um ein Zertifikat zu erhalten, das in einer unklaren Position in einem nicht existierenden Verzeichnis ohne Echt-Mittel veröffentlicht wird, es zu widerrufen."

Durchführungsprobleme

Durchführungen leiden unter Designfehlern, Programmfehlern, verschiedenen Interpretationen von Standards und fehlen von der Zwischenfunktionsfähigkeit von verschiedenen Standards. Einige Probleme sind:

• Viele Durchführungen drehen Revokationskontrolle ab:
• Gesehen als Hindernis werden Policen nicht beachtet
• Wenn es in allen Browsern standardmäßig einschließlich des Codeunterzeichnens angemacht würde, würde es wahrscheinlich die Infrastruktur zertrümmern.
• DNs sind kompliziert und wenig verstanden (fehlen Sie von canonicalization, Internationalisierungsproblemen..)
• rfc822Name hat 2 Notationen
• Name und Politikeinschränkungen haben kaum unterstützt
• Schlüsselgebrauch das ignorierte, erste Zertifikat in einer Liste, die wird verwendet
• Die Erzwingung von kundenspezifischem OIDs ist schwieriger
• Attribute sollten kritisch nicht gemacht werden, weil es Kunden abstürzen lässt.
• Die unangegebene Länge von Attributen führt zu produktspezifischen Grenzen

Großtaten

• MD2-basierte Zertifikate wurden seit langem verwendet und waren für Vorbildangriffe verwundbar. Seitdem das Wurzelzertifikat bereits eine Selbstunterschrift hatte, konnten Angreifer diese Unterschrift verwenden und sie für ein Zwischenzertifikat verwenden. Dan Kaminsky an 26C3.
• 2005 haben Arjen Lenstra und Benne de Weger demonstriert, "wie man Kuddelmuddel-Kollisionen verwendet, um zwei X.509 Zertifikate zu bauen, die identische Unterschriften enthalten, und die sich nur in den öffentlichen Schlüsseln unterscheiden" hat das Verwenden eines Kollisionsangriffs auf die MD5 Kuddelmuddel-Funktion erreicht.
• 2008 haben Alexander Sotirov und Marc Stevens auf dem Verwirrungsnachrichtenkongress einen praktischen Angriff präsentiert, der ihnen erlaubt hat, eine Schelm-Zertifikat-Autorität zu schaffen, die durch alle allgemeinen Browser, durch die Ausnutzung der Tatsache akzeptiert ist, dass RapidSSL noch X.509 auf MD5 gestützte Zertifikate ausgab.

Wie man

• gehalten hatte, waren X.509 auf SHA-1 gestützte Zertifikate herauf bis die sehr letzte Zeit sicher gewesen. Im April 2009 auf der Eurogruft-Konferenz haben australische Forscher der Macquarie Universität "Automatischen Differenzialpfad präsentiert, der nach SHA-1 Sucht". Die Forscher sind im Stande gewesen, eine Methode abzuleiten, die die Wahrscheinlichkeit einer Kollision um mehrere Größenordnungen vergrößert.
• Mit dem Gebiet gültig gemachten Zertifikaten ("Trödel-Zertifikate") wird noch durch WWW-Browser vertraut, und kann mit wenig Anstrengung bei kommerziellem CAs erhalten werden.
• EV-Zertifikate sind von der sehr beschränkten Hilfe, weil Browser Policen nicht haben, die DV-Zertifikaten, Zusman und Sotirov Blackhat 2009 zurückweisen
• Es gibt Durchführungsfehler mit X.509, die z.B gefälschte unterworfene Namen mit ungültig begrenzten Schnuren Marlinspike Blackhat 2009 erlauben oder Spritzenangriffe in Zertifikaten codieren.
• Durch das Verwenden ungesetzlichen 0x80 hat Subbezeichner von Gegenstand-Bezeichnern, falschen Durchführungen oder durch das Verwenden von Überschwemmungen der ganzen Zahl ausgepolstert, ein Angreifer kann ein unbekanntes Attribut in den CSR einschließen, den der CA, der der Kunde falsch interpretes als "CN" (OID=2.5.4.3) unterzeichnen wird. Dan Kaminsky an 26C3.

PKI Standards für X.509

• PKCS7 (Kryptografischer Nachrichtensyntax-Standard - öffentliche Schlüssel mit dem Beweis der Identität für die unterzeichnete und/oder encrypted Nachricht für PKI)
• Secure Sockets Layer (SSL) - kryptografische Protokolle für das Internet sichern Kommunikationen
• Online Certificate Status Protocol (OCSP) / Certificate Revocation List (CRL) - das ist, um Beweis der Identität gültig zu machen
• PKCS12 (Persönlicher Informationsaustauschsyntax-Standard) - hat gepflegt, einen privaten Schlüssel mit dem passenden öffentlichen Schlüsselzertifikat zu versorgen

Zertifikat-Autorität

Eine Zertifikat-Autorität (CA) ist eine Entität, die Digitalzertifikate für den Gebrauch durch andere Parteien ausgibt. Es ist ein Beispiel eines vertrauten Dritten. CAs sind für viele Schemas der öffentlichen Schlüsselinfrastruktur (PKI) charakteristisch.

Es gibt viele kommerzielle CAs, die für ihre Dienstleistungen stürmen. Einrichtungen und Regierungen können ihren eigenen CAs haben, und es gibt freien CAs.

Infrastruktur des öffentlichen Schlüssels (X.509) Arbeitsgruppe

Die Infrastruktur des Öffentlichen Schlüssels (X.509) Arbeitsgruppe (PKIX) ist eine Arbeitsgruppe der Internettechnikeinsatzgruppe, die dem Schaffen von RFCs und anderer Standarddokumentation auf Problemen gewidmet ist, die mit der öffentlichen auf X.509 Zertifikaten gestützten Schlüsselinfrastruktur verbunden sind. PKIX wurde im Herbst 1995 in Verbindung mit dem Nationalen Institut für Standards und Technologie gegründet.

Siehe auch

• Abstrakte Syntax-Notation ein
• Zertifikat-Autorität
• Zertifikat-Politik
• Certificate Revocation List (CRL)
• Zertifikat-Server
• Codezugriffssicherheit
• Computersicherheit
• Kommunikationssicherheit
• Digitalzertifikat
• Digitalunterschrift
• Informationssicherheit
• ISO/IEC
• Gegenstand-Bezeichner
• Online Certificate Status Protocol (OCSP)
• Pretty Good Privacy (PGP)
• Öffentlicher Schlüssel
• Public Key Infrastructure (PKI)
• Protokoll des Zeitstempels
• Vertrauter timestamping

Protokolle und Standards, die X.509 Zertifikate unterstützen

• Transportschicht-Sicherheit (TLS/SSL)
• Sichern Sie Mehrzweckinternetposterweiterungen (S/MIME)
• IPsec
• SSH
• Kluge Karte
• HTTPS
• Extensible Authentication Protocol (EAP)
• Lightweight Directory Access Protocol (LDAP)
• Trusted Computing Group (TNC TPM NGSCB)
• CableLabs (nordamerikanisches Kabelindustrietechnologieforum)
• WS-Sicherheit
• XMPP
• Microsoft Authenticode
• ITU-T Empfehlung X.509 (2005): Informationstechnologie - Offene Systemverbindung - Das Verzeichnis: Beglaubigungsfachwerk, 08/05.
• C. Adams, S. Farrell, "Internet X.509 Publikum-Schlüsselinfrastruktur: Zertifikat-Verwaltungsprotokolle", RFC 2510, März 1999
• Housley, R., W. Ford, W. Polk und D. Solo, "Internet X.509 Publikum-Schlüsselinfrastruktur: Zertifikat und CRL Profil", RFC 3280, April 2002. Obsoleted durch RFC 5280, Obsoletes RFC 2459/aktualisiert durch RFC 4325, RFC 4630.
• Housley, R., W. Ford, W. Polk und D. Solo, "Internet X.509 Publikum-Schlüsselinfrastruktur: Zertifikat und CRL Profil", RFC 2459, Januar 1999. Obsoleted durch RFC 3280.
• Arjen Lenstra, Xiaoyun Wang und Benne de Weger, Auf der Möglichkeit, bedeutungsvolle Kuddelmuddel-Kollisionen für öffentliche Schlüssel, volle Version, mit einem Anhang beim Kollidieren von X.509 Zertifikaten, 2005 http://www.win.tue.nl/~bdeweger/CollidingCertificates/ zu bauen (sieh auch http://eprint.iacr.org/2005/067).

Links

• ITU-T Empfehlung X.509: Informationstechnologie - Offene Systemverbindung - Das Verzeichnis: Öffentlicher Schlüssel und Attribut-Zertifikat-Fachwerk
• Die Artikel von Peter Gutmann, eine Übersicht von PKI http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf, bemerkt X.509 Durchführung X.509 Stil-Führer
• PKIX Website
• Unternehmensvertrauensintegration und Webdienst-Sicherheitsstandards und Demos
• Häufig gestellte Fragen von RSA Laboratorien
• Sun Inc. - sichere Coderichtlinien
• RFC 4158 - Internet X.509 Publikum-Schlüsselinfrastruktur: Zertifikat-Pfad, der Baut
• CSR Decoder und Zertifikat-Decoder - können verwendet werden, um einen verschlüsselten CSR oder Zertifikat zu decodieren und zu untersuchen.
• SSL Kontrolleur - kann verwendet werden, um ein Zertifikat zu prüfen, und dass er richtig installiert worden ist