Re: JCA design for RFC 7748

[Anders Rundgren]

Hi Guys,

whatever you come up with I anticipate it comes with descriptions
of how to use it as well. I would recommend putting the JEP on GitHub
(although this may not be the usual process), since this topic have
bearings on other crypto APIs in the workings.

I really hope that the end-result will turn out better than the quite quirky
EC support provided by JDK:
http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html

Regards,
Anders

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

[Jonathan Gibbons]

Brad,

Thanks. I should have noted that the issues were detected by checking tools,
and that after the edits, no such issues were reported in this package.

FWIW, there is one remaining issue to be addressed: it is a broken link 
in Provider.html.

It comes from Provider.replace(Object, Object, Object) which overrides
Properties.replace(Object, Object, Object), but for some reason, that 
method is

marked @hidden in Properties, causing a broken link in Provider. That needs
to be investigated, but I don't want to block these accessibility fixes.

-- Jon


On 08/11/2017 05:14 PM, Bradford Wetmore wrote:
Changes look good to me, although I'm not an HTML expert nor an expert 
in our current documentation style.  I did compare the output, and can 
see the effects.  (Striped, scope (row vs col), style)


Brad



On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:
Please review the following small fix for some accessibility issues 
in the java.security package.


3 tables are converted to the de-facto JDK standard for row-oriented 
tables, and updated
with appropriate scope=row|col attributes to identify the header cell 
in each row or column.

You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the 
JDK documentation.


JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

[Bradford Wetmore]

Changes look good to me, although I'm not an HTML expert nor an expert 
in our current documentation style.  I did compare the output, and can 
see the effects.  (Striped, scope (row vs col), style)


Brad



On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:
Please review the following small fix for some accessibility issues in 
the java.security package.


3 tables are converted to the de-facto JDK standard for row-oriented 
tables, and updated
with appropriate scope=row|col attributes to identify the header cell in 
each row or column.

You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the 
JDK documentation.


JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon

RFR: JDK-8186160 Fix a11y issues in java.security package

[Jonathan Gibbons]

Please review the following small fix for some accessibility issues in 
the java.security package.


3 tables are converted to the de-facto JDK standard for row-oriented 
tables, and updated
with appropriate scope=row|col attributes to identify the header cell in 
each row or column.

You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the 
JDK documentation.


JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon

Re: JCA design for RFC 7748

[Adam Petcher]

On 8/10/2017 12:25 PM, Michael StJohns wrote:


On 8/10/2017 9:44 AM, Adam Petcher wrote:
Does anyone know of a particular use case (that we haven't discuss 
already) that would require a provider to support arbitrary curves? 
Any other arguments for or against this feature? 


There are uses for changing out the base point.  PAKE and SPAKE use 
similar math (e.g. G^s*sharedSecret is the equivalent of a new base 
point).


There are uses for private curves - e.g. when you want to actually be 
sure that the curve was randomly generated (sort of the same argument 
that got us to Curve25519 in the first place).


There are the whole set of Edwards curves that are mostly not included 
in any provider (except possible Microsoft's) as of yet.


Basically, you're trying to argue that there are no better curves (for 
the 'new' math) than have already been specified and there never will 
be.  I think that's a very shortsighted argument.


I expect that new curves will be developed in the future, and the API 
should absolutely be designed in such a way that that support for new 
curves can be easily added to applications and providers. What I 
attempted to argue (I apologize if this was not clear) was that we don't 
necessarily need support for arbitrary curve parameters in the initial 
API design because:


1) When new, better curves are developed, they will eventually get 
names, and then they can be used in exactly the same way as the curves 
that exist today.
2) If there is a desire to allow arbitrary curve parameters for 
Montgomery/Edwards curves over the API, then we can consider this in the 
future as a separate feature. We should ensure that the initial API 
design accommodates the addition of this API in the future.





Later, Mike

Re: Code review request: JDK-8046295 - Support Trusted CA Indication extension

[Xuelei Fan]

Hi Martin,

Sorry for the delay.

I'd like to wait for finalization of TLS 1.3 specification, so that we 
can get a stable specification of the Certificate Authorities extension.


For the current design, I did not see much benefit to add a new 
CertificateAuthority API.  The CertificateAuthority.implies() may not 
yet reach the threshold to be a public API.  A trust/key manager can 
easily matching the distinguished name with the target certificate.  And 
I did not see the cert matching behavior differences between different 
providers and trust/key managers.


For the specification documentation part, I may suggest reword them a 
little bit so that those developers who are not TLS specification 
experts can easily catch the purpose or benefits of the API.


Xuelei

On 7/21/2017 7:20 AM, Martin Balao wrote:
Webrev has been uploaded to cr.openjdk.java.net 
:


  * 
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/
  * 
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/8046295.webrev.03.zip


Kind regards,
Martin.-

On Tue, Jul 18, 2017 at 2:12 PM, Martin Balao > wrote:


Hi,

Given that 1) Trusted CA Indication TLS Extension does not appear to
be widely implemented today and 2) it will be replaced by
Certificate Authorities TLS extension in TLS 1.3, it looks more
beneficial to me supporting only the latter -and avoid paying the
cost for a larger code-base-.

Here it is my proposal for Certificate Authorities TLS extension:

  *

http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03/


(browse online)
  *

http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03.zip


(download)

Implementation based on TLS 1.3 - draft 20 [1]. Patch based on
JDK-10 (rev 76ff72bb6a4a).

Pending / blocked (in descending priority order):

High

  * The extension applies only to TLSv1.3+
   * Blocked because TLSv1.3 is still not supported in JSSE.
   * Impact: the extension cannot be used in TLS 1.2 (high impact on
the client-side).
   * Action: replace "useTLS12PlusSpec" with "useTLS13PlusSpec" in
the patch when available.

Medium

  * Server can send the CertificateAuthorities extension to the
client in a CertificateRequest message (feature)
   * Blocked by: Server is still not able to send
EncryptedExtensions message in CertificateRequest
   * Impact: feature not supported on the server side. The extension
can still work in production environments. (medium).
   * Action: implement EncryptedExtensions message in
CertificateRequest and then implement this feature.

Low

  * Update documentation to refer the final TLS 1.3 RFC (draft 20 is
currently referred)
   * Blocked by: publication of the final TLS 1.3 RFC
   * Impact: documentation is not accurate. (low)
   * Action: replace
"https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4
"
with the final link in the patch.

  * Update bug id in "CertificateAuthoritiesClientTest.java" and
"CertificateAuthoritiesServerTest.java"
   * Blocked by: there is no bug id for Certificate Authorities TLS
extension
   * Impact: internal tests (very low).
   * Action: replace "@bug 8046295" with the new bug id in the
patch. Open a new bug id for Certificate Authorities TLS extension.
Look forward to your comments.

Kind regards,
Martin.-

--
[1] -
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4


On Tue, Jun 20, 2017 at 9:33 PM, Xuelei Fan > wrote:

Hi Martin,

The TLS 1.3 spec is replacing the Trusted CA Indication
(trusted_ca_keys) extension with a new Certificate Authorities
(certificate_authorities) extension.  See more details about the
specification in the TLS 1.3 draft:
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 


Both serves a similar purpose, but the trusted_ca_keys extension
will not be used in TLS 1.3 any more.  The "trusted_ca_keys"
extension will only be used for legacy protocol versions (TLS
1.2/1.1/1.0).

There are two options to me:
1. Supports the certificate_authorities, but not trusted_ca_keys
extension.
It is acceptable to me as