Diskussion:Public-Key-Zertifikat

Inhalt und Struktur

... ließen leider sehr zu wünschen übrig. Da wird einfach mal ein X.509-Zertifikat reinkopiert, PGP und Gnu-PG erläutert (und hierarchische PKI nicht!), SSL und S/MIME als je eine der drei (!) Anwendungen genannt, aber die logische Idee hinter einem Zertifikat fehlt. Ich will hier nicht über andere Autoren herziehen, jeder hat das Recht zu schreiben und ist willkommen. Aber wir sollten versuchen, erst das Konzept zu erklären und dann Beispiele zu geben. Aber dann bitte ausgewogen. Neben SSL steht eben auch SSH, IKE/IPSec, WTLS, u.v.m. Klar sind manche Beispiele praktisch relevanter, aber das muss man dann auch so formulieren.

Ich habe den Artikel ziemlich überarbeitet. Als nächstes werde ich den Abschnitt Vertrauensmodelle zum Artikel PKI verschieben, dort gehört er hin. Hier muss eigentlich nicht mehr viel stehen, außer was ein Zertifikat ist, der Zusammenhang mit einer PKI, Standards (fehlt noch) und vielleicht ein Beispiel.--Mojo1442 14:26, 21. Dez. 2006 (CET)

So, ich habe den Artikel wie angekündigt noch einmal überarbeitet und mit dem Artikel zu Public Key Infrastrukturen konsolidiert.--Mojo1442 14:26, 21. Dez. 2006 (CET)

Alte Beiträge

Wenn es schon ein derart ausführliches Beispiel gibt, sollten zumindest Teile der kryptischen Zeichenkolonnen erklärt werden. --Mikue 14:07, 15. Okt 2003 (CEST)

hi

ich will also mal einen Versuch starten die Zeichenreihen zu erklären...

   Public Key Algorithm: rsaEncryption
   RSA Public Key: (1024 bit)
           Modulus (1024 bit):
                   00:c4:40:4c:6e:14:1b:61:36:84:24:b2:61:c0:b5:
                   d7:e4:7a:a5:4b:94:ef:d9:5e:43:7f:c1:64:80:fd:
                   9f:50:41:6b:70:73:80:48:90:f3:58:bf:f0:4c:b9:
                   90:32:81:59:18:16:3f:19:f4:5f:11:68:36:85:f6:
                   1c:a9:af:fa:a9:a8:7b:44:85:79:b5:f1:20:d3:25:
                   7d:1c:de:68:15:0c:b6:bc:59:46:0a:d8:99:4e:07:
                   50:0a:5d:83:61:d4:db:c9:7d:c3:2e:eb:0a:8f:62:
                   8f:7e:00:e1:37:67:3f:36:d5:04:38:44:44:77:e9:
                   f0:b4:95:f5:f9:34:9f:f8:43
               Exponent: 65537 (0x10001)

Im Artikel wird erwähnt, dass es sich bei einem Zertifikat im Prinzip um einen signierten Public Key handelt.

In diesem Beispiel ist das Verschlüsselungsverfahren RSA. Bei diesem Verfahren besteht der Public Key aus zwei Zahlen: Hier Modulus und Exponent genannt. Um im RSA Verfahren eine Nachricht M zu verschlüsseln, berechnet man (M^Exponent mod Modulus). Dabei ist die Modulus Zahl das Produkt zweier (großer) Primzahlen. Hier hat die Modulus Zahl 1024 bit. Die Zeichenreihe ist die se Bitzahl in der Hexadezimal Darstellung. Jede Ziffer (0..9,a..f) sind 4 bit also sind :xx: 8 bit und es gibt, (wenn ich mich nicht verzählt habe) 128 Ziffernpaare mal 8 bit = 1024 bit.

   Signature Algorithm: md5WithRSAEncryption
       12:ed:f7:b3:5e:a0:93:3f:a0:1d:60:cb:47:19:7d:15:59:9b:
       3b:2c:a8:a3:6a:03:43:d0:85:d3:86:86:2f:e3:aa:79:39:e7:
       82:20:ed:f4:11:85:a3:41:5e:5c:8d:36:a2:71:b6:6a:08:f9:
       cc:1e:da:c4:78:05:75:8f:9b:10:f0:15:f0:9e:67:a0:4e:a1:
       4d:3f:16:4c:9b:19:56:6a:f2:af:89:54:52:4a:06:34:42:0d:
       d5:40:25:6b:b0:c0:a2:03:18:cd:d1:07:20:b6:e5:c5:1e:21:
       44:e7:c5:09:d2:d5:94:9d:6c:13:07:2f:3b:7c:4c:64:90:bf:
       ff:8e

Hier bin ich mir nicht mehr so ganz sicher, aber die ist die Signatur der Trusted Party die das Zertifikat ausstellt. Also müsste dies hier der mit dem Secret Key der Trusted Party verschlüsselte Hashcode des Zertifikats sein. (Oder so ähnlich) --Autor unbekannt

