Let's see if I can boil this argument down to the nub. This started with a claim that there is something unusually dangerous about DKIM so it needs warning labels or hazmat suits to prevent people from using it to chop the net into pieces. The first question is: is this problem unique to DKIM (and maybe a few related techonologies), or is it a general problem that we now are going to worry about all the time? If the former, I need to understand concretely how to distinguish a risky technology like DKIM from a less risky one like, say, S/MIME. (The distinguishing rule should account for details like the fact that the DKIM WG doesn't propose to standardize any authorization beyond keys in the DNS, and that the evidence for partition due to similar technologies like DNSBLs and SPF and S/MIME is pretty thin.) If the latter, I share concerns about gratitous or accidental partitioning, but they really need a WG of their own to produce their own documents to which future work can refer, just as we refer to RFC 3833 when storing new data in the DNS rather than rehashing the fight about how secure the DNS is. If the partitioning issues are particularly related to e-mail, I would be happy to continue them in the ASRG which is overdue for a good argument. If they're for the net in general, it would make a fascinating topic for a WG where we can re-argue how bad private address space and NAT are and whether the ICANN/IANA root is good and whether the de-facto Verisign S/MIME root is bad, and about a hundred other things and wrap it all up in about 2014 just as the last e-mail user gives up and switches to one of three proprietary IM systems. So can people give me guidance? What problem are we trying to solve with the danger warnings? Regards, John Levine, johnl@xxxxxxxx, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf