None of them make any sense to me. The problem with DANE is that they had two agendas and only made one public when they asked for the group to be formed. What they purported to be doing was to make it possible to use the DNSSEC to establish keys. What they were really about was trying to replace CAs.
One consequence of that positioning was that they could not accept any advice from any of the people who work with CAs as they imagined all such advice was designed to sabotage their efforts. Which meant that they began by cutting themselves off from all advice from people with practical experience of what they were attempting to do. The key usages are the product of their ideological baggage. The descriptions are confused because the thinking behind them is confused. It is one of those plans that begins 'well first lets knock down all the buildings and then decide what to replace them with'. Problem is that people who start with that sort of plan rarely get beyond the first stage of knocking everything down. Downtown Niagra being a prime example of the result of that type of thinking. CT seems a much better idea because it is designed to reinforce the existing infrastructure rather than define it as the problem. The big problem with DANE is that it relies on people putting correct information into the DNS and keeping it correct even when it is going to have (initially) marginal impact on functionality. Information in DANE could be useful for some parties to use to curate certificate data in combination with other data but it isn't viable for client enforcement in an end to end model. CT data is much better for enforcement as it is going to be managed by a small circle of parties who are specialists in managing that type of data. Any plan that relies on the typical Webmaster doing anything different is unlikely to succeed. They already have more problems than anyone in IETF land can imagine. On Mon, Oct 22, 2012 at 7:42 AM, Ben Laurie <[email protected]> wrote: > On 22 October 2012 09:44, Alexander Gurvitz <[email protected]> wrote: > > Hello. > > > > I don't quite understand what is the purpose of Cert. Usage 0 and 1 TLSA > > records ("CA constraint" and "Service Certificate Constraint"). If we > trust > > DNSSEC and TLSA, we need no CA at all, and if we don't trust DNSSEC/TLSA, > > what's the purpose of having any information in the TLSA ? The only place > > such CA/cert. constraint makes sense to me is the certificate itself, > HSTS, > > or some checkbox in a browser setup. > > Two of these three don't make any sense to me! > > A CA/cert constraint in the certificate seems pointless - for a start, > the cert is already signed by some particular CA, and secondly, why > would an evil certificate constrain itself into non-operation? > > Likewise, checkbox in browser setup - what would this checkbox do? > Pick a CA for every site on the 'net? How? > > CAs have been arguing in other venues that using TLSA to validate in > the browser is inferior to using CAs because CAs are prepared to > revoke certificates that are used for bad things, whereas DNS > registrars/ICANN are not. > > OTOH, CAs don't necessarily even no they've issued a cert to revoke, > if we look at history. And, of course, not all CAs have the same view > of what is bad. > > This is, of course, why Certificate Transparency exists, so everyone > can see what's going on. Neither TLSA nor CAs are adequate, IMO. > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
