Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt

Viktor Dukhovni <> Wed, 08 January 2014 16:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C422B1AE4D1 for <>; Wed, 8 Jan 2014 08:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id npAuFkucMduq for <>; Wed, 8 Jan 2014 08:02:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BE4781AD9AD for <>; Wed, 8 Jan 2014 08:02:05 -0800 (PST)
Received: by (Postfix, from userid 1034) id 2E9632AB190; Wed, 8 Jan 2014 16:01:56 +0000 (UTC)
Date: Wed, 8 Jan 2014 16:01:56 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
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: Wed, 08 Jan 2014 16:02:08 -0000

On Wed, Jan 08, 2014 at 07:23:21AM -0800, wrote:

> 	Filename        : draft-ietf-dane-smime-04.txt

Given the use of base32 encoding, and explicit non-support for
names that encode to more than 63 bytes of base32 text, I would
like to suggest that trailing "=*" padding be explicitly dropped
from the base32 label allowing for somewhat longer inputs and less
redundant outputs.

With base32, every 5 octets of input text encode to 8 octets of
encoded text, therefore 35 octets encode to 56 octets, but anything
longer encodes to 64 octets which is too long.  Thus inputs with
36-39 octets cannot be represented when the "=" padding is part
of the encoded text.

Also, with say "6" octets of input, e.g. "viktor", we have 48 bits
of input which encodes to 9 full octets of 5 bit per octet output,
plus a short 3 bit encoded octet, and then *7* octets of padding:


This seems rather wasteful.  The truncated encoding:


carries identical information.

Finally is the word "prohibited" appropriate in the new text:

       Also note that user names can be any length, and labels are
       limited to 63 octets.  Also note that user names that are
       encoded with Base32 are longer than the original user name.
       Any user name that would cause a label of longer than 63
       octets is expressly prohibited by this specification.

I would think "unsupported" or "incompatible" would be closer,
since such local parts remain valid, even though there are incompatible
with SMIMEA.

One way to get around the length limit would be to break up long
encoded strings into multiple labels at each 32 bytes of output
(which decode to 20 bytes of input).  Thus the encoding of "Base32
is a notation for encoding arbitrary byte data using a restricted
set of symbols":

    ON4W2YTPNRZQ			// trailing "====" truncated

would result in a multi-label DNS prefix of:


Allowing for significantly longer local parts (ultimately limited
by the total length of a DNS fqdn when combined with the relevant
suffix derived from the domain part).