The question in my view is what you intend to do with the certificate information.
Let us consider some outsourcing cases: A) Alice writes a blog, she has her own DNS name and the Web site is hosted as a virtual Web server on a machine with 1000 other blogs B) Bob writes a blog, but he rents use of a whole machine, not just a virtual partition. C) Carol writes a blog and also sells T-shirts with witty slogans on that people buy through a hosted checkout. D) Doug runs a business with a large e-commerce shop and manages the credit card data directly. Question, which ones of these should be using SSL? Answer, all of them. Question, which identity should the application client be presenting to the user. Answer: Doug is the only party that has a corporate identity. Alice, Bob and Carol probably don't want to reveal their personal identity so the only identity we have that we can present is a domain name. The reason I raise this is that I see several possible conclusions that can result from cert processing query: 1) Organizational Validation or Extended Validation that establishes accountability. 2) Certificate is bound to the domain name on which the resolution process was begun 3) Certificate is bound to a domain name to which the resolution points 4) There is no particular connection between the cert and the domain name. Which outcome is sufficient depends on whether your objective is to turn on use of crypto or tell the user that they are safe. Another point to bear in mind is that applications are not necessarily applying the traditional SSL model in which the application looks at the information provided by the Web site and determines if that meets a particular safety threshold and the user is responsible for working out if they are safe or not. For the past five years or so, the model that has been emerging is one in which the application takes data from multiple sources and fuses them to establish a safety evaluation. For example, if a domain name is on the Anti-Phishing Working Group suspicious URL list, the browser might well want to block access regardless of whether the Web Site has a certificate or not. So rather than having a spec state what is 'safe' and what is not. We really need to look at how many potential points of vulnerability have accumulated. Running Web servers and running DNS servers 24/7 is complex and time consuming. There are clear economies of scale. So people are inevitably going to outsource. The number of potential points of vulnerability are a consequence of the outsourcing and not the use of CNAME. The use of CNAME is merely a consequence of the easiest way to implement outsourcing. More points of vulnerability does not correspond to higher risk. What matters is the vulnerability of the weakest link in a chain (or the weakest critical path in a redundant mesh). On Thu, Sep 16, 2010 at 1:39 AM, Matt McCutchen <[email protected]>wrote: > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > Clearly unsafe operations: > > > > - building a reference identifier from the result of a > > DNS CNAME lookup > > > (the use of DNSSEC does not make this safe) > > Why not? I'm not saying it's good practice, but I don't see an actual > vulnerability. > > I agree with everything else you said; nicely put. > > -- > Matt > > _______________________________________________ > certid mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/certid > -- Website: http://hallambaker.com/
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
