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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
