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. Actually as will become clear, I would not propose using OpenPGP keys for authentication at all. But I would propose using DNS signaling as a means of driving deployment of S/MIME and PGP for encryption. I don't think that DKIM+OpenPGP buys you anything that you do not get with either DKIM or OpenPGP by itself - otherwise I am sure Jon Callas (ccd) would have proposed it. But being able to use the DNS to leverage key discovery for encryption in the same way that DKIM enables authentication would be very valuable indeed. And I propose as much in my book the dotCrime Manifesto, and also explain why it is essential to do BOTH PGP and S/MIME in that case not just one. Note that OpenPGP is Pretty Good PRIVACY and NOT authentication. As with S/MIME the authentication was an afterthought (otherwise DKIM would not have been necessary). Confidentiality was the main story. OpenPGP can be used to provide for integrity, but only after you add in quite a bit of additional mechanism like key servers. Phil Z. did have some really interesting insights into how to do authentication right as well - but he didn't put them into code. 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. 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. The point here is that you want to have a self contained path, that means that you need to have at least three and quite often four or five certs in the chain (offline root, online signing cert, end-entity cert plus typically an offline sub-root for an affiliate or other cross-certified root). Each cert has a minimum of one public key and one signature, which for RSA2048 is 512 bytes per cert for a start. You also need info in an accreditation cert that pertains to the thing you are accrediting (like the brand logo, subject name, certificate policy, extended uses etc). And you also need legal disclaimers to incorporate the CPS and the relying party agreement by reference. It is important to realize that Phil Z's critique of PEM was not just 'you are doing everything wrong'. His (well founded) criticism was that they were solving the wrong problem and in particular they were solving a problem that was far too complex and difficult and that was requiring too much mechanism. Once you decide to do more than base DKIM you are doing more than Phil Z. thought sensible in 1992. You are not going to end up with something that is as slim and elegant as simple PGP. You key blobs are going to be at least as large as for PKIX cert paths, probably larger. -----Original Message----- From: [email protected] on behalf of Charles Lindsey Sent: Wed 12/17/2008 8:45 AM To: DKIM Subject: Re: [ietf-dkim] First cut on certificate extensions draft On Tue, 16 Dec 2008 21:21:50 -0000, Hallam-Baker, Phillip <[email protected]> wrote: > An update of the extensions draft that focuses exclusively on the X.509 > certs extensions is attached. > Note that even though this is intended to be an individual submission, > comments from others are welcome. The point of not making it a WG > charter item is that this work item is not sufficient by itself to > justify rechartering. > This has undergone substantial modification as a result of Paul's input > at the meeting. In particular I realized that there are significant use > cases for both 'call by reference' and 'call by value'. > Another major modification is that in this draft, ALL certificates are > encoded as a MIME application/pkix-pkipath object as described in the > TLS extensions RFC. So even if you have a single self-signed cert, you > have tio wrap it in a path. It is useul to bear in mind the possible use (at some possibly distant date) of DKIM for the purpose of signing Usenet Control messages (which are curently signed by a well-known but not well documented use of PGP signatures). The call by reference method would likely be used. BTW, why should a call by value occupy 4000 bytes of header? For sure, a well-attested PGP key can be stored in far less than that. And is there any inherent problem in using the DKIM signature mechanisms with PGP? A PGP key with a substantial web-of-trust behind it might be less hassle than organizing some accredited CA to sit behind the chain of a 509 certificate. Your mechanism is likely to be used for all sorts of special purpose applications, and it up to the commuminty involved in such applications to sort out what sort of keys they will use and how they are attested. > The reason for this is that in the context of DKIM, a self-signed cert > offers no real advantage over a DNS accredited key, other than an even > lower barrier to entry. As with SSL, I tend to think that self-signed > end-entity certs should be banned anyway, if someone wants to certify > themselves they should set up a CA and have one self signed issuing cert > and chain end-entity certs off it. I take your point about self-signed keys, which are roughly equivalent to PGP keys with an empty web-of-trust behind them. -- 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
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
