Re: [dane] Encoding local parts in better ways

[Sean Leonard <[e-mail]>]

Correct, it says base32 encoding. I am not saying to interpret it otherwise.

I am saying that the animating principle of Section 4 “Encoded bytes” is to transform the local-part into a form that preserves case sensitivity.

So yes, perhaps Section 4 should be expanded to include the different types of transformations: reversible, irreversible, and irreversible with collision resistance. (In this context, collision resistance is a pretty important property, so just “irreversible” may not be a useful sub-category.)

Sean

On Oct 14, 2015, at 8:14 AM, Wiley, Glen <[e-mail]> wrote:

> Section 4 reads as though it is specifying base32 encoding, as it is
> written I don’t see room for interpreting that as allowing for a hash.
> -- 
> Glen Wiley
> 
> Principal Engineer
> Verisign, Inc.
> [phone]
> 
> A5E5 E373 3C75 5B3E 2E24
> 6A0F DC65 2354 9946 C63A
> 
> 
> 
> 
> On 10/14/15, 11:10 AM, "Sean Leonard" <[e-mail]> wrote:
> 
>> 
>> On Oct 14, 2015, at 6:59 AM, Wiley, Glen <[e-mail]> wrote:
>> 
>>> John,
>>> 
>>> I read the draft.
>>> 
>>> In the list of approaches you include literal, encoded, regex and
>>> pointer
>>> but I didn¹t see a place to refer to hashes (such as SHA224).  While
>>> there
>>> are different views on the use of hashes for local parts, would it makes
>>> sense to allow for the future use of a hash?
>> 
>> Probably makes sense conceptually as a sub-part of “encoded” (Section 4).
>> Some encodings are reversible (e.g., base32); others are one-way (e.g.,
>> CRC); yet others are one-way and also collision-resistant (e.g.,
>> SHA-224). The commonality that they share is that they preserve the
>> byte-for-byte/case-sensitive matching of SMTP.
>> 
>> Sean
>> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane