On Wed, 2005-07-13 at 10:31 +0200, Simon Josefsson wrote:
Derek Atkins <derek(_at_)ihtfp(_dot_)com> writes:
Hi,
Do the members of this working group feel we need a meeting
in Paris? I think we might want to meet in order to consider
work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
that's been proposed).
I would likely be around to talk about the OpenPGP mail header [1], if
there is interest. Feedback from OpenPGP experts on the usefulness of
adding a "supports" token to the header is one open issue that may be
useful to discuss.
I actually am more in it for just specifying where the keyserver for
this key is located. Or actually just having the address of this key.
Eg, when I send mail out, it gets signed by my jeroen(_at_)unfix(_dot_)org key.
But
there is no reference to that anywhere to which id which key belongs
(afaik).
Currently a raw mail contains something like:
8<-----------------------------------------------------------------
--=-Zzt3A5Tzpnkf1gPDBX5s
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/
iD8DBQBC09z4KaooUjM+fCMRAq9tAJsGXLds6ZmnVq0x/XXTlQR2sLlV2QCeM/+Z
C9ZzYLmV73CSGK4hOL/ORHg=
=ehvS
-----END PGP SIGNATURE-----
----------------------------------------------------------------->8
What if we added, in addition to the "Comment:" line a line like:
8<-----------------------------------------------------------------
User-ID: jeroen(_at_)unfix(_dot_)org
----------------------------------------------------------------->8
We then know, programmatically, who this key is supposed to represent.
We can then:
8<-----------------------------------
$ dig +short _pgpkey._service.unfix.org any
_pgpkey-http._tcp.unfix.org.
_pgpkey-https._tcp.unfix.org.
----------------------------------->8
PTR records
8<-----------------------------------
$ dig +short _pgpkey-http._tcp.unfix.org. any
"path=/pks/"
42 100 80 purgatory.unfix.org.
$ dig +short _pgpkey-https._tcp.unfix.org. any
"path=/pks/"
13 100 443 purgatory.unfix.org.
----------------------------------->8
TXT + SRV record.
https having the weight, from which we can construct:
https://purgatory.unfix.org/pks/
where a onak cgi is located, basically doing hkp, but then over full
https. (one can also do _pgpkey-hkp for hkp://.... but I don't have a
hkp server on that box, so it is not in DNS)
We then know:
- if DNSSEC would be deployed we for sure would know
the dns answer was valid and that the above servers
are authoritive keyservers for the unfix.org domain.
But we can assume this is pretty correct even without dnssec.
- ssl on the https + the certifacate make sure we
are talking to the correct box.
- the user was able to put his key on the keyserver
running for this domain
Then we can assume:
- when we do a
https://purgatory.unfix.org/pks/lookup/jeroen(_at_)unfix(_dot_)org
that they key returned is valid for this ID.
We can now verify it, giving it some extra 'trust points' because the
domain said this key belongs to it. Or we could require that keyservers
used in this way make sure all the keys get signed by the operator, who
has a key in the strong set. eg large ISP's could automatically generate
keys for their users and sign outgoing mail based on SMTP AUTH, to avoid
people having to do pgp themselves.
Another verification could be comparing that the 'home keyserver', as
found in the key itself,
This brings us distributed keyservers.
Though one still requires to have a lot of keys in a local cache, which
at a certain point most likely is at least 60% of the keys.
Having this field also allows one to specify a nice policy for email, eg
in a SPF record: "pgp:unfix.org", saying that mail send from this domain
has to be signed with a key which has a user-id in unfix.org.
/me now expects an avalanche of comments about many things I did not
take into the sum of the equation ;)
Greets,
Jeroen
signature.asc
Description: This is a digitally signed message part