[linux-l] Wie man CAcert.org Zertifikate deinstalliert
Steffen Dettmer
steffen at dett.de
Di Jul 7 00:31:03 CEST 2009
* Lutz Willek wrote on Sun, Jul 05, 2009 at 10:37 +0200:
> Steffen Dettmer schrieb:
> >>> Eine ganze Reihe von bisher eher "muendlich ueberlieferten"
> >>> Regeln wurden in Policies gegossen
> >
> > kann ich kaum noch etwas hinzufügen. Wenn ein `Assurer' das nicht
> > versteht, paßt das prima in mein Bild von CAcert.org.
> > (ist ironisch gemeint. Natürlich kann man dem unheimlich viel hinzufügen)
>
> Ich verstehe das nicht, Du haust auf cacert rum und sagst nicht warum.
War vermutlich nicht klar genug ausgedrückt. Ich muß zugegeben,
es interessiert mich auch nicht so sehr. Wer will, kann ja
CAcert.org vertrauen. Wer will, kann Zeritifkate von 12-jährigen
Chinesen trauen und an deren Sicherheit glauben. Meintewegen auch
an den Weihnachtsmann. Daher war ich wohl zu knapp.
> Was soll daran schlecht sein das die neuen verschärften Regeln jetzt
> "offiziell" werden? Vorher gab es doch auch schon Regeln, jetzt halt
> mehr davon.
- `von bisher eher' oder vielleicht mehr oder weniger? Fängt
schon mal schwammig an.
- `muendlich ueberliefert' ist keine Qualität. Qualität und
Prozesse müssen genaue Regeln haben und sogar Regeln, wie man
diese prüfen kann. Prüfen ist dabei ein systematischer Vorgang.
- `"muendlich ueberlieferten" Regeln' ist ein Widerspruch in
sich. Regeln müssen einhalten und prüfbar sein. Regelverstöße
müssen ahnbar sein. Wenn etwas mündlich überliefert ist, kann
es nicht 100% klar sein (wobei manche der Meinung sind, auch
nichts schriftliches kann 100% klar sein). Wenn es nicht klar
ist, ist es nicht prüfbar und somit kann es keine Regel sein.
- `wurden in Policies gegossen'. Das kann nicht rückwirkend
gehen. Man kann rückwirkend Sicherheitslevel reduzieren, aber
nicht erhöhen. Falls das wieder zu kurz ist, je ein Beispiel.
Reduktion durch Veröffentlichung eines geheimen Schlüssels oder
Wegfall von Regeln. Unmögliche Erhöhung durch neue Regel, weil
man nachträglich ja nicht sicherstellen kann, dass der geheime
Schlüssel nie gegen diese Regeln angewendet wurde (weil es die
damals ja gar nicht gab, kann man es ja nicht wissen, selbst
wenn es ab dem Zeitpunkt der Regelexistenz transkationssicher
protokolliert werden muß - kann ja nicht rückwirkend gelten und
glaubhaft sein).
- in `Policies gießen', was man gerade so macht, mag ein
üblicher und pragmatischer Ansatz bei der Installation eines
Qualitätswesens sein, aber so kriegt man nichtmal ISO9001. Gut,
kriegt man schon, wenn man die Gutachterfirma auch als
Konsulter einkauft (weil die ja incht gegen sich selbst richten
können), ist bloß teurer, aber immerhin einklagbar. Wie auch
immer. Jedenfalls müssen diese Policies und die zu verwendenden
Prozesse aufwändig entwickelt, getestet, geprüft (auditiert)
werden. Dann, nach genauen Freigabeprozessen, meist externen
Audits und Gutachten etc., kann man Schulungen durchführen und
sonstige notwendige Maßnahmen ergreifen und dann diese
freigeben. Dazu muß im Falle von Kryptografie dann mindestens
ein neuer root key erzeugt werden (es sei denn, das neue System
ist unsicherer als das alte und eine Teilmenge dessen, so daß
die neuen Regeln mit den alten vollumfänglich gefordert waren,
sprich, dass man nur Regeln bzw. Einschränkungen wegläßt).
Auch die Diskussion über die Audits sprach schon Bände. Meiner
Meinung nach müßte eine "offene Lösung" so extrem hart sicher
sein, daß alles kommerzielle vor Neid erblaßt. So war's vor 10
Jahren ja mit Linux auch mal. Gut, heute im
Mir-wirds-langsam-z/U-bunt-Du/ muß man das alles relativ sehen,
aber damals dachte ich jedenfalls: wozu Kompromisse, wenn man
alles perfekt haben kann?
Na ja, komplexes Thema, wenn man es richtig machen will. Aber ein
Punkte-basiertes System, wie in einem noob-Forum, ist meiner
Meinung nach außerhalb jeglicher Diskussion. Ich muß gestehen,
ich verstehe nicht einmal, wie man dem überhaupt Wert beimessen
kann! Das ist meiner Meinung nach etwa so, wie an ein "Web of
trust" zu glauben. Und auch dort gibt es einige, die tatsächlich
daran glauben. Vielleicht gibt es auch einige, die an den
Weihnachtsmann glauben. Wer weiß. Verstehen kann ich all dieses
jedenfalls nicht.
Wenn etwas behauptet, SICHER zu sein, muß ich es einklagen
können. Es muß einen harten Vertrag geben und Garantien. Wenn das
Geld kostet, beispielsweise wegen einer notwendigen
Haftpflichtversicherung, dann ist das so. Kann ich nehmen oder
lassen. Aber ohne Vertrag, Versicherung usw. mit der Begründung
"kostet ja auch nix" ist IMHO nicht billig, sondern schlicht
falsch.
> Ich meine als Bank oder Webshop kann man kein solches
> Zertifikat nehmen, einfach weil die Beglaubigungskette nicht
> stark genug ist um auch die Leute hinter einer Webseite zu
> beglaubigen
? Was ist jetzt bitte an einer Webseite besonderes? Ist IMHO
ziemlich verdammt weit unten in der Vertrauenskette....
> (das wäre so als würde ich einen Hammer zum Schraube eindrehen
> nehmen, falsches Werkzeug halt...) Das leistet cacert aber eh
> nicht. Als gute Alternative zum selbst signierten Zertifikat
> sehe ich sie aber schon.
`selbst signierten Zertifikat' ist IMHO ein ganz anderes Thema.
Ich habe beispielsweise solche mit hohem Niveau. So hoch, das ich
sie nicht nutze. Ich hab hier z.b. einen 486 ohne Netzwerk nur
mit Floppy zum Daten-Austausch mit einem `medium secure key'.
Nutz ich nicht, zum umständlich. Vermutlich aber ungleich
schwerer anzugreifen, als den schwächsten Assurer von CAcert.org.
Gibts da eine Liste aller Assurer? Sind bestimmt viele. Sehr
viele. z.B. die 12 jährigen Chinesen. Mit Punkten ohne Ende. Die
haben halt viele Kumpels.
> Was bitte soll so schlecht an so einer Organisation sein?
Vertrauen hängt eben nicht davon ab, wieviele einen `cool'
finden, sondern ob die Prozesse und Audits was taugen. Wenn die
im Nachhinein erschaffen werden, ist das IMHO Beweis genug, dass
es sich um Snakeoil handelt (Schlangengift muß ja für irgendwas
gut sein - aber Security ist es IHMO nicht).
Wobei ich gesehen muß, daß mir diverse Richtlinien zur verwandten
kommeriziellen Sicherheitsthemen auch unzureichend erscheinen.
Was ein Glück, dass ich kein Sicherheitsgutachter bin :-)
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
Mehr Informationen über die Mailingliste linux-l