I propose we use DNS to keep the meeting minutes. Seriously, two things: This should be on namedroppers, and I have some issues with it. Most obvious being that LDAP is already used in this capacity. Secondly, there are multiple mail servers that handle a message. Just look at the headers from an ietf list message. Having each mailserver do these lookups and then sign the message many times is a lot of work, and adds many times more text to the message in the form of signatures. Further down on the list is the comment that mailserver authentication isn't widely used. Only Residential ISPs have per user accounts. Commercial ISPs don't have this data, but still provide relay services to business users. And way down on my list is the point that many devices just send mail, and don't have accounts. --Dean On Fri, 12 Sep 2003, Sergey Babkin wrote: > 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 > >