> These arguments are going beyond silly and reaching ludicrous. Yes, some > ISPs do stupid things. That's when you choose a different ISP or come up > with some workaround. Yes, there are broken DNS servers out there that > can't handle TCP queries. Get an unbroken DNS server, there are plenty. > Yes, there may be fragmentation issues, however we are going to have to deal > with this if we're ever going to deploy DNSSEC. well, all of the above is sort of besides the point, because you really don't need to use DNS to return certs (and there are a lot of problems with doing so) - you still get to leverage DNS if you simply define a way to use DNS to obtain certs with a different protocol (say, using SRV records). then you don't have to stand on your head to try to fit the certs into DNS and/or adapt DNSSEC to the needs of your particular app. the trust issues are a separate matter. but again, if you get away from trying to make DNSSEC do this job then you can just build a query mechanism for certs that responds to the addresses/ports in those SRV records, and let each host/site/application decide whether the certs that come back are sufficient for its particular needs. and you don't need any kind of distinguished cert or cert hierarchy to make that work. of course if DNSSEC can help validate the SRV records, discourage denial of service attacks on the DNS lookups used to find keys, or provide additional means to validate keys, that's all well and good. Keith