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

[[e-mail]]

Zitat von Paul Hoffman <[e-mail]>:

> On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni <[e-mail]> wrote:
>
>> On Wed, Jan 08, 2014 at 07:23:21AM -0800, [e-mail] 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.
>
> In the real world, there are few users who have LHS user names that  
> are more than 30 (or maybe even 20) characters long. What you are  
> proposing is "base32 but not really base32" and that could introduce  
> errors in libraries looking up the names.

Not followed closely on the topic but LHS part of e-mail addresses  
with more than 20 characters are common here in Germany because of the  
schema which uses <Vname>.<Nname>@domain. With the double lastname  
this will even get <Vname>.<Nname1>-<Nname2> in some cases. With names  
from other contries this could be even worse like the following  
(slightly modified) example show:

Dr.Massouf.Najani.Maryam.Nemari

Furthermore "descriptive" e-mail addresses are often used, for example  
"wirtschaftsrat-deutschland", "Redaktionsservice-Buch" and the like.

An short estimate on our input relay would be around 5% > 20  
characters and <1% with more than 30 characters. But IMHO one should  
try to avoid to limit the useable scope from the begining as far as  
possible, no?

Regards

Andreas