Re: [pkix] [smime] Key lookup service via draft-bhjl-x509-srv-00

"John Levine" <johnl@taugh.com> Fri, 25 March 2016 15:59 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D312DADF for <pkix@ietfa.amsl.com>; Fri, 25 Mar 2016 08:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPn-s4xucbuC for <pkix@ietfa.amsl.com>; Fri, 25 Mar 2016 08:59:07 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6082012D121 for <pkix@ietf.org>; Fri, 25 Mar 2016 08:59:07 -0700 (PDT)
Received: (qmail 14804 invoked from network); 25 Mar 2016 15:59:05 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Mar 2016 15:59:05 -0000
Date: Fri, 25 Mar 2016 15:58:43 -0000
Message-ID: <20160325155843.13079.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: pkix@ietf.org
In-Reply-To: <56F45AFB.50802@nthpermutation.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/jRe8p8VST2jOUGT4f1apFZNsu5M>
Subject: Re: [pkix] [smime] Key lookup service via draft-bhjl-x509-srv-00
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2016 15:59:09 -0000

>> Right.  When you come up with a way for my MUA to fetch a key from 
>> your MUA when you have never sent me a message, let us know. 
>
>Is it possible that you're both using the wrong term above?  E.g. MTA vs 
>MUA?

No, this is the classic mail crypto model from the 1990s.  The
endpoints know the secrets, the intermediate nodes aren't trustworthy.
We are all familiar with vast popularity of crypto schemes that work
this way like, um, and er.

>I would expect it might be possible for a user to arrange to have its 
>inbounds MTA configured with some amount of data related to the user's 
>delivery email address, and I would also expect that such data could be 
>retrieved from the MTA by an MUA wanting to send email to that delivery 
>email address.

That's what DEEP does.  It has the practical problem that due to the
plague of botnet spam, most MUAs can't directly talk to remote MTAs,
only to their local MSA, so it needs a kludge to proxy the retrieval
MUA->MSA->remote MTA->MSA->MUA.  One of the reasons we wrote our draft
is that it does the lookups over https, which most MUAs already know
how to do.

R's,
John