Re: A brief comparison of email encryption protocols

-----BEGIN PGP SIGNED MESSAGE-----

At 15:54 2/29/96, Derek Atkins wrote:

>So, there needs to be a compromise, some shorthand method to describe
>the hint.  One solution is to provide a "keyserver" type and then some
>string that says which "keyserver" to use.  For example, if there is a
>DNS-style keyserver deplyed, I could put '1,"mit.edu"' in all my
>signatures, if we assume that '1' is the DNS-style keyserver code.
>
>I'm sure there are other possible solutions as well, and any real
>suggestions are welcome.

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

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

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMTYY/1QXJENzYr45AQFr5QQAkff2u+VvCvpPYTyYCVsj1NFMD/dsN+Ps
Dyc7cX4iMDynls+dibG8cTAw6FrqKtvZ6qSDdu15oI49rHiEzTZOWj/VUKjlalmu
rp0QZ7iSiYinsHFK4H/ZfWarx/3RfngGFXjNOLQUjpe0Otqz1nnHqaVkCXPbz/VG
gmQbMKn5syA=
=hKEC
-----END PGP SIGNATURE-----

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091      Tel: (703) 620-4200                                 |
+--------------------------------------------------------------------------+

> 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!

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.

-derek

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

> 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...

Oh, of course the central keyserver model would disappear, but I'm
still trying to design a system which is as compact as possible.

-derek

> > 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

Carl Ellison writes:
> At 15:54 2/29/96, Derek Atkins wrote:
> >So, there needs to be a compromise, some shorthand method to describe
> >the hint.  One solution is to provide a "keyserver" type and then some
> >string that says which "keyserver" to use.  For example, if there is a
> >DNS-style keyserver deplyed, I could put '1,"mit.edu"' in all my
> >signatures, if we assume that '1' is the DNS-style keyserver code.
> >
> >I'm sure there are other possible solutions as well, and any real
> >suggestions are welcome.
> 
> is a URL just too big?  My sigs are already several lines long.  E.g.,
> 
> 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

> 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 writes:
> 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.

That wasn't actually what I had in mind. When I said a new URL I meant
something like key://foo.bar.com/bleh/blah/foo, to go with the new key
server protocol.

I'm not exactly sure what the key servers should take as lookup values
-- that is, at this point, a matter for discussion.

> Finally, does anyone know if anything's been happening with Matt's key
> management project? 

Matt does, I presume...

Perry

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

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

Adam Shostack writes:
> 
> 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


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

The reason for the keytype specifier is obvious, so that the
system can support more than just PGP keys.  The problem with
the above example is that the 'pgp' part is imbedded in the path.
Since the apps that read these key URLS need to know which ones
are for PGP and which for DH or DSS or whatever, the keytype
specifier needs to be in a standard location in the URL.

Suggestions?  maybe key:/pgp/slack.lne.com/ericm/key/asc?
 

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.



-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

[I've changed the Subject: because this now has very little to do with
email encryption protocols]

Eric Murray writes:
> 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, 

The certificate should be able to stand on its own. Anyone can already feed
arbitrary certificate data to you via the keyserver, just by submitting it to
the keyserver in the usual way. 

However, a MITM can mount some denial-of-service
attacks by removing sigs. from a cert., or substituting some certs. for
others, or stopping the delivery of some certs. If the keyserver signs
responses by default, then an ordinary active attacker (non-MITM) couldn't
do DoS at finer granularity than the scope of each signed piece.

> so perhaps someone smarter than I can explain why, or why not.

Disclaimer: My decision to reply to your message should in no way be 
construed as implying a judgment on my part about our relative intelligence :)

-Lewis	"You're always disappointed, nothing seems to keep you high -- drive 
	your bargains, push your papers, win your medals, fuck your strangers;
	don't it leave you on the empty side ?"  (Joni Mitchell, 1972)

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

Carl Ellison wrote:

| At 15:54 2/29/96, Derek Atkins wrote:
| 
| >So, there needs to be a compromise, some shorthand method to describe
| >the hint.  One solution is to provide a "keyserver" type and then some
| >string that says which "keyserver" to use.  For example, if there is a
| >DNS-style keyserver deplyed, I could put '1,"mit.edu"' in all my
| >signatures, if we assume that '1' is the DNS-style keyserver code.

| is a URL just too big?  My sigs are already several lines long.  E.g.,
| 
| Key: ftp://ftp.clark.net/pub/cme/cme.asc

I think a URL is probably a good solution.  But if we're using 
URLs, lets create a scheme for public keys.  If needed, this could be
either abbriviated, or dereferenced with a key exchanger (similar to
SMTP's mail exchangers).  Defaults would also allow for a good deal of
shortening.  And URLs have the user interface advantage of becoming
common, and understood.  Who gets on the net today and not the web?


key://ftp.clark.net/pub/u/cme/cme-current.asc
key://ftp.clark.net/pub/u/cme/cme-longterm.asc

or 
key://gateway.acme.net/pub/s/telnetd.asc

abrieviated version:

key://acme.com/~telnetd/

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume