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

My apologies for being late to this. I was not doing a lot over the  
holidays.
On Dec 28, 2008, at 9:38 AM, Hallam-Baker, Phillip 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.
I think they're quite as interchangeable as he suggests, and I say  
this as someone who produces software that does both OpenPGP and S/ 
MIME. Certainly for this purpose they're isomorphic.
> 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.
I might agree with the second half of that statement, but not the  
first. Of course PGP keys were designed for third party accreditation.  
Thawte and others did that for quite some time, and might actually  
still do it. But you can answer that better than me, as Thawte is a  
Versign company now.
> 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.
I'm not sure how to respond to this. I think a major feature of DKIM  
is that it doesn't require certificates at all.
I buy that many people see value to taking the DKIM key that is in the  
DNS, wrapping it up into a certificate, and certifying it at some  
level. Certainly, you're in the business of doing that, and you  
wouldn't be spending work on certificate customers without the  
reasonable expectation of paying customers who see value in that.
When we were designing DKIM, we were discussing certificates in DKIM,  
and I said then that there's nothing stopping you from taking that  
very RSA key and creating a cert request with it and doing whatever  
you want to with it. That's still true.
*I* don't know why one wants to do that. I don't see the value. I  
think the value in DKIM is that it's simple. But I understand that  
there are people who like complexity in their life and are willing to  
pay other people to make their life complex. Whatever.

> 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.
Gosh, that makes sense. Since OpenPGP is *privacy* and not  
authentication, I suppose we can't do S/MIME in anything that doesn't  
have a MIME encoding, right?
I think you're wrong on that. The major use that I know of for OpenPGP  
is signing things, which I think counts as authentication.
The major reason we didn't use either of them with DKIM was that it  
would have required a change to the way email was formatted, and the  
major ISPs had a requirement that DKIM be invisible to the naive user.  
That meant that putting the signatures into the headers was the only  
viable solution.
> 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.
I'm sorry, this is so wrong on so many ways, Phill.

(1) OpenPGP is a *standard* for a *protocol*. It is not code.

(2) OpenPGP is a descendent of what the original PGP was, and contains  
many things that weren't in the original PGP, and comparing OpenPGP to  
PGP 2 would be like reducing S/MIME to being nothing more than PEM.
(3) Many people have put advanced authentication concepts into code  
that uses the OpenPGP protocol.
I know you don't want to do this, but you're setting up a straw man in  
a forest with a lot of trees and trying to cut down the mightiest tree  
in that forest with a red herring.
> 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)
Then, uh, why not do all of this via XKMS? XKMS is a beautiful  
protocol that has as its only flaw that there's no integration into  
existing systems. Since there's no major practical thing that it does,  
no one does it. Why not rescue it with this, which is something it is  
uniquely positioned to do?
In short -- why invent something new when XKMS is an existing protocol  
that does it? (There are a number of reasonable answers that I can  
think of to this question, like that what you're doing is not generic,  
and generic is often more like a bug than a feature. Nonetheless, you  
describe what looks to me like a reasonable answer to this issue  
yourself. Use XKMS, and get all of them.)
> 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.
Sure, but there's no reason why you can't define certificate  
extensions for generic certificate formats with about three paragraphs  
extra text, especially if you just invoked XKMS, or RFC 4398.
If the real reasons you don't want to do it are that you don't see  
customer demand for doing anything other than a PKIX certificate, and  
the people who want it want to do other things like tie it into EV  
certificates, logotypes, and so on -- then just *say* *so*. That's a  
fine reason. The argument you're making is muddled and wrong. It  
wouldn't be hard to do if you wanted to do it. The point is that you  
don't want to.
        Jon

PGP.sig
Description: PGP signature

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