Re: [dane] draft-wouters-dane-openpgp-01 review

Paul Wouters <> Tue, 07 January 2014 04:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A2DC81AE428 for <>; Mon, 6 Jan 2014 20:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.338
X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RP_MATCHES_RCVD=-0.538] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DJM8htZafgk6 for <>; Mon, 6 Jan 2014 20:31:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4DC571ADF7B for <>; Mon, 6 Jan 2014 20:31:03 -0800 (PST)
Received: by (Postfix, from userid 500) id 51D6A80055; Mon, 6 Jan 2014 23:30:54 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1389069054; bh=xlx+xPs6PO1HNGJzH98LCCwxiu9cLZhxXtY+WSwf7aA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hXD/Qm9magPBEmwlsNpPC6O2fJI5rKZYon8PI7AufiGNfgxPCSD7MVQ3IKkIYRKWu PzRGxiMAf4FW0I4C9CD3Ux7y1OgkTnJSbuTZWBEdPVk4J/O5E2Za4F13qXziTyI3Z9 jIUUGPle9ZAvOHGKh1LlkhrDomchM6naBPGRj67I=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4185E80048; Mon, 6 Jan 2014 23:30:54 -0500 (EST)
Date: Mon, 6 Jan 2014 23:30:54 -0500 (EST)
From: Paul Wouters <>
To: Mark Andrews <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: " list" <>
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jan 2014 04:31:04 -0000

On Tue, 7 Jan 2014, Mark Andrews wrote:

Thanks for the review Mark.

> Section 3.1 has lots of factually incorrect rationals for
> encoding using base32.  The DNS is capable of encoding
> binary data in labels up to 63 octets.  I've got no problem
> with encoding, but if one intends to include rationalisations
> please make them factually correct.

I took those from draft-hoffman-dane-smime-01, Paul Hoffman and
Jacob Schlyter believe these to be right as well? Can you explain
what's wrong or perhaps write a replacement paragraph that would
agree with you more? It's mostly there to explain why we did not
end up using and require base32 encoding.

> There is no mention of how to encode LHS which exceed 63 octets
> when encoded using base32.  Pack the left most labels or the
> right most labels?

Is that really a use-case we need to cover? How many _real_ +- 50+ LHS
character email addresses do people use? I'm happy to document the
limitation, a little more reserved for specifying tricks to go beyond.
For example, mentions this limit too
in context of UTF8,unicode,Kanji without defining anything to extend
this limit.

> There is no mention of how to normalise LHS prior to base32 encoding.

That was discussed offline, but you are right in that the result of
that discussion is missing. Since there seems to be great variety in
how SMTP servers normalise the LHS, we did not want to enforce our
one normalisation.

> Are "Hugh" and "hugh" the same?

That really depends on the SMTP server implementation, the OS it runs
on, the email client used by the sender, etc.

> Should "hugh" and "hugh+xxx" be treated the same?

I don't think so? The "+" sign as magic "this is the same user as"
is also not a feature supported by all SMTP servers or specified in
a standard, correct? And people might want to use different keys for
paul+personal versus paul+ietf.

> It should be possible to specify normalisation
> rules and store them at _openpgpkey.

But those rules could change if the SMTP implementation changes?

So, this document is leaving these as unclear as whether your email
will arrive at all or not based on the presence or absence of
normalisation rules of the SMTP server.

> It might be useful to suppress the padding at the end of base32
> encoded strings.  We already do similar suppression with NSEC3
> records.

Unlike NSEC3 we will see some interaction with userland tools and humans
that will use stock base32 that produces the padding. So I have a slight
preference to stick with the output generated by standard base32 code in
the hope that it will be less confusing to users and developers.