[ Quoting <[email protected]> in "Re: [dane] Call for Adoption: draft..." ] > In general, I support the idea of what this document is trying to do. But > there are a couple of problems with their concrete approach. Without delving > into a full review… > > -- The algorithm for domain names is really insufficient. For example, I have > the email address [email protected] -- how do the dots get > encoded? I realize that the DNS wire format allows labels to have dots, but > good luck making most libraries make that query.
Huh? Reading from section 3: (http://tools.ietf.org/html/draft-hoffman-dane-smime-04) Design note: Encoding the user name with Base32 allows local parts that have characters that would prevent their use in domain names. For example, a period (".") is a valid character in a local part, but would wreak havoc in a domain name. Similarly, [RFC6530] allows non- ASCII characters in local parts, and encoding a local part with non- ASCII characters with Base32 renders the name usable in the DNS. > -- I don't really see why we need a new RR type here, beyond the cognitive > dissonance caused by the three letters "TLS". new RRs are cheap. Why not get one? grtz Miek
signature.asc
Description: Digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
