Zu den Keyservern gibt es schon seit einiger Zeit eine Alternative, um PGP Public Keys zu veröffentlichen.Verwendbar sind einmal der RR Typ
wobei man bei Letzterem keinen http Server für den Public Key benötigt. Eine Definition dieser RRs findet man in RFC-4398.
Typ PKA
Im DNS gibt es dazu den RR Typ PKA, über den
veröffentlicht werden. Man braucht dafür lediglich irgendwo Webspace, um den Public Key dort abzulegen, so dass dieser via
https abrufbar ist. Aufgrund des Fingerprints reicht auch http, weil im Falle einer Manipulation der Fingerprint nicht mehr
stimmen würde. Aus Datenschutzgründen könnte https jedoch trotzdem die bessere Wahl sein.
Mit diesem kleinen Skript kann man sich den RR schnell und einfach erzeugen lassen.
#!/bin/bash
KEY="12345678"
URL="https://www.example.com/${KEY}.pub.asc.txt"
EMAIL="user" # w/o domain
FP=$(LANG=C gpg --list-keys --fingerprint $KEY | grep fingerprint | sed 's/^ *Key fingerprint = //'|sed 's/ //g')
echo "${EMAIL}._pka IN TXT \"v=pka1;fpr=${FP};uri=${URL}\""
KEY, EMAIL und URL müssen natürlich angepasst werden. Mit
gpg --export -a 12345678
muss der Key exportiert werden und unter der im Skript angegebenen URL verfügbar gemacht werden.
Typ CERT
#!/bin/bash
KEY="12345678"
EMAIL="user" # w/o domain
TTL=3600
gpg --export ${KEY} --export-options export-minimal > ${KEY}.pub.bin
b64=$(openssl enc -in ${KEY}.pub.bin -base64 | tr -d '\n')
printf "%s\t%s\t%s" $EMAIL $ttl "IN CERT 3 0 0 ("
printf "%s " ${b64}
printf "%s\n" ")";
Das Resultat enthält hier einen recht langen RR, der in der betreffenden DNS Zone eingetragen werden muss. Der Vorteil dieser Lösung liegt darin, dass man keinen http Server braucht, um den Public Key zu publizieren.
Wirklich sicher ist das nur dann, wenn die Domain mit DNSSEC gesichert ist, ansonsten könnte auch der Fingerprint z.B. über DNS Cache Poisoning verändert werden.
GnuPG unterstützt DNS als Quelle für PGP Keys, so dass man nichts mehr umständlich importieren muss. Das folgende Beispiel zeigt die Anwendung:
#!/bin/sh
SUBJ="Test PGP"
KEY="[email protected]"
RCPT="User <[email protected]>"
BODY='Hello world!'
TMP="/tmp/gpg-$$"
echo "$BODY" | gpg --batch --trust-model always \
--no-default-keyring \
--keyring "$TMP" --encrypt --armor \
--auto-key-locate cert \
-r "$KEY" | \
mailx -s "$SUBJ" "$RCPT"
Das Beispiel eignet sich für die Einbindung in Skripte. Ob man allen Schlüsseln trauen will, muss jeder selber wissen,
ggf. einfach –trust-model always weg lassen. Wenn die betreffende Domain DNSSEC unterstützt, kann man der
Authentizität des Keys schon zumindest bis zur Domain trauen.
Keyserver wie z.B. https://key.ip6.li vertrauen darauf, dass der PGP Key von mehreren Personen signiert ist und nutzt dabei das Funktionsprinzip von PGP. Mal ganz ehrlich: Wer prüft das wirklich? Der Schwachpunkt ist hier wieder der Anwender.
Die DNS Lösung hat den Vorteil, dass zumindest nachweisbar ist, dass der Public zu der Domain der E-Mail Adresse gehört, denn [email protected] muss ja wohl den Key user.example.net haben. Man kann also durchaus annehmen, dass diese Lösung ebenso verlässlich ist, wie ein S/MIME Zertifikat.