On 1/8/14 11:48 AM, "Paul Hoffman" <[email protected]> wrote:
>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.txt >> >> Given the use of base32 encoding, and explicit non-support for >> names that encode to more than 63 bytes of base32 text [snip, include all useful context ;-)] >Yes it does. It also puts a burden on the application to use our new >"base32ish" encoding instead of the base32 encoding they already have. In >order to save five bytes. > >> 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. > >You are right: we'll change to "incompatible" in the next draft. Let's see if I understand the purpose of the original proposal (base32 encoding of local-part/"local part"), the limitations, and the counter-proposals. These are for deterministically putting something into DNS, and for deterministically finding the thing that was put into DNS. The RHS is the interesting thing (e.g. smime stuff), and the LHS just has to be deterministic, right? The input can be either non-international (arbitrary length ASCII characters, bytes with first bit 0) or international (arbitrary length strings of UTF8). Even adding a distinguisher between the two input sets, at best would only optimize fixed-upper-limit functions (7 onto 5 or 8 onto 5 encoding schemes with 63 character max). So instead of "encoding" per se, what about using a hash function? It does not have to automatically be an existing hash function, although re-use of the NSEC3 code might be reasonable. All that matters is that the probability of hash collisions is very very low, and perhaps the addition of some collision-mitigation would help. LDH = 26 alpha + 10 digit + hyphen = 37 characters 37^63 is a big big number (about 100 decimal digits starting with "6"). It means on average the lhs is longer, but in practical terms removes the upper limit on the encoding (since the hash function has no upper limit on input). We're talking about stuff that hasn't yet been developed, right, so a major shift in LHS stuff is no biggie? Brian _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
