Re: RFR: 8280494: (D)TLS signature schemes [v13]
On Tue, 8 Feb 2022 23:36:05 GMT, Xue-Lei Andrew Fan wrote:
>> 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.server.SignatureSchemes, as well
>> as JDK provider defaults."
>>
>> Does that accurately capture the implementation behavior?
>
> Basically, the suggestion captures the implementation behaviors correctly.
> To make it more accuracy, if we want to use it, we may need to consider more
> cases:
> 1. _explicitly set by application_, with null, empty or 1+ schemes.
> 2. _specified by system property_, with unset, empty or 1+ schemes.
>
> I think the description could be in the following logic:
> A. the system properties are used to customize the provider default schemes.
> B. If the API set it to null, use the the provider default schemes (including
> system properties customized default schemes).
> C. If the API set it to empty, don't use any schemes.
> D. if the API set it to 1+ scheme, use the API set schemes.
>
> With logic A, we don't have to describe both _system properties_ and the
> _provider default schemes_ each time when we talk about the interaction
> behaviors of them. And then we can simplify the 3 interactive factors into 2
> factors.
>
> Here is the general 3 interactive factors:
> 1. the API.
> 2. the System properties.
> 3. the provider default.
>
> Here is set 1 of the 2 interactive factors:
> 1. The System properties;
> 2. the provider default.
>
> Here is set 2 of the 2 interactive factors:
> 1. the API
> 2. the provider default.
>
> Then, we could describe set 1 and set 2 individually. I think it is easier
> to understand.
>
> Then, we could have the sections accordingly.
> For A, we have (for set 1 of the 2 interactive factors):
>
> * @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.
> ```
>
> For B, we have (for set 2 of the 2 interactive factors):
>
> * If the returned array is {@code null}, then the underlying
> * provider-specific default signature schemes will be used over the
> * SSL/TLS/DTLS connections.
>
>
> For C, we have (for set 2 of the 2 interactive factors):
>
> * 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.
>
>
> For D, we have (for set 2 of the 2 interactive factors):
>
> *
> * 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.
>
>
> That's the current description we have. That's, in order to explain behavior
> of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections
> above.
>
> I understand it could be confusing when multiple facts are involved. It may
> be clear if re-org the description. What do you think of the following
> descriptions?
>
> In the get method:
>
> *
> * 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.
> *
> * The set of signature schemes that will be used over the SSL/TLS/DTLS
> * connections is determined by the returned array of this method and the
> * underlying provider-specific default signature schemes.
> *
> * If the returned array is {@code null}, then the underlying
> * provider-specific default signature schemes will be used over the
> * SSL/TLS/DTLS connections.
> *
> * 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.
>
Re: RFR: 8280494: (D)TLS signature schemes [v15]
> This update is to support signature schemes customization for individual > (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Spec update - Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/8302c592..c0018c67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=13-14 Stats: 31 lines in 1 file changed: 7 ins; 16 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252 PR: https://git.openjdk.java.net/jdk/pull/7252
Re: RFR: 8280494: (D)TLS signature schemes [v13]
On Wed, 9 Feb 2022 14:33:11 GMT, Sean Mullan wrote:
>> Basically, the suggestion captures the implementation behaviors correctly.
>> To make it more accuracy, if we want to use it, we may need to consider more
>> cases:
>> 1. _explicitly set by application_, with null, empty or 1+ schemes.
>> 2. _specified by system property_, with unset, empty or 1+ schemes.
>>
>> I think the description could be in the following logic:
>> A. the system properties are used to customize the provider default schemes.
>> B. If the API set it to null, use the the provider default schemes
>> (including system properties customized default schemes).
>> C. If the API set it to empty, don't use any schemes.
>> D. if the API set it to 1+ scheme, use the API set schemes.
>>
>> With logic A, we don't have to describe both _system properties_ and the
>> _provider default schemes_ each time when we talk about the interaction
>> behaviors of them. And then we can simplify the 3 interactive factors into 2
>> factors.
>>
>> Here is the general 3 interactive factors:
>> 1. the API.
>> 2. the System properties.
>> 3. the provider default.
>>
>> Here is set 1 of the 2 interactive factors:
>> 1. The System properties;
>> 2. the provider default.
>>
>> Here is set 2 of the 2 interactive factors:
>> 1. the API
>> 2. the provider default.
>>
>> Then, we could describe set 1 and set 2 individually. I think it is easier
>> to understand.
>>
>> Then, we could have the sections accordingly.
>> For A, we have (for set 1 of the 2 interactive factors):
>>
>> * @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.
>> ```
>>
>> For B, we have (for set 2 of the 2 interactive factors):
>>
>> * If the returned array is {@code null}, then the underlying
>> * provider-specific default signature schemes will be used over the
>> * SSL/TLS/DTLS connections.
>>
>>
>> For C, we have (for set 2 of the 2 interactive factors):
>>
>> * 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.
>>
>>
>> For D, we have (for set 2 of the 2 interactive factors):
>>
>> *
>> * 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.
>>
>>
>> That's the current description we have. That's, in order to explain
>> behavior of the null, empty and 1+ schemes setting, I cut the sentence into
>> 4 sections above.
>>
>> I understand it could be confusing when multiple facts are involved. It may
>> be clear if re-org the description. What do you think of the following
>> descriptions?
>>
>> In the get method:
>>
>> *
>> * 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.
>> *
>> * The set of signature schemes that will be used over the SSL/TLS/DTLS
>> * connections is determined by the returned array of this method and
>> the
>> * underlying provider-specific default signature schemes.
>> *
>> * If the returned array is {@code null}, then the underlying
>> * provider-specific default signature schemes will be used over the
>> * SSL/TLS/DTLS connections.
>> *
>> * 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.
>> *
>> * 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.
>>
>>
>> and similarly, in the set method:
>>
>> *
>> * 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
>> * custom
Re: RFR: 8280494: (D)TLS signature schemes [v15]
On Wed, 9 Feb 2022 18:24:56 GMT, Xue-Lei Andrew Fan wrote: >> This update is to support signature schemes customization for individual >> (D)TLS connection. Please review the CSR as well: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 >> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > Spec update If you agree with my last couple of comments, I think the API looks good now that you can finalize the CSR. I have not really reviewed the impl code and tests previously and may not have time to do a thorough review although I think Jamil may have done that - if he is ok with the rest of the code, then I think you can integrate once the CSR is approved. Thanks for the patience. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 749: > 747: * @implNote > 748: * Note that the underlying provider may define the default signature > 749: * schemes for each SSL/TLS/DTLS connection. Applications may also > use I think you can remove the first sentence that starts with "Note ..." as you already talk about provider-specific defaults before this. Also @implNotes are usually about the JDK implementation and not any provider. In the second sentence I would be more specific that this applies to the SunJSSE provider (see changes in italics), ex: "Applications ... system properties _with the SunJSSE provider_ to ..." - PR: https://git.openjdk.java.net/jdk/pull/7252
Re: RFR: 8280494: (D)TLS signature schemes [v15]
On Wed, 9 Feb 2022 21:38:22 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Spec update > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 749: > >> 747: * @implNote >> 748: * Note that the underlying provider may define the default >> signature >> 749: * schemes for each SSL/TLS/DTLS connection. Applications may also >> use > > I think you can remove the first sentence that starts with "Note ..." as you > already talk about provider-specific defaults before this. Also @implNotes > are usually about the JDK implementation and not any provider. In the second > sentence I would be more specific that this applies to the SunJSSE provider > (see changes in italics), ex: "Applications ... system properties _with the > SunJSSE provider_ to ..." Sounds good to me. Updated the CSR and PR. Thank you for the review! @jnimeh Jamil, do you have any comment about the spec and implementation? Otherwise, I will finalize the CSR. - PR: https://git.openjdk.java.net/jdk/pull/7252
Re: RFR: 8280494: (D)TLS signature schemes [v16]
> This update is to support signature schemes customization for individual > (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: spec re-wording - Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/c0018c67..40163778 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=14-15 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252 PR: https://git.openjdk.java.net/jdk/pull/7252
