ietf-dkim
[Top] [All Lists]

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

2008-12-28 13:20:31
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
<Prev in Thread] Current Thread [Next in Thread>