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

[Paul Wouters <[e-mail]>]

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 username._openpgpkey.domain.com 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, http://tools.ietf.org/html/rfc6763 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.

Paul