On Monday, September 24, 2012 at 3:49 PM, Miek Gieben wrote: > [ Quoting <[email protected] (mailto:[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] > > (mailto:[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) >
Thanks. That's what I get for replying to email under the influence of jet lag. > > > -- 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? Why *would* you? The cert/chain matching semantics are the same, the only difference is how you get the cert/chain (S/MIME vs. TLS). New RRs are not *that* cheap. Yes, servers and resolvers usually do let you provision arbitrary RR types by number, but that's not nearly as nice as having a real syntax, which takes time to develop and deploy. If you've got TLSA and you just need people to look for it in a different place, why bother going to the effort of making everyone support a new type? --Richard > > grtz Miek > _______________________________________________ > dane mailing list > [email protected] (mailto:[email protected]) > https://www.ietf.org/mailman/listinfo/dane > >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
