Hello, I can understand that the PKI Path implementation or SSL engine does need to do some policy decisions. And for this I guess its not really a problem to combine larger RSA with larger hashes (especially as the CAs need to phase them out anyway).
But - as the SSH example shows - there are protocols which have different needs and threat scenarios. Crypto primitives should stay away from that policing. Gruss Bernd Am Fri, 19 Sep 2014 09:56:02 +0900 schrieb Atsuhiko Yamanaka <atsuhiko.yaman...@gmail.com>: > Hi, > > Thank you for your quick response, > > On Fri, Sep 19, 2014 at 9:04 AM, Valerie Peng > <valerie.p...@oracle.com> wrote: > > > > Do > > you have any more info such as CA certs using large DSA keys with > > SHA1withDSA signature algorithm, etc.? > > Our problem has appeared in SSH2 connections, not in CA certs. > > On SSH2 protocol, the key exchange will be used to share the secret > between client > and server, and that secret will be used to encrypt packets. > SHA1WithDSA has been > used to confirm if the secret is successfully shared or not. The > SSH2's RFCs have defined > some methods for key-exchanges. > > RFC4419[1] has defined "diffie-hellman-group-exchange-sha1" at its > Section 3, and it has > allowed to use keys between 1024 and 8192. And also, RFC4253[2] has > defined "diffie-hellman-group1-sha1". In that key-change method, 1024 > bit-length key will be used, but some sshds have been using > the longer keys. It seems those sshds have been widely used > unfortunately, and pure java SSH2 clients > have not been able to connect to them in using Java8's SunJCE. > > I hope this is the expected answer for your question. > > [1] http://tools.ietf.org/html/rfc4419 > [2] http://tools.ietf.org/html/rfc4253#section-8.1 > > > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > Skype callto://jcraft/ > Twitter: http://twitter.com/ymnk > Facebook: http://facebook.com/aymnk
