[LUGA] Mit freundlicher Unterstützung von:
WSR

Mail Thread Index


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

PGP und MIME



Nachdem ich kürzlich mla's PGP-signierte multipart-messages moniert
habe, habe ich ein bißchen in den relevanten RFCs geschmökert.

Ergebnis:

Meine Behauptung, daß das ganze nicht MIME-compliant sei, entspricht
nicht den Tatsachen, ich ziehe sie hiermit zurück. Soweit es MIME
betrifft, bestand die Mail aus einem einzigen Teil vom Content-Type
application/pgp, und wie der aussieht, geht niemanden außer die 
Applikation PGP was an. 

Da allerdings liegt schon der erste Hund begraben: application/pgp ist
nirgends (oder zumindest nicht bei der IANA) registriert, infolgedessen
kann der Empfänger nur raten, was er damit anfangen soll.

Daß das ganze durch PGP gepipet werden soll, ist ja noch relativ klar.

Daß format=mime bedeutet, daß der Inhalt wieder MIME-Format hat und
entsprechend weiter verarbeitet werden soll, ist für den menschlichen
Leser auch einsichtig, meine selbstgebastelte Helper-Application
für den tkmail hat es allerdings überfordert (Ich sehe auch keine
Möglichkeit, das zurückzupipen. Wie macht das der exmh? Fix eingebauter
Support für application/pgp oder flexibel genug, um solche Sachen 
spezifizieren zu können?).

x-action=clearsig und x-originator=62C995D9 schließlich braucht man
eigentlich gar nicht,
man könnte höchstens eine Warnung ausgeben, wenn der Inhalt kein
cleartext mit signature oder die Signature nicht mit Key 62C995D9
gemacht wurde.

Im entsprechenden RFC 1847 werden zwei MIME-types multipart/signed
und multipart/encrypted spezifiziert, die jeweils aus zwei Teilen
bestehen. Deine Mail hätte demnach ungefähr so aussehen können:

|Content-Type: multipart/signed; protocol="pgp/clearsig";
|              micalg="pgp"; boundary="Signed Boundary"
|
|--Signed Boundary
|Content-Type: multipart/mixed ;
|        boundary="===_0_Mon_Jun__3_23:42:00_MET_DST_1996"
|
|This is a multipart MIME message.
|
|--===_0_Mon_Jun__3_23:42:00_MET_DST_1996
|Content-Type: text/plain; charset=us-ascii
|
|
|Ob das funktioniert? loki.gams.co.at ist eine "alte" (NIC)
|Adresse. Die wird vom EBONE nicht geroutet.
|
|Aber ich werde einen ssh proxy auf der Firewall einrichten.
|
|
|
|--===_0_Mon_Jun__3_23:42:00_MET_DST_1996
|Content-Type: text/plain; charset=us-ascii
|Content-Description: identity.pub
|Content-Transfer-Encoding: base64
|
|MTAyNCAzMyA5NjIwODI3NjcxMjE4NjYzNTcwNTg5NzY1NjY5NTgzMDQ2NTgyNTc5NTg4NjQ0
|NDgwNzg2Nzk1MTIzNDI2MjgxNTE3MjE5MzI2NDk2OTgxMTc0Nzc0MjcxOTI0NzM3OTMwNzE1
|Mjg4MjUzMzg2MTkxODk5NTUwMTg3MzI3Mzg3MjcyODgyMDYzODI4MjQ0MjgzNTAyNTAzOTI1
|NTcxNjExNTEwNDMwNTA0NTA3OTQyNTY0MjkwNjkzNTA5ODczNjcyNDc1NjEzMjU3MDg5NDg1
|Njc1MTM3Mjk0MDg3Njc3MDA2NTY3NTI1MzQyMjI5ODMwMTgyNTkwNTE0MDI3NTkzMzc4ODMy
|NzE1MjI4Mjk3NDE1ODI2NTA3NDMwNjk3MjU1MTM3MDI3NDQ1MDY1MzkxNjMyMSBtbGFAbG9r
|aS5nYW1zLmNvLmF0Cg==
|
|--===_0_Mon_Jun__3_23:42:00_MET_DST_1996--
|
|--Signed Boundary
|Content-Type: pgp/clearsig
|
|Version: 2.6.2i
|
|iQCVAwUBMbNcO9o6LU1iyZXZAQH8ggP/XbKBBmMYntpwBgT3YOWPh41r/Gc14VDp
|OeOx7UzrzpiG2ADPR38uUj5d/tuadY275F4oSVxHVB2VtycP+5buThzY3wRIVLpH
|V5OXoxM0eUiqJC41bumwZyQXuHphTf6pRhO46lC5txqflwg0qGRLPSTwxI0HfmdP
|JtLn1GIam0g=
|=Te7d
|--Signed Boundary--


Da die Grenzen zwischen Text und Signature hier bereits vom Protokoll
vorgegeben sind, habe ich die entsprechenden Delimiter vom PGP
weggelassen (und auch das Quoting der - am Zeilenanfang). Der
MIME-Handler müßte dann Text und Signature entweder in zwei separate
Temp-Files abspeichern oder diese einfügen. Daß der Text wieder
MIME-Format hat, ist im RFC spezifiziert. Der subtype und der micalg
sind vorgeschrieben, wären aber im Fall von PGP nicht notwendig
(pgp/clearsig und pgp habe in dem Fall ich erfunden, der RFC
spezifiziert nur ein Framework, aber keine speziellen Strings für
protocol und micalg).

Im Fall von multipart/encrypted könnte das ganze so aussehen

|Content-Type: multipart/encrypted; protocol="pgp/armor";
|        boundary="Encrypted Boundary"
|
|--Encrypted Boundary
|Content-Type: pgp/armor
|
|
|--Encrypted Boundary
|Content-Type: application/octet-stream
|
|--BEGIN PGP MESSAGE-----
|Version: 2.6.3i
|
|hEwCNUyTrWgbOX0BAf9J6Av8VK1Nvr76AM5hSj5vADp23GlOY9h4F4vG+Rg/0817
|4zCjZoqY5TGyi4BGJkQD4KThYlUgG5Is7EbLvQ3epgAAH3/RrV858lzLwQ/CVBHa
|[...]
|0BjBuhDYTM7CgnoADmHXS+EKfyhLxfuPL8qyTNnrxcrk5JXitV2IZ3G4yp8oqFtw
|QpcVeFxmJgO0PaNzVnNkfRwn2hvQSktOljZ9zAnVZjBoIA==
|=Ie9j
|-----END PGP MESSAGE-----
|
|--Encrypted Boundary--

oder ohne armor und dafür mit Content-Encoding base64.


Es gibt übrigens noch einen RFC 1848 »MIME Object Security-Services«,
der darauf aufbaut, aber der hat 48 Seiten, von denen ich erst einen Teil
gelesen habe. PGP kommt darin aber auch nicht vor.


        hp

   _  | Peter J. Holzer             | Workstations are like toothbrushes --
|_|_) | Sysadmin WSR                | Nobody may use mine, especially not
| |   | hjp@wsr.ac.at               | while I am using it.
__/   | http://wsrx.wsr.ac.at/~hjp/ |     -- Robert van Renesse



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010