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 <[email protected]> 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. > (571) 230-7917 > > A5E5 E373 3C75 5B3E 2E24 > 6A0F DC65 2354 9946 C63A > > > > > On 10/14/15, 11:10 AM, "Sean Leonard" <[email protected]> wrote: > >> >> On Oct 14, 2015, at 6:59 AM, Wiley, Glen <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dane
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
