On Wed, 2005-07-13 at 10:31 +0200, Simon Josefsson wrote: > Derek Atkins <derek@xxxxxxxxx> 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@xxxxxxxxx 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@xxxxxxxxx ----------------------------------------------------------------->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@xxxxxxxxx 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
Attachment:
signature.asc
Description: This is a digitally signed message part