Zitat von Paul Hoffman <[email protected]>:
On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni <[email protected]> wrote:On Wed, Jan 08, 2014 at 07:23:21AM -0800, [email protected] wrote:Filename : draft-ietf-dane-smime-04.txtGiven 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.NemariFurthermore "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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
