Re: not really pgp signing in van

Phillip Hallam-Baker <hallam@gmail.com> Tue, 10 September 2013 16:32 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8488A21F9FB0 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 09:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU4H+MKQBvg1 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 09:32:06 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id C92A811E80D2 for <ietf@ietf.org>; Tue, 10 Sep 2013 09:32:05 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id z5so6458156lbh.14 for <ietf@ietf.org>; Tue, 10 Sep 2013 09:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vwmYo7e3WvgDsiSg4H2rfFSWCL1dUB5D4BICTy1ki+w=; b=H9xXA1oi73FzbLBqw9OfrV9dOVmq3R7yvUKUFoQfbVZWN/Qsy6HBGYgf6i5NfKeO4Y lBNL86BAfdlrPJ7RKcgFUGwTU/dbsUAwxMj8FDEXZ8JGapvld0ynqD9olRa5Skask8m6 uGm9NcJ1WfDZSLVd2cUYf7mCVsw6xLqpziBnDGH7qmjsIscEtM32ioGjakJiQykiyDm4 qZ9paM/zo4Ad4Tn5Giwp0oKSVZ/6OYM/i9KrZsgwo8Qjyt8dpSXyxejOIBoVy0LeLtFy pXJmBvrG2Ex/B5g90ea4b1BOlaF3u9Lgkok+U6vA0rN2Su2gaGpa9EgTQ6aZZmKsVtzN vWHQ==
MIME-Version: 1.0
X-Received: by 10.112.155.39 with SMTP id vt7mr7043262lbb.29.1378830723317; Tue, 10 Sep 2013 09:32:03 -0700 (PDT)
Received: by 10.112.148.165 with HTTP; Tue, 10 Sep 2013 09:32:03 -0700 (PDT)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077527E488@mbx-01.win.nominum.com>
References: <20130910010719.33978.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B63077527E234@mbx-01.win.nominum.com> <alpine.BSF.2.00.1309092125360.34090@joyce.lan> <8D23D4052ABE7A4490E77B1A012B63077527E488@mbx-01.win.nominum.com>
Date: Tue, 10 Sep 2013 12:32:03 -0400
Message-ID: <CAMm+LwhZ9OKesZW+kFct5Gps6_JBzcNUUBQ-y5J21zMcxmL6EQ@mail.gmail.com>
Subject: Re: not really pgp signing in van
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary="089e0112c136780a6204e60a0b2c"
Cc: John R Levine <johnl@taugh.com>, "<ietf@ietf.org>" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 16:32:07 -0000

On Mon, Sep 9, 2013 at 9:41 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> On Sep 9, 2013, at 9:26 PM, John R Levine <johnl@taugh.com> wrote:
> > Um, didn't this start out as a discussion about how we should try to get
> > people using crypto, rather than demanding perfection that will never
> > happen?
>
> Yes.
>
> > Typical S/MIME keys are issued by CAs that verify them by
> > sending you mail with a link.  While it is easy to imagine ways that
> > could be subverted, in practice I've never seen it.
>
> The most obvious way that it can be subverted is that the CA issues you a
> key pair and gives a copy of the private key to one or more others who
> would like either to be able to pretend to be you, or to intercept
> communication that you have encrypted.   I would argue that this is
> substantially less trustworthy than a PGP key!
>

The CA NEVER ever gives the user the key in any of the systems I have
worked on.

VeriSign did offer a key recovery system for enterprise use with central
key generation but the keypair is generated on the enterprise side and
never passed to the CA.


Of course you can _do_ S/MIME with a non-shared key, but not for free, and
> not without privacy implications.   (I'm just assuming that an individual
> can get an S/MIME Cert on a self-generated public key—I haven't actually
> found a CA who offers that service.)


Comodo offers that exact service today.

https://secure.comodo.com/products/!SecureEmailCertificate_Signup


Now this product still has the usual problems of S/MIME and PGP in that
there is no infrastructure that allows a receiver to easily acquire the
certificate (except by bulk query on the CA LDAP server) and there is no
way to know what the sending policy should be.

The key pair is generated in the browser using the Javascript mechanism (as
far as I know, I have not checked but my understanding is that this is how
it works).

Just applied for a cert for Safari on phill@hallambaker.com. Worked fine.


But the process of getting the certificate into my email client is far from
simple. Apple mail certainly has the capability to do S/MIME but the
controls to enable it are buried deep.



> > Same issue.  I can send signed mail to a buttload more people with
> > S/MIME than I can with PGP, because I have their keys in my MUA.
> > Hypothetically, one of them might be bogus.  Realistically, they aren't.
>
> Very nearly that same degree of assurance can be obtained with PGP; the
> difference is that we don't have a ready system for making it happen.
>

I don't see the value of this argument.

We have to fix key distribution. We have to make the CA actions
transparent. That means a redesign of that whole part of the technology. If
we are looking forward to new email systems then we can combine PGP Web of
Trust with S/MIME message formats.


> E.g., if my MUA grabs a copy of your key from a URL where you've published
> it, and validates email from you for a while, it could develop a degree of
> confidence in your key without requiring an external CA, and without that
> CA having a copy of your private key.   Or it could just do ssh-style
> leap-of-faith authentication of the key the first time it sees it; a fake
> key would be quickly detected unless your attacker controls your home MTA
> or the attacked identity's home MTA.


Eliminate the CA and you eliminate the parties with the incentive to sell
the solution.

Whatever scheme is picked to complete secure email there is going to be a
problem finding end users certs and end user policies. And there may be a
market for solving that problem just like there is a market for blocking
spam.

-- 
Website: http://hallambaker.com/