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

Mark Andrews <> Tue, 07 January 2014 05:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 146571AE435 for <>; Mon, 6 Jan 2014 21:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id feQQSjsm5buY for <>; Mon, 6 Jan 2014 21:26:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 25DF61AE434 for <>; Mon, 6 Jan 2014 21:26:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1EF082383D7; Tue, 7 Jan 2014 05:26:15 +0000 (UTC) (envelope-from
Received: from (localhost []) by (Postfix) with ESMTP id E82DC1602B4; Tue, 7 Jan 2014 05:36:31 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 84FC8160050; Tue, 7 Jan 2014 05:36:31 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4EBA9C79C09; Tue, 7 Jan 2014 16:27:24 +1100 (EST)
To: Paul Wouters <>
From: Mark Andrews <>
References: <> <> <>
In-reply-to: Your message of "Mon, 06 Jan 2014 23:30:54 -0500." <>
Date: Tue, 07 Jan 2014 16:27:24 +1100
Message-Id: <>
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 05:26:40 -0000

In message <>ca>, Paul Wouters wr
> 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?

Yes.  Lots of mail systems use real names and some people have long names.

> How many _real_ +- 50+ LHS character email addresses do people use?

The fact that you can't answer that is the reason you need to support

> 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.

I didn't say enforce one normalisation, though you should specify
how to handle all the forms of Postmaster as that is required to
be treated as a case insensitive value.

> > 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.

And this is not a decision that needs to made by us.  This is a decision
that should be made by the publisher of the data.  One could even have
a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"

> > It should be possible to specify normalisation
> > rules and store them at _openpgpkey.
> But those rules could change if the SMTP implementation changes?

So you update the rules.
> 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.

This is about how to discover the pgp key stored in the DNSN for a
user given a email address.

I know that my email address is in various databases as ""
and "MARKA@ISC.ORG" despite me entering it as "" in
all cases.  I still want those who have stored the address as
"MARKA@ISC.ORG" to be able to find my PGP key.  I do not want to
have to add 31 CNAME records to the DNS to account for all the
permutations of MaRkA.

> > 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.


> Paul
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: