CFRG support in JCE Provider etc?

[cyberphone]

Are there any plans regarding support for https://tools.ietf.org/html/rfc8037 including the JCE?

[peterdettman]

We will be adding support for RFC 7748 and RFC 8032 in the next few months, which should provide the crypto parts for RFC 8037, but I doubt we'll add anything specific to JSON.

[cyberphone]

That's great! I hope that you create distinct classes for these objects.
It seems that signature and ecdh keys also should be distinct unlike it is for EC.
How about X.509, PKCS #8 and PKCS #12 support?

JSON does'n need direct support but it would be nice if the solution maps to RFC 8037 because this is probably the primary use case.

[cyberphone]

Updated 2017-06-24

To make this more adapted to GitHub, I moved the spec into a separate repository:
https://github.com/cyberphone/java-cfrg-spec

[peterdettman]

Yes, once we have the basic implementations of the CFRG curves/algorithms are in place, we would gradually support their use in the context of certificates, key stores, etc. Since RFC 8037 refers directly to the CFRG RFCs, I don't expect we will need any specific code to support that usage. I don't envisage there being an "OKP" key-type, but presumably there will need to be e.g. an "EdDSA" signature algorithm. I don't see any reason why "ECDH" shouldn't cover RFC 7748, although the new point encoding will require some care.

Someone will probably want to make a small library to provide JOSE support to JSON apps, using BC, but it's not something we are likely to include ourselves.

[cyberphone]

AFAICT https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 does (in similarity to RFC 8037), not overload existing EC specifications.

Anyway, if your plan is to overload, the above is of no interest.

RFC 8037: Do not assume that there is an underlying elliptic curve, despite the existence of the "crv" and "x" parameters. (For instance, this key type could be extended to represent DH algorithms based on hyperelliptic surfaces.)

[ecki]

I think easy access to key usage might be an orthogonal issue. It is also relevant for RSA and EC Keys in X509Certificate (especially with RSAPSS Keys).

[cyberphone]

Hi @ecki. I guess you are referring to isSignatureKey(), right?

Well, the rationale for this is because "X25519" and "X448" must according to the IETF specs only be used for Diffie-Hellman operations while "Ed25519 " and "Ed448" must only be used for signatures. This is not related to key usage in X.509 terms (which is about "crypto hygiene" and applications rather than core algorithms characteristics).

I felt it would be nice to have this (for Signature, KeyAgreement, etc. mandatory) test in one place.

[cyberphone]

@peterdettman According to Oracle there is already a JEP in progress:
http://mail.openjdk.java.net/pipermail/security-dev/2017-June/016037.html

[cyberphone]

@peterdettman Oracle have now stated their preferences:
http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016171.html

The PKCS 11 folks have also realized that it is time to decide overload or not:
https://lists.oasis-open.org/archives/pkcs11/201708/msg00007.html

[peterdettman]

Thanks for the update, I'll try and review those discussions shortly.

[peterdettman]

RFC 7748 and RFC 8032 are now broadly supported in the provider. Please open new issues for support in specific high-level APIs.

[cyberphone]

@peterdettman thanx for the update. Unfortunately curve25519 and curve448 support became a disaster from a developer's point of view since BouncyCastle and JDK have entirely different interfaces making a the provider concept fairly useless. The JDK interfaces are also quit strange:
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022378.html
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html
https://mail.openjdk.java.net/pipermail/security-dev/2020-September/022382.html

[peterdettman]

@cyberphone We have had to wait for JDK to finalize their design and release their API classes. We'll be adding support for those new APIs in due course. and will keep an eye out for the issues you describe in those posts.