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

[Sean Mullan]

On Mon, 7 Feb 2022 23:13:13 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> "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.
>> 
>> Please let me know if you are on the same page as well.  I am open to make more changes if the spec is still not clear.
>
>> Are you maybe saying that this method returns the value of the system properties if they are set?
> 
> The return value of this method depends on the following specs:
> 
>      * If the {@link #setSignatureSchemes} method has not been called, this
>      * method should return the default signature schemes for connection
>      * populated objects, or {@code null} for pre-populated objects.
> ``` 
> 
> If the setSignatureSchemes() method has been called, the get method will return the set values.  I may miss this spec.  But I think it is a common sense that the getter method returns the values set with setter method.  Let me know if you would like to have an explicit clarification in the spec.

Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following:

"The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.client.SignatureSchemes, as well as JDK provider defaults."

Does that accurately capture the implementation behavior?

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

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