On 25/09/13 13:25, Adam Back wrote:
On Wed, Sep 25, 2013 at 11:59:50PM +1200, Peter Gutmann wrote:
Something that can sign a new RSA-2048 sub-certificate is called a
a browser, it'll have to be a trusted CA. What I was asking you to
how the browsers are going to deal with over half a billion (source:
web server survey) new CAs in the ecosystem when websites sign a new
This is all ugly stuff, and probably 3072 bit RSA/DH keys should be
deprecated in any new standard, but for the legacy work-around senario to
try to improve things while that is happening:
Is there a possibility with RSA-RSA ciphersuite to have a certified RSA
signing key, but that key is used to sign an RS key negotiation?
At least that was how the export ciphersuites worked (1024+ bit RSA auth,
512-bit export-grade key negotation). And that could even be weakly
secret in that the 512bit RSA key could be per session. I imagine that
ciphersuite is widely disabled at this point.
But wasnt there also a step-up certificate that allowed stronger keys if
right certificate bits were set (for approved export use like banking.)
Would setting that bit in all certificates allow some legacy
to get forward secrecy via large, temporary key negotiation only RSA keys?
(You have to wonder if the 1024-bit max DH standard and code limits was bit
of earlier sabotage in itself.)
A couple of points: all the big CAs will give you a new certificate with
a new key for free (but revocation is your baby) - while it isn't
something they do, can't they issue say two years worth of one-day certs
for perhaps a little more than the price of a two-year cert?
In the UK we have a law called RIPA, part of which allows Plod to demand
keys. They can demand keys used for encryption and for key setup - but
they can't demand keys used only for authentication. I don't think they
routinely demand keys from TLS/SSL webservers.
The point is that in an ordinary TLS session the RSA key is used for
both secrecy and authentication - in any future TLS these functions
should be split.
Also, Dan Boneh was talking at this years RSA cryptographers track about
putting some sort of quantum-computer-resistant PK into browsers - maybe
something like that should go into TLS2 as well?
You need to get the browser makers - Apple, Google, Microsoft, Mozilla -
and the webservers - Apache, Microsoft, nginx - together and get them to
agree we must all implement this before writing the RFC.
-- Peter Fairbrother
The cryptography mailing list