Derek Atkins writes:

...

is a URL just too big? My sigs are already several lines long. E.g.,

Key: ftp://ftp.clark.net/pub/cme/cme.asc

IMHO, yes. Consider for a minute: there are currently about 20000 PGP keys on the public keyservers. There are about 30000 signatures on those keys. The keyrings are already 8MB or more.

Now, consider adding a URL to every signature. Lets even use your URL, which is 35 characters long (and lets not even count the NULL or length byte). Adding this URL to 30000 signatures would add 1050000 bytes, or just over 1MB. This is an increase in 12% of the keyrings!

Yes, but we have to assume that the need for central key servers would go away if we had a way of distributing the data around, which would reduce the problem substantially...

On the other hand, using my method and your "URL" (clark.net) would add only 10 bytes per sig, or 300k. This is only a 4% increase.

By the way, a lot of this discussion should probably also be taking place on SPKI. Perry

...

Now, consider adding a URL to every signature. Lets even use your URL, which is 35 characters long (and lets not even count the NULL or length byte). Adding this URL to 30000 signatures would add 1050000 bytes, or just over 1MB. This is an increase in 12% of the keyrings!

Yes, but we have to assume that the need for central key servers would go away if we had a way of distributing the data around, which would reduce the problem substantially...

...

On the other hand, using my method and your "URL" (clark.net) would add only 10 bytes per sig, or 300k. This is only a 4% increase.

The current PGP keyring model does not scale anyway. Suppose one day every user on the Internet will have a key... It is not relevant whether the space per key is 100 bytes, 1000 bytes, or 10000 bytes. All of these sizes are small enough for it to be quick to transfer a single key. There will soon be no way to transfer and store the entire key ring. In the long run, the problem must be solved using an entirely different, distributed architecture. Tatu

In suggesting key:// urls, I (without commenting) placed a path of /s/telnetd/ in a URL. I was considering that a telnetd might need many keys and associated documents, all of which could be found in a directory. gateway's master telnetd public key. daily keys policy statements about who may connect, or how etc I expect that we could extend the syntax in such a way that a URL could contain most of the data we need. Thus, the default document might be a 'cert of the day,' with possibly with references within the certificate to the master telnetd key, the hosts master key. To expand, I was thinking of: key://foo.bar.com/{u,s,h,d}/family/instance The first two bits, the scheme (key) and host are pretty clear. They're followed by an (arbitrary) grouping, of User, System, Host or Domain. User is for user space certificates, such as personal certs, or possibly currently in use IPv6 keys. System is for system daemons, such as telnetd. Host is for host certificates, such as might be generated for a host to sign its daemon's keys. Domain could be analogous to host, but for an entire domain. Family is for natural groupings, such as telnetd or adam, or within a domain, certificates by host. An thus a host's certificates would be available under h/main/cert.asc or d/mailhost/cert.asc. It would be possible to extend this by date, to d/mailhost/96/march/cert.asc Instance would then be the particular certificate, in a standardized namespace. These are no longer particularly short in the verbose version, but they are capable of being optimized (by ommission) for the usual cases. Adam Perry E. Metzger wrote: | Carl Ellison writes: | > Key: ftp://ftp.clark.net/pub/cme/cme.asc | | URLs are nice, but I'm not quite sure they are sufficient in practice, | though they are certainly theoretically sufficient. If I get a | document from someone, and it is signed, I'd like to be able to get | the key associated with the signature, and the URL is in theory enough | to do that. However, going in the opposite direction -- retrieving a | key associated with, say, a remote host's TELNET server, I'd like to | be able to query a server ask much more flexible questions than an FTP | URL would let me ask -- I might have a prefered public key system (RSA | versus DSS or what have you), I might want to be able to distinguish | between versions of the key, I might want to ask for all keys of a | certain class, etc. | | In the end, we are probably going to need something in the way of key | servers, which may (or may not) imply either a new type of URL or | something other than a URL to do retrieval off of. | | Perry | -- "It is seldom that liberty of any kind is lost all at once." -Hume

Eric Murray wrote: | > key://foo.bar.com/{u,s,h,d}/family/instance | While that would be useful in a lot of cases, I would hope that | all that path gunk wouldn't be required.... most people would | have one key, at least initially, and so a simple | | key://foo.bar.com/username/key.asc | | would be enough for them. I wouldn't want to prevent people | from using your system, in fact it's a good idea. I just don't think | that it should be required, just recommended. | Something else to add would be a specifier for the type of key, i.e. | | key://slack.lne.com/pgp/ericm/key.asc I'd either move that later in the structure, or leave it out. Moving it later in the structure so we don't need duplicate heirarchies. Leaving it out may be ok because we can define a standard location by key type: key://slack.lne.com/~ericm/key.asc key://slack.lne.com/~ericm/key.x509 key://slack.lne.com/~ericm/x509/key.cert key://slack.lne.com/~ericm/pgp/key.asc I have no objection to defining a shorter URL, but would want some indicator that we're in user space, not host/domain/realm space. A ~username serves that purpose as well as /u/ and is a more common usage. My last comment is that if we define a URN scheme for keys, we should force a dependable structure on it, so that its predictable where to find a users PGP key from an email address, without having to check 6 locations. Nothing is there now, we should require order to make everyones life easier. | Finally, a question: should the keyserver be able to serve | keys in a way that is secure from a MITM attack, or can it depend | on the certificate chain in the key certificate itself to | validate the key certificate? I think it can, but I am not | sure, so perhaps someone smarter than I can explain why, or why not. | | The attraction is obvious, if the key server doesn't have to | validate the keys it serves, the whole problem of distributed | key servers becomes much easier. A key server should serve keys because protecting from MITM is hard. Serving keys is easy, so we should solve that problem today, and the other problems as we can. Some infrastructure is better than none. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume

In the end, we are probably going to need something in the way of key servers, which may (or may not) imply either a new type of URL or something other than a URL to do retrieval off of.

Sorry for the stupid questions, but I want to make sure I'm on the same page as the rest of you. Correct me where I'm wrong -- The idea to have a distributed database (like DNS?) that allows you to retrieve keys with query strings similar to urls. So if you wanted to do a secure telnet to host.foobar.com, you'd submit something like "telnet://host.foobar.com" to the key server, and it would give you back a key. If you wanted to send mail to me, you'd submit something like "mailto://alex@suba.com". Etc. The key distribution system wouldn't address the problem of trust directly, but the key you'd get back from the server would contain information that you could use to verify it. Suppose I get signed email from Perry. The signature would contain something like "mailto://perrry@piermont.com" -- I could use that to get Perry's key to verify the signature. Along with Perry's key I'd probably get a signature from some entity that vouches for his key, maybe a piermont.com key. I could follow the chain up until I hit an entity I trust. If this is correct, I have a question: What's the advantage of using this url type system instead of "fully qualified" certificates, ie., attaching all the keys and signatures to the object? Doesn't the give and take with the key servers more than wipe out the advantage of the smaller data object? Does the win come from solving the revocation problem? Finally, does anyone know if anything's been happening with Matt's key management project?

Alex Strasheim wrote: | What's the advantage of using this url type system instead of "fully | qualified" certificates, ie., attaching all the keys and signatures to the | object? Doesn't the give and take with the key servers more than wipe out | the advantage of the smaller data object? | | Does the win come from solving the revocation problem? The win from a referenced system can come in two places. First is standard places for keys, so I can ask a host for its telnetd's key simply. Second is that I may already have cached some of the keys, and not need, for example, they key for toad.com/s/sendmail/ Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume