-----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----- _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography