On Sun, 28 Dec 2008 17:38:54 -0000, Hallam-Baker, Phillip <[email protected]> wrote:
> I am happy to work with people to 'do the same for PGP'. But I don't > think that the two projects should be combined and I don't think that > PGP and S/MIME are quite as interchangeable as you appear to suggest. > > PGP keys are not designed for third party accreditation, since support > for accreditation is what I am attempting to add here, a PGP scheme > would be an entirely different draft. Yes, but you seem to be trying to concoct a general-purpose solution which may be far too complicated for simple cases involving communities where the entities to be accredited are well known to the people who need to know, and the purpose of the signatures is simply to exclude the various trolls and malefactors who wish to disrupt. That is the sort of environment where a simple-minded scheme like PGP comes into its own. Look at my own signature at the foot of this message. How to you know that key really belongs to me? The answer is that there is an entity that chooses to call itself "Charles Lindsey" that has been exhibiting that fingerprint for the last 12 years or so, and you can find it recorded all over the internet if you want to go looking for it. The example I originally raised was the certification of newgroup control messages on Usenet. The list of keys can be found at ftp://ftp.isc.org/pub/pgpcontrol/PGPKEYS, and that list has been maintained there since at least 1997, and the community of people people who need to know about it know that it is there. Not a Certification Certificate in sight. It ain't broke and it don't need fixing. What _does_ need fixing is the signing protocol that lies behind it, which is poorly documented and in severe need of cleaning up (hence my suggestion that moving to DKIM might be a way to fix it). > As with the PKIX approach, there is only value to doing an OpenPGP > binding if you are going to get something more from it than you already > get from the existing DKIM DNS key distribution scheme. That means doing > more than the absolute bare bones PGP key signing. How much more I don't > know, but certainly more than just a fingerprint and probably more than > one key signing. We are entering areas that are certainly possible with > PGP in theory, but practical experience is thin. But no, DNS is NOT the way to go for that particular application (though it is entirely appropriate for other applications). All that is needed is a means to refer to a suitable URL, as in your proposal, plus reorganizing that site (and others that may mirror it, to use whatever format PKIX might require. > > > The way I would add in support for PGP to DKIM would be to add in a link > to XKMS which serves as a multi-protocol key-server. Significantly, one > of the authors of XKMS, Brian LaMachia was also the author/maintainer of > the MIT Key Server for PGP. (Some other DKIM folk were also involved) > > A PKIX cert Path is currently 4000 bytes plus. That is a measurement > taken from the PayPal cert chain. Which is a good argument for using a URL to access the key by reference. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
