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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 16 Dec 2008 13:21:50 -0800

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.
 
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.
 
Having only one data object to manage is a lot simpler than having separate provision for certs and cert paths.
 
The choice of pkix-pkipath as the path representation is because this is a bona-fide IETF standard and the CMS encapsulation is not. Also, there is a significant chance that at least some CAs have already built out the pkix-pkipath logic to support OMA applications.

I have not filled out the security considerations, just given headlines as it is usually best to discuss the architecture and get that settled first.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 17 Dec 2008 13:45:06 -0000

On Tue, 16 Dec 2008 21:21:50 -0000, Hallam-Baker, Phillip  
<[email-masked]> wrote:

> 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-masked]      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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 28 Dec 2008 08:54:04 -0800

Not sure what you are getting at here.

The draft describes how to glue PKIX certificates to DKIM messages. So the material in it is an extension to DKIM. It is certainly possible to implement a DKIM scheme without this if that is what you mean by 'stand alone'. But it is not possible to extend something without a dependency on what you extend.

-----Original Message-----
From: Mark Delany [mailto:[email-masked]]
Sent: Tue 12/16/2008 6:19 PM
To: Hallam-Baker, Phillip
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] First cut on certificate extensions draft
 
On Dec 16, 2008, at 1:21 PM, Hallam-Baker, Phillip wrote:

	 
	 
	The reason for this is that in the context of DKIM,

Hi Phil.

Maybe the draft didn't render properly for me, but I didn't find anything that described how this actually relates to DKIM directly. Put another way, can this draft stand on its own in the absence of DKIM?

Mark.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 28 Dec 2008 09:38:54 -0800

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.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 29 Dec 2008 12:49:16 -0000

On Sun, 28 Dec 2008 17:38:54 -0000, Hallam-Baker, Phillip  
<[email-masked]> 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.