[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HTTP mit RfC 3156 (MIME/OpenPGP)?
[Thread Prev] | [Thread Next]
- Subject: Re: HTTP mit RfC 3156 (MIME/OpenPGP)?
- From: Martin <martin@xxxxxxxxxxxx>
- Date: Sun, 11 May 2014 20:35:07 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Hi, 2014-05-10 2:47 GMT+02:00 Raphael Eiselstein <rabe@xxxxxxxxx>: > Nicht fuer jeden Anwendungsfall interessiert mich das Vertrauen zum > Server sondern zB dass der Server mit Daten fuer mich verschluesselt > uebermittelt, meinetwegen auch mit einer Signatur, die ich nicht > unmittelbar sofort pruefen kann. Es muss unbedingt interessieren. Ohne diese Information weiszt du einfach nicht wer am anderen Ende ist und ob die Entitaet nicht vielleicht direkt einen Twitter Stream befuettert mit genau den Informationen deines Trafics... Ab dem Zeitpunkt der Verschluesselung gibt es ein Shared Secret, sei das nur das klassische Token das 2 kommunizierende haben oder eine gemeinsame Vertauensbasis -- btw. das Vertrauen an sich wird auch in PGP als geheime Information betrachtet und sollte nicht oeffentlich sein (https://www.gnupg.org/gph/en/manual.html#AEN346). Natuerlich laesst sich auch ueber Konstrukte in PGP ein CA aehnliches Konstrukt erzeugen, das wiederum hat dann aber keinen Unterschied zur CA Struktur der jetzigen Form (mittel-/langfristig). Ohne die Moeglichkeit zu verifizieren wer am anderen Ende steht ist die Kommunikation einfach nicht gesichert. >> Was nimmst du dann? > > In *diesem* Fall: Aus den HTTP-Header das, was ich zum decrypten > benoetige (also irgendein mime/multipart/*), aus dem meta-Tag des dann > entschl+sselten Dokuments (HTML, XML) das, was es nachher inhaltlich > darstellen soll. Ich sehe hier keinen Widerspruch. Abgesehen davon das ein XML Parser schon mal gesagt haette "not well formed" (kein schlieszendes Meta-Tag oder self closing). Der Punkt war das in der Theorie zwar ein Content-Type existiert, aber die Praxis und das parsen von dem Kram da drauszen nicht umsonst den "quirks mode" enstehen (IMHO der einzige Weg um als Browser tatsaechlich was anzuzeigen) haben lassen. Ein Webservice das nicht von einem Browser gelesen werden kann ist "anything goes" es gibt keinen Standard fuer REST. SOAP ist nicht gebunden an HTTP und sonst gibt es IMHO nichts mehr mit groeszerer Verbreitung (Korrekturen bitte!). Wenn du selbst eine Client Lib schreibst und zur Verfuegung stellst ist es relativ egal, da kannst du auch multipart/signed mit application/octet-stream und application/pgp-signature verwenden und es wird niemand interessieren.... Ich bleib dabei: Solange das Grundproblem "Wie vertraue ich der Gegenstelle" nicht schluessig geloest ist, bleibt das einen technische Spielerei (die ja auch bereits existiert) und ist fuer mich nicht nutzbar -- Ja ich weiss bei den derzeit gaengigen Zertifikaten habe ich die Vertrauensstellung ausgelagert, damit bin ich aber fuers erste zufrieden. LG, Martin -- UUGRN e.V. http://www.uugrn.org/ http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/