JCA design for RFC 7748
Adam Petcher
adam.petcher at oracle.com
Tue Aug 8 17:42:19 UTC 2017
On 8/8/2017 11:45 AM, Anders Rundgren wrote:
> On 2017-08-08 17:25, Adam Petcher wrote:
>
>> It sounds like what you are saying is
>> that I will need something like XDHPublicKey and XDHPrivateKey in
>> java.security.interfaces. Can you tell me why? What is it that we can't
>> do without these interfaces?
>
> Every JOSE Java library I have seen constructs and deconstructs RSA
> and EC keys
> based on JWK definitions. Maybe we don't need XDH keys but it would
> be nice to
> hear what the solution would be without such.
Of course, you could get the X.509 or PKCS#8 encoding of the key, and
then convert that to JWK (I think all the information you need is in the
algorithm ID), but that is not a very good solution. So perhaps it would
be helpful to have an interface that exposes the key array along with
its associated algorithm name and parameters. This would be similar to
your OKP interface, but we can make it a bit more general so that it can
be reused by other algorithms. We could also add interfaces for RFC 7748
public keys and private keys, but they wouldn't have any additional
information, and I still don't know if they are needed.
>
> Then there's lot of stuff out there like this which also needs some
> explanations on how to enhance with RFC7748 on board:
>
> Object myOwnEncrypt(PublicKey publicKey) throws SecurityException {
> if (publicKey instanceof RSAKey) {
> // RSA
> } else {
> // It should be EC
> }
> }
Like before, there is a (not very good) solution using X.509 encoding,
and a better solution involving a new interface that provides the
required information. Something like:
Object myOwnEncrypt(PublicKey publicKey) throws SecurityException {
if (publicKey instanceof RSAKey) {
// RSA
} else if (publicKey instanceof ECKey) {
// EC
} else if (publicKey instanceof ByteArrayKey) {
ByteArrayKey baKey = (ByteArrayKey)publicKey;
if(baKey.getAlgorithm().equals("XDH") {
// RFC 7748
}
}
}
The ByteArrayKey would also hold a parameter spec that can be used to
determine which curve is associated with the key. Would something like
this work?
>
> CC:ing the creator of OKP keys.
>
> https://tools.ietf.org/html/rfc8037#section-2
>
> Anders
More information about the security-dev
mailing list