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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 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
<pbaker(_at_)verisign(_dot_)com> 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: 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html