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 mailto:xuelei@oracle.com>> 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 trusted_ca_keys is for legacy use only
and the ce

Re: JCA design for RFC 7748

[Adam Petcher]

On 8/10/2017 9:46 PM, Michael StJohns wrote:


On 8/10/2017 7:36 PM, Xuelei Fan wrote:
Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) 
and at least 4 major representational domains (Raw, PKIX, XML and 
JSON).  In the current situation, I can take a JCA EC Public key and 
convert it to pretty much any of the other APIs or representations. 
For much of the hardware based stuff (ie, smart cards), I go 
straight from JCA into raw and vice versa. Assuming you left the 
"getEncoded()" stuff in the API and the encoding was PKIX, I'd have 
to encode to PKIX, decode the PKIX to extract the actual raw key or 
encode a PKIX blob and hope that the KeyFactory stuff actually worked.


It's not just support of arbitrary keys, but the ability to convert 
things without having to do multiple steps or stages.


Good point!  It would be nice if transaction between two formats 
could be done simply.  Using X.509 encoding is doable as you said 
above, but maybe there are spaces to get improvements.


I need more time to think about it.  Please let me know if any one 
have a solution to simplify the transaction if keeping use the 
proposed named curves solution.




I'm also coming to the conclusion that using X.509 encoding for this 
sort of interoperability is too onerous, and we should come up with 
something better. Maybe we should add a new general-purpose interface 
that exposes some structure in an algorithm-independent way. Something 
like this:


package java.security.interfaces;
public interface ByteArrayValue {

String getAlgorithm();
AlgorithmParameterSpec getParams();
byte[] getValue();
}

The actual value is encoded, but the parameters are exposed, so this 
interface would work well for any value that is generally represented 
using a single encoded value (like public/private keys in RFC 7748, and 
8032). This could be used with the new NamedParameterSpec class to 
identify the parameters by name. It could also be used with other 
parameter specs to specify curve coefficients.


Of course, you may still need to look up curve name/OID/coefficients 
based on the parameters, but at least this solution provides direct 
access to the parameters and raw value, and you wouldn't need to go 
through X.509. Though perhaps this is less appropriate for SEC1 types 
and XML/JSON, because you would need to parse the value to extract the x 
and y coordinates. So using the existing ECKey for those types may make 
more sense.