[Cryptography] heterotic authority + web-of-trust + pinning
jsd at av8n.com
Fri Sep 27 12:43:30 EDT 2013
-----BEGIN PGP SIGNED MESSAGE-----
On 09/25/2013 04:59 AM, Peter Gutmann wrote:
> Something that can "sign a new RSA-2048 sub-certificate" is called a CA. For
> a browser, it'll have to be a trusted CA. What I was asking you to explain is
> how the browsers are going to deal with over half a billion (source: Netcraft
> web server survey) new CAs in the ecosystem when "websites sign a new RSA-2048
There are other ways of thinking about it that makes it seem not
quite so bad.
There are many approaches to establishing trust. Familiar examples
*) The top-down authoritarian X.509 approach, such as we see in SSL.
*) The pinning-only approach, such as we see in SSH.
*) The web-of-trust approach, such as we see in PGP.
Each of these has some security advantages and disadvantages. Each
has some convenience advantages and disadvantages.
My point for today is that one can combine these in ways that are
heterotic, i.e. that show hybrid vigor.
-- The example of combining the CA approach with pinning has already
-- Let's now discuss how one might combine the CA approach with the
web-of-trust approach. Here's one possible use-case:
Suppose you have a HTTPS web site using a certificate that you bought
from some godlike CA. When it expires, you buy another to replace it.
So far so good.
However, it would be even better if you could use the old certificate
to sign the new one. This certifies that you /intend/ for there to be
a continuation of the same security relationship. [As a detail, in
this approach, you want a certificate to have three stages of life:
(1) active, in normal use, (2) retired, not in active use, but still
valid for signing its successor, and (3) expired, not used at all.]
This is like PGP in the sense that the new certificate has multiple
signatures, one from the top-down CA and one from the predecessor.
The idea of having multiple signatures is foreign to the heirarchical
authoritarian X.509 way of thinking, but I don't see any reason why
this would be hard to do.
-- Similar heterotic thinking applies to SSH. Suppose I want to replace
my old host key with another. It would be nice to use the old one to
/sign/ the new one, so that a legitimate replacement doesn't look like
a MITM attack. (In theory, you could validate a new SSH keypair by
distributing the fingerprint via SSL or PGP, which reduces it to a
problem previously "solved" ... but that's labor-intensive, and AFAICT
hardly anybody but me ever bothers to do it.)
> Something that can "sign a new RSA-2048 sub-certificate" is called a CA.
You could call it that, but you could just call it a /signer/. PGP
has already demonstrated that you can have millions upon millions of
signers. In the use-case sketched above, we don't even need a keyserver.
The web site just offers its public key, plus a certifiate signed by
the CA, plus another certificate signed by the predecessor key.
For end-to-end security of email, where it may be that neither end
is a server, some sort of keyserver is probably necessary. This
seems like a manageable problem.
We agree that half a billion CAs would be too many, if they all had the
power to sign anything and everything. Forsooth, my system already has
321 certificates in /etc/ssl/certs, and that seems like waaay too many,
IMHO. That's because the adversay needs to subvert only one of them,
and the adversary gets to pick and choose.
On the other hand, if we think in terms of a /signer/ with much more
limited power, perhaps only the power to countersign a successor cert
that has already been signed by a CA, that sounds to me like a good
thing, not a bad thing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the cryptography