On 7/11/19 11:56 AM, Xuelei Fan wrote:
Also, in the CSR you list all the different signature algorithms that
could be disabled, but you use the TLS names, and not the standard JCE
names. I found this a bit confusing, since if you added those exact
TLS names to jdk.tls.disabledAlgorithms, I don't think it will work,
or if it does we need additional changes to the
jdk.tls.disabledAlgorithms definition - and maybe that is what we
should do? Also, I don't think it is possible to disable individual
RSASSA-PSS algorithms, I think you can just disable all or none of
them because the parameters are specified separately and not part of
the standard JCE name. Similar to other algorithms - how would I just
disable ecdsa_secp256r1_sha256 and nothing else? Is that an issue?
Yes, it is an issue now. The AlgorithmConstraints is able to accept
parameters, but the current jdk.tls.disabledAlgorithms property cannot.
That's also why I used the TLS names (ecdsa_secp256r1_sha256,
rsa_pss_rsae_sha256, etc) rather than standard names (SHA256withECDSA,
RSASSA-PSS).
I agree with you that it is confusing. The use of rsa_pss_rsae_sha256
may be fine, but the name "dsa_sha256" rather then "SHA256withDSA" could
be confusing.
I was planned to add TLS signature algorithms into the standard names,
as we will do for the named groups. But it looks like a duplicate of
the crypto Signature algorithms.
I would lean towards this option. We could extend the
jdk.tls.disabledAlgorithms property to allow you to specify TLS
signature schemes as defined in
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme
We would also need to add a section to the Standard Names specification
listing these schemes.
The reason I like this option is because it fits well with the TLS
namespace, and it is more flexible than the JCE names and we can more
easily restrict new TLS signature schemes that are defined later.
--Sean
It is an option to support crypto Signature algorithm with the specific
parameters, for example "SHA256withECDSAofSECP256R1",
"SHA256withRSASSA-PSS". I don't like it as a provider need to enum all
known parameters.
Maybe, we can introduce something new in jdk.tls.disabledAlgorithms. For
example, "signature_algorithm with parameters" ("SHA256withECDSA with
Secp256R1", "RSASSA-PSS with SHA256"). However, it does not sound
generic or simple.
We may want to introduce new system property or APIs to customize the
signature algorithms of TLS connections. Using the TLS signature
algorithms is an acceptable option to me, but it is far from satisfied
because the duplication with the crypto Signature algorithm.
Let's discuss the issue more. Any feedback are welcome!
Thanks,
Xuelei
Thanks,
Sean
On 7/9/19 12:43 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.01/
CSR: https://bugs.openjdk.java.net/browse/JDK-8227445
During handshaking, the selection of signature algorithms was not
checked with the algorithm constraints. Then the available signature
algorithms may be ignored if a restricted algorithm get selected.
The connection should be able to be established as there are
available algorithms.
Within this update, more algorithm constraints checking are
introduced in the signature algorithms and named groups code.
The significant changes are in NamedGroup.java and
SignatureScheme.java, in order to introduce the checking and
algorithm parameters and specs.
Note that the following JDK 13 review thread was close out.
https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020348.html
I targeted this enhancement to JDK 14, and come up with a CSR request.
Thanks,
Xuelei
