RFR: 8280494: (D)TLS signature schemes [v13]

[Xue-Lei Andrew Fan]

On Mon, 7 Feb 2022 22:18:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I think lines 714-816/723-725 describe the behavior already.
>> 
>> I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode.  The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values.
>> 
>> It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead".  But I think it is a duplicate of lines 714-816/723-725 .
>
> Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set?

> "If set, these properties will override the signature schemes returned by this method."

If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null.

But let me trying  if I could understand the spec by myself.

For the getSignatureSchemes() method's spec:

     * If the returned array is {@code null}, then the underlying
     * provider-specific default signature schemes will be used over the
     * SSL/TLS/DTLS connections.

With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection.  As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question.  However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties).


     * If the returned array is empty (zero-length), then the signature scheme
     * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
     * the connections may not be able to be established if the negotiation
     * mechanism is required by a certain SSL/TLS/DTLS protocol.

With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used.  The API wins, the default signature schemes are not used.


     * <p>
     * If the returned array is not {@code null} or empty (zero-length),
     * then the signature schemes in the returned array will be used over
     * the SSL/TLS/DTLS connections.

With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used.  The API wins, the default signature schemes are not used.


     * @implNote
     * Note that the underlying provider may define the default signature
     * schemes for each SSL/TLS/DTLS connection.  Applications may also use
     * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
     * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
     * customize the provider-specific default signature schemes.

With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties.

So back to my question above, why I don't want to use the properties, and use the default signature schemes instead?  We need to take care of three things: the properties, the API set values and the provider default values.  If I use the properties values, I would have to describe the provider default values as well.  As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context.

What if both the properties and the APIs are set?  The properties are used to set the provider default values, and the properties will change the  provider default values.  So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above.  Simply, if both set, the API wins.

Similar to the set method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252