[Cryptography] heterotic authority + web-of-trust + pinning

[John Denker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 
> sub-certificate".

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
include:
 *) 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
  been mentioned.

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

iQIVAwUBUkW1svO9SFghczXtAQLjPg//d4P9Lchbe7Z7sylIzGGXyx8oe0742vrX
/7L3c+RvIymE5b7sighyDQFKjM16CIGp9bbfVS5XkAwyWdWv3alWjXfL3vAV0mjx
Xctad+B5ipyg22+t9xGI4c+NXgC+oxqu3D5tNy7kg6tDuKHEDpxDqip0IEdOTNTE
+N2uyfg9N4ltIf5Y0PnkTaEl0as42lifLlhn7b1PrZ4H1YaWOUyTlIdM/TPeK8OD
f3rlnbmScFVchdhAbUOanaHOAqiR6RMG+exSksISq8KwcvTnei1EChGV7yQ/LTxv
H/qpMq2RJPMWnr6wZ3EnpJvOTVFKE/E8oYiUMa1ZnvsesMce7Xu45tILA92NKyeA
lc8RATR0CXij1CgXyf+exaURif0hQtgMRRM9hZdKur5y3Uaysgu+Jz9Dh8oGs5a+
5TccQhsm/CpPzArgNYrnw87I7b1j6RnH12sEYVpwYqvnQGR3JW7xKoPSf9zI8OHG
RW68BKeRlTwUdb8nsvvX5jl8QN29H/oajH83D+S0aY2fwMTxxqpHWO+mkcHWHbdE
iKzJ2t5oh9lskBXj83Ect7tQ+UAtrFXMcEPGTD36IbXceMQ8dqpyq7yX/PRXtwKM
5uuTCFsDcW6fULvtr8c13SU/FaBTg8fImdF36FnangW6679Jjp0+6B8EQu26jZj2
+1NFV1rGqoo=
=V6VL
-----END PGP SIGNATURE-----