[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