On Sat, Mar 22, 2008 at 10:59:18AM +0000, Ben Laurie wrote: > [EMAIL PROTECTED] wrote: > >On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote: > >>From time to time I hear that DNSSEC is working fine, and on examining > >>the matter I find it is "working fine" except that .... > >> > >>Seems to me that if DNSSEC is actually working fine, I should be able to > >>provide an authoritative public key for any domain name I control, and > >>should be able to obtain such keys for other domain names, and use such > >>keys for any purpose, not just those purposes envisaged in the DNSSEC > >>specification. Can I? It is not apparent to me that I can. > > > > > > actually, the DNSSEC specification -used- to support > > keys for "any purpose", and in theory you could use > > DNSSEC keys in that manner. However a bit of careful > > thought suggests that there is potential disconnect btwn > > the zone owner/admin who creates/distributes the keys as > > a token of the integrity and authenticity of the data in > > the DNS, and the owner/admin of the node to which the DNS > > data points. > > So far, so good. This disconnect doesn't seem to have done the CA > industry any harm, though.
The CA business -is- to serve as a "notary" They attest to the binding o fthe key to holder. To date, thats NOT what a zone admin does, he is attesting that its HIS key, that it is HIS record in HIS database. Just because he has sold the right to use to someone else, is still his database and his data. Unless of course Nominet (for example) is now going to allow client driven dynamic updates - where the clients are in complete control of their data. (thats closer to James, assertion that he owns/controls his domain name) > > > Remember that while you may control your forward > > name (and not many people actually run their own DNS servers) > > it is less likely that you run your address maps - and for > > the paranoid, you would want to ensure the forward and > > reverse zones are signed and at the intersection, there is > > a common data element which you can use. > > Non sequiteur, plus I can't see why paranoia would prompt me to want to > do this? What does it prove? The argument is, again, to James asserton that he owns his domain name. In point of fact, every node has at least two "names" in the DNS, the forward (which gets most of the attention) and the reverse - which is nearly always controled by your ISP. DNSSEC validation along one path in the DNS graph is reassuring (or so it is claimed). I posit that validation over two, generally non-overlapping administrative spheres of influence, in the DNS graph would give a higher level of assurance. Couple this with finding the identical x509 cert at the origin of the validation chain for both paths - and I think I have a much higher confidence that I am actually going to be sending packets to the "right" node. > Also, PTR records are only supposed to point to "primary domain names". > Since it is common for hosts to have many names resolving to the same IP > address, by definition most of these will not correspond to the reverse > lookup. Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. > > To do what you want, want, you might consider using the > > CERT-rr, using the DNS to distribute host-specific keys/certs. > > And to ensure that the data in the DNS was not tampered with, > > using DNSSEC signed zones with CERT-rr's would not be a bad > > thing. In fact, thats what we are testing . > > Who is "we" and what exactly are you testing? We is USMIR, the registry for .UM - www.nic.um --bill > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.links.org/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]