Thanks to everyone for the pointers! One of the concerns I had is that the idea looks really simple, why nobody has implemented it already? - and it turns out that they already did. Though not exactly in the same way. The SECSH document below is actually for distribution of the fingerprints, not actual keys. Also both of these documents have a very fixed and restricted format for the keys. I think that providing an arbitrary string implementation is easier and more flexible: i.e. you would not need separate standards for ssh and ipv6 - they would be covered by the same record type, with the only difference being the key type field in the value. Joel Jaeggli wrote: > > The problem with public keys is not distribution... The distributions > machanisms we have now work fine. Maybe I'm not up to date with the recent initiatives, but I so far I don't know of any other way to distribute keys to the whole world without registering them with some private repository. > it's getting people to generate > validate and use them. Well, I have the second part of proposal for this. More exactly, for the e-mail application. What's the reason that the users don't use the crypto signatures? Because it's difficult to do with the e-mail software they have or because the whole concept of cryptography is too difficult for them to understand. So it would be nice to move this issue to the infrastructure level to make it transparent to the users. Many ISPs (and IT departments) already require the users to enter a password to send e-mail. So the mail server knows reasonably well who the sender is. What it can do now is write this user information into the e-mail's headers, then calculate the checksum of the whole message and sign it with the mail server's key (and possibly do the same thing for the identity-relation portion of the header). When the addressee receives the e-mail, he can look up the server's private key and check the signatures, to make sure that the sender is who he claims he is. Another easy use comes to the SMTP connection authentication: ask the connecting server for identity, look up the private key on DNS and authenticate through a crypto-challenge. Pretty much the same thing as SMTP allows to do now except for the need to exchange the keys in advance. -SB > On Thu, 11 Sep 2003 Valdis.Kletnieks@vt.edu wrote: > > > On Thu, 11 Sep 2003 22:27:25 EDT, Sergey Babkin <babkin@bellatlantic.net> said: > > > Hello, > > > > > > I think that I've found an easy way to distribute the public keys: > > > put them into DNS. The records would look like: > > > > Go to: > > > > http://search.ietf.org/ > > > > query 'dns public keys' > > > > Of particular interest: > > > > For SSH public keys: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-05.txt > > > > IPSEC keying: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-07.txt > > > > See also RFCs 2536-2539, and all the other DNSSEC RFCs. > > > > > > -- > -------------------------------------------------------------------------- > Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu > GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2