Eine Verschlüsselung findet bei einer digitalen Signatur schon mal gar nicht statt! Ich habe dieses Beispiel zum Artikel X.509 verschoben.--Mojo1442 14:23, 21. Dez. 2006 (CET)

Oder so ähnlich

Ja, an dieser Stelle wird die Sache auch für mich ziemlich unklar. Die Signatur ist Bestandteil des Zertifikats. Daher ist es offensichtlich unmöglich die Signatur aus dem gesamten Zertifikat zu berechnen, weil die Signatur vor der Berechnung nicht bekannt ist und der Hashwertberechnung (erster Schritt der Signaturberechnung) nicht möglich ist. Was genau in die Signaturberechnung eingeht, konnte ich aber bisher nicht recherchieren. Es käme z.B. der Text bis

Signature Algorithm: md5WithRSAEncryption

in Frage oder wirklich nur der öffentliche Schlüssel. Vor allem ist mir aber gänzlich unklar, wie das Zertifikat (also die Signatur darunter) in der Praxis geprüft werden kann. Es wahrscheinlich erforderlich ein weiteres Zertifikat zur Prüfung und eine geeignete Software zu besorgen. Es stellt sich dann erneut die Frage, wie dieses weitere Zertikat und die Software zu prüfen sind. Franz Scheerer

Es geht alles vor Signature Algorithm: md5WithRSAEncryption in die Signatur ein. Diesen ersten Teil nennt X.509 auch ToBeSigned. Allerdings sind die Informationen im Zertifikat noch einmal kodiert und sehen nicht so aus wie oben angegeben. Der Ausdruck Signature Algorithm: steht z.B. so nicht da, sondern ein entsprechender Object Identifier (OID). Auch md5WithRSAEncryption ist nur ein Name für einen OID, er lautet 1.2.840.113549.1.1.4.

Die Prüfung erfolgt mit dem Public Key des Ausstellers, den man sich aus einem anderen Zertifikat besorgen muss. Das wäre dann natürlich wieder zu prüfen, sofern es sich nicht um ein Root-CA-Zertifikat handlt. So entsteht ein Validierungspfad (siehe Public Key Infrastruktur).--Mojo1442 14:34, 21. Dez. 2006 (CET)

Unterscheidung Qualifiziertes Zertifikates <> qualif. elektr. Signatur

An mehreren Stellen im Artikel steht in etwa "Qualifizierte Zertifikaten sind der eigenhändigen Unterschrift gleichgestellt." Hier wäre noch eine klarere Formulierung nötig, weil es nicht die Zertifikate, sondern die qualif. elektronischen Signaturen sind, die der eigenh. Unterschrift gleichgestellt sind

Nutzen von Zertifikaten

Hi, mir fehlt noch ein, auch für den normalen Anwender, verständlicher Abschnitt zum Nutzen von Zertifikaten. Was genau lässt sich damit machen? Stelle mir das ungefähr so vor:

---

• Der geheime Schlüssel (Private Key) ist nur dem Eigentümer zugänglich, er darf anderen nicht zugänglich gemacht werden.
• Der öffentliche Schlüssel (Zertifikat) kann weltweit veröffentlicht werden.
• Daten, die mit dem Private Key verschlüsselt werden, können nur mit dem dazugehörigen Zertifikat entschlüsselt werden.
• Daten, die mit dem Zertifikat verschlüsselt werden, können nur mit dem dazugehörigen Private Key entschlüsselt werden.

Anwendungsbeispiel:

Person A möchte Person B eine E-Mail schicken. A besitzt ein Zertifikat und den dazugehörigen Private Key. A verschlüsselt die Mail auf Grundlage des Zertifikats mit dem Private Key. B empfängt die E-Mail. Wenn B der Zertifizierungsstelle vertraut, die das Zertifikat ausgestellt hat, kann B sicher sein, das die Mail von A gekommen ist.

B möchte nun A eine Mail schicken. B verschlüsselt die Mail mit dem Zertifikat von A (ohne den Private Key von A). B kann nun sicher sein, das nur A die Mail lesen kann, da nur A die Mail wieder entschlüsseln kann.

---

Würde mich freuen wenn einer der Hauptautoren da nochmal drüber schaut, und es in den Artikel aufnimmt (Die letzten paar mal als ich, bei anderen Artikeln, eigenmächtig was geändert hab wurde es immer wieder zurückgesetzt - heut probier ich es mal so ;) ) Ciao Volly imnetz 11:23, 29. Mär. 2007 (CEST)

Ist das nicht schon im verlinkten Artikel Asymmetrisches Kryptosystem ausreichend erklärt?

Ich finde auch, dass der genaue Ablauf mit Zertifikaten und Zeritfikat-Servern nicht wirklich ausreichend geklärt ist. Es wäre schön, wenn der genaue Ablauf eines verschlüsselten Verbindungsaufbaus erläutert werden würde. Unter Asymmetrisches Kryptosystem wird zwar das Prinzip von Public und Private Key beschrieben aber nicht der genaue Ablauf mit Zertifikaten und Zertifikat-Servern. --AngMo 14:44, 10. Apr. 2007 (CEST)

---

http://en.wikipedia.org/wiki/Public_key_certificate beschreibt unter "Use" ziemlich gut wofür das digitale Zertifikat dient! (Stand 13.Sept.2007, 10:00, CET)

Änderung bei den Anbietern

Ich habe die Information der Schweizer Anbieter, welche nur auf die Swisscom beschränkt war, auf alle akkreditierten Schweizer Zertifikatsdienstleiter erweitert.

Was genau ist ein Stammzertifikat?

In dem Artikel taucht der Begriff "Stammzertifikat" nicht auf und in der gesamten deutschen Wikipedia wird der Begriff nur ein einziges mal beiläufig erwähnt - aber nicht erklärt. In der täglichen Arbeit am Rechner stößt man oft über den Begriff. Da leider auch keines der Online-Wörterbücher den Begriff kennt kann ich mich auch nicht in der Englischwiki schlau machen... Wie lautet die korrekte Definition für "Stammzertifikat" und was heißt "Stammzertifikat" auf englisch? Bei meiner Recherche bin ich auch auf den Begriff "Zwischenzertifikat" gestoßen der meiner Meinung nach auch in diesem Artikel behandelt werden sollte. Leider hat sich jedoch nun seit bald einem Jahr außer mir niemand mehr in dieser Diskussion betätigt.--DavidDerGroße 18:51, 14. Sep. 2009 (CEST)

Dieselbe Frage hätte ich auch. Wer kennt sich in dieser Materie aus und ergänzt die Wikipedia um Informationen? --Wolfgang1018 09:12, 8. Okt. 2009 (CEST)

Nachdem der Begriff nach einem weiteren Jahr immer noch nicht in der Wikipedia zu finden ist, setze ich diesen Link, der zwar auch nur unzureichende rudimentäre Informationen bietet, und bitte weiterhin, dass ein Kenner der Materie im Hauptartikel dazu Infos ergänzt. --Wolfgang1018 15:45, 8. Nov. 2010 (CET)

Der Begriff wird von Microsoft für Wurzelzertifikate verwendet. Die verwenden ja gerne ihre eigenen Begriffe. Aber auch der (Standard-)Begriff Wurzelzertifikat war noch nicht erklärt. Ich habe den Begriff nun im Artikel Public-Key-Infrastruktur erläutert. --Mojo1442 21:50, 26. Feb. 2011 (CET)

OCSP

"die im Unterschied zu Sperrlisten auch Positivauskünfte („dieses Zertifikat ist authentisch und gültig“) geben können."

das ist im Allg. falsch. OCSP ist entstanden um das vollständige herunterladen und checken der relativ langen CRLs einzusparen. OCSP ist also nur eine "Abkürzung" in Bezug auf die CRLs. OCSP kann nur drei Antworten geben: Good, Revoked und unkown (RFC 2560). "Good" heisst nur: es ist nicht in der Speerliste. (Es kann u.Um. in Bezug auf seinen Gültigkeitszeitraum abgelaufen sein, dann ist es aber immer noch "Good", gleich NICHT auf der Speerliste.)

Zitat von RFC 2560: "good [...] but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval." (nicht signierter Beitrag von 195.145.148.246 (Diskussion | Beiträge) 11:38, 6. Apr. 2010 (CEST))

Du hast völlig recht, dass das nach dem Standard nicht so sein muss. Kann es aber, wenn der OCSP-Responder dies so implementiert. Und genau das hatte ich geschrieben. Natürlich müssen die Clients diese Semantik unterstützen. Das funktioniert nur, wenn es entsprechende Regelungen gibt, die von OCSP-Respondern und Clients umgesetzt werden, so z.B. bei qualifizierten Zertifikaten in Deutschland. --Mojo1442 21:57, 26. Feb. 2011 (CET)

Lemma

Wenn schon, dann muss es nach deutscher Rechtschreibung Public-Key-Zertifikat heißen. (Oder englisch "certificate".) "Public Key Zertifikat" geht gar nicht. --08-15 22:46, 23. Feb. 2011 (CET)

+1. Ich stelle ein SLA auf die Weiterleitung Public-Key-Zertifikat, damit der Artikel verschoben werden kann. --Fomafix 10:52, 24. Feb. 2011 (CET)

Verweis auf PKI in der "Übersicht"

Der viertletzte Abschnitt der "Übersicht" endet mit "Diese Hierarchie von Zertifikaten bildet eine Public-Key-Infrastruktur (PKI)."

Das ist m.E. falsch. Eine PKI umfasst insbesondere auch die Organisationen (z.B. Zertifizierungsstelle, Certificate Authority, CA), welche die Zertifikate erzeugt. Hier wäre der Begriff "certificate-chain" (oder vielleicht: Zertifikatskette) angebracht. Diese ist dann wiederum Teil der PKI. --Constejo (Diskussion) 12:59, 29. Jul. 2019 (CEST)