[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTP mit RfC 3156 (MIME/OpenPGP)?


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/