ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] First cut on certificate extensions draft

2008-12-29 08:33:35
On Sun, 28 Dec 2008 17:38:54 -0000, Hallam-Baker, Phillip  
<pbaker(_at_)verisign(_dot_)com> 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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      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

<Prev in Thread] Current Thread [Next in Thread>