continuity of identity

[John Denker]

Jerrold Leichter mentioned that:

>  a self-
> signed cert is better than no cert at all:  At least it can be used in an 
> SSH-like "continuity of identity" scheme.

I agree there is considerable merit to a "continuity of identity"
scheme.

But there are ways the idea can be improved.  So let's discuss it.

For starters, let me suggest that rather than having a self-signed
certificate of the type created more-or-less automatically when
you set up your Apache server or set up your SSH daemon, it makes
more sense to set up your own CA and issue your own certs from
there.  In some sense this is just a different type of self-signing,
but it adds a possibly useful layer of indirection.

One advantage is that one CA can issue lots of certs, so if you
are (say) a hosting service provider running N hosts, you only
need to have one CA.  The idea is that your users can have
a notion of continuity of your CA.  This notion is more powerful
than having N separate lines of continuity, one for each of your
hosts.  That's because each line of continuity is vulerable at
its beginning.  Having one CA reduces the vulnerabilty by a factor
of N, or at least a factor of M, where M tells us how many of
your hosts are likely to be visited by a typical visitor over
the course of time.

Another advantage is that you can keep your CA on a separate
machine, with a security policy radically stricter than the
policy on the N hosts.  That means if one of your hosts is
compromised, they get only the host key, not the CA private
key.  New host keys can be generates as soon as the compromise
is remedied, and assuming the old host keys have a reasonably
short expiration time, then your total vulnerability is
bounded, much more tightly bounded than in any commonly-used
scheme.  (I don't know of anybody who renews his Verisign-issued
certs every day, or even every week.)

In a similar vein, rapid expiration of host certs limits how
careful you have to be with backup takes, et cetera.

Another advantage is that it might shrink your known_hosts
file ... reducing it by a factor of M or thereabouts, since it
now becomes, in effect, a known_ca file.

This scheme is in some sense doable already, since modern browsers
have a way of importing new CA keys under user control.  If you
can persuade a user to go through those steps you're all set.
However, this process is sufficiently arcane and cumbersome that
it must be considered
  -- in the short term, a serious drawback to my continuity-of-CA
   scheme, or
  -- in the medium term, a tremendous opportunity for improvement.

In particular, it would be nice if both SSH and the web protocols
had a way of piggybacking a CA public key along with each cert
signed by that CA, so that SSH clients and web browsers could
give the users a relatively Muggle-friendly way of deciding
  *) to trust the CA henceforth
  *) to trust only this particular host henceforth
  *) neither.

By default, such a CA should be limited to signing only one
domain and its subdomains, such as *.jdenker.com (as opposed
to signing *.com).

Setting up a CA is no big deal.  There is a HOWTO by Ng Pheng Siong:
   http://sandbox.rulemaker.net/ngps/m2/howto.ca.html

==========

I realize that such a scheme is open to abuse ... but on the whole,
I expect it would solve more problems than it creates.

Comments, anyone?


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com