Re: [dane] draft-wouters-dane-openpgp-01 review
Jelte Jansen <jelte.jansen@sidn.nl> Tue, 07 January 2014 12:23 UTC
Return-Path: <Jelte.Jansen@sidn.nl>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id 2934D1ADBD7 for <dane@ietfa.amsl.com>;
Tue, 7 Jan 2014 04:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.444
X-Spam-Level:
X-Spam-Status: No,
score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55,
HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=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 sSmXy5UdTyBU for
<dane@ietfa.amsl.com>; Tue, 7 Jan 2014 04:23:54 -0800 (PST)
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl
[IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP
id 737C51A1F78 for <dane@ietf.org>; Tue, 7 Jan 2014 04:23:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl;
c=relaxed/relaxed;
h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-originating-ip;
bh=AdhBuc2NNrIfT09ls0E7ZHW1W8bdS3CFB8tWrvvQ0Tc=;
b=KIK+1osHFGaG7BzGrrksa5XEkDXTraVzYqJDnhXVq9FWjfC5tiGoz3i5Xb8a5lPXzcmmWMWEzyU/CO/2Kgk/oO0xwAbPcYCG2bGLdBI6gOI3XctTaVL33gDyqR++n6Fzwzy+Xs9JbWUk84I44xsOE2Fk0RtfzNuBQ42g6n/zu+U=
Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl
with ESMTP id s07CNhiW008075-s07CNhiZ008075 (version=TLSv1 cipher=AES128-SHA
bits=128 verify=CAFAIL); Tue, 7 Jan 2014 13:23:44 +0100
Received: from [94.198.152.214] (94.198.152.214) by kahubcasn01.SIDN.local
(192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1;
Tue, 7 Jan 2014 13:23:39 +0100
Message-ID: <52CBF1CA.4050800@sidn.nl>
Date: Tue, 7 Jan 2014 13:23:38 +0100
From: Jelte Jansen <jelte.jansen@sidn.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>, <dane@ietf.org>
References: <E05CBC7F-1B37-49A0-9E27-D2B52BFA48A9@ogud.com>
<20140107021142.A6C6BC772A3@rock.dv.isc.org>
<alpine.LFD.2.10.1401062246300.5833@bofh.nohats.ca>
<20140107052724.4EBA9C79C09@rock.dv.isc.org>
<20140107054402.GW2317@mournblade.imrryr.org>
<20140107063213.82D61C7A081@rock.dv.isc.org>
In-Reply-To: <20140107063213.82D61C7A081@rock.dv.isc.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.198.152.214]
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>,
<mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>,
<mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 12:23:56 -0000
On 07-01-14 07:32, Mark Andrews wrote: > > All of which is irrelevent provided you can encode that into a policy > which can be transmitted. > >> It is not possible to handle these without substantially complicating >> the logic. One would have to query the domain for the domain's >> recipient delimiter first, and then for the address. > > So. One of the reasons to go with base32 and not raw binary is > that the DNS does normalisation which is potentially different to > the normalisation done by the SMTP server. > > At a minimum we should be able to specifying "no normalisation" vs > "case fold" (and which direction) for ascii LHS. > Seems to me these are both the same issue, and they could either be resolved with one (probably nasty) policy-specification, or not at all (leave 'em out like smtp does). Not a big fan of either :) > Yes, it makes things more complicated but the real world is > complicated. > > Remember that one is comparing this to a SRV record which points > to a key server that does all the normalisation required to return > the correct key 100% of the time. > Are you suggesting this as a possible solution (which sounds more like using DNS(SEC) to specify personal pgp key servers to get around the current pgp key server problem)? (while I type this, I wonder whether this functionality should be on this level in the first place; shouldn't it fit better in smtp itself, which is the only real place that currently know what normalization and other rules apply?) One small thing on the draft itself: IMO the last part of section 2 should not use 2119 terminology; it's not about interoperability nor implementation. Oh and 'sent' should be 'send' :) Jelte
- [dane] draft-wouters-dane-openpgp-01 review Olafur Gudmundsson
- Re: [dane] draft-wouters-dane-openpgp-01 review Viktor Dukhovni
- Re: [dane] draft-wouters-dane-openpgp-01 review Mark Andrews
- Re: [dane] draft-wouters-dane-openpgp-01 review Paul Wouters
- Re: [dane] draft-wouters-dane-openpgp-01 review Paul Wouters
- Re: [dane] draft-wouters-dane-openpgp-01 review Mark Andrews
- Re: [dane] draft-wouters-dane-openpgp-01 review Viktor Dukhovni
- Re: [dane] draft-wouters-dane-openpgp-01 review Mark Andrews
- Re: [dane] draft-wouters-dane-openpgp-01 review Jelte Jansen
- Re: [dane] draft-wouters-dane-openpgp-01 review Scott Rose