# Re: Installing a new security Provider

Jan Luehe (luehe@laguna.eng.sun.com)
Thu, 20 Aug 1998 13:38:02 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Charlie Lai: "Re: Java Security Exeption"
- Maybe in reply to: Batchelor, Steve: "Installing a new security Provider"

    Date: Thu, 20 Aug 1998 13:38:02 -0700 (PDT)

    From: Jan Luehe <luehe@laguna.eng.sun.com>

    Subject: Re: Installing a new security Provider

    To: java-security@java.Sun.COM, steve.batchelor@intel.com

Steve:

> The reason why we are using a non-Sun implemented provider is
> because we have a need for a Provider that supports an asymmetric algorithm
> that can be used for both signature generation and ciphering.
> But the problem is this: we would like to programmatically generated
> (issue and sign) certificates using a public/private key pair generated by
> an asymmetric algorithm. This we understand is not possible with the
> current version of the JDK (1.2Beta4) and JCE (1.2) and its providers, so we
> have accepted the use of 'keytool' to issue key pairs and certificates.

We may be working on a Java extension package that would allow
you to programmatically generate certificates. We felt that this
should not be part of the JDK core.

> We
> then like to use the asymmetric keys, generated by 'keytool' and associated
> with the issued certificate, to encrypt (public key) and decrypt (private
> key) simple clear text. This is again not possible as mentioned above as it
> is currently not supported by the Sun implemented providers.

Correct, the "SUN" and "SunJCE" providers do not implement
any reversible asymmetric algorithms (such as RSA). Note that
we cannot supply an implementation of RSA in Java due to
licensing restrictions by RSA Data Security, Inc.

However, there are other providers out there (such as "JSAFE")
that provide such as functionality and can be plugged into
the JCA framework.

> So this is why
> we are using a provider that supports both signaturing and ciphering using
> an asymmetric key pair.
> As mentioned earlier, we are using 'keytool' to issue and sign
> certificates. But we are finding that 'keytool' refuses to recognize and
> the non-Sun security provider that we can successfully use through the Java
> APIs.
> Further investigation using the book 'Java Security (Java 1.2)', by
> Scott Oaks, has uncovered the following limitation of 'keytool'. On page
> 334, in the description of '-keyalg AlgorithmName' it says the following:
> 'Use the given algorithm to generate the key pair. For the default Sun
> security provider, the name must be DSA, which is also the default value for
> this option. Despite the presence of this option, you cannot really specify
> another algorithm name, nor, for that matter, can you use a non-Sun DSA
> provider. Internally, keytool expects the key generator to produce keys
> that belong to a specific class in the sun package.' Is this still true?

This is not true.

We create RSA keys (using keytool and an RSA provider on top of
Bsafe) all the time!

When we create keys in keytool, we instantiate *provider-based*
KeyPairGenerator and Signature objects, which can be supplied
by providers other than the default SUN provider.
The generated keys (and certificates) are stored in encoded format
in your keystore.

When we parse the keys and certificates from the keystore, we
instantiate *provider-based* KeyFactory and CertificateFactory
objects, which parse the encoded bytes and return provider-based
key and certificate objects.

There used to be a limitation if you plan to use a signature
algorithm with keytool that is not mentioned in Appendix A of the
"Java Cryptography Architecture API Specification & Reference"
(at
http://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.html).
When generating the certificate, keytool needs to be able to
determine the OID of the signature algorithm to include
in the certificate encoding. This limitation will no longer
exist in the JDK 1.2 FCS version.

However, if you plan to use RSA signatures with keytool,
that should work fine (we do it all the time),
because the JDK already knows about the RSA OIDs, thus the
limitation mentioned above does not apply to you.

> Understanding our programmatic requirements and our current
> 'keytool' limitations, can you please suggest a work around if one exists?,
> and/or, if this will be included in the JDK/JCE in the future in the form of
> programmatic way to issue certificates and perform public-key cryptography
> using the Cipher class?
> Thanks,

We may provide a Java extension package for certificate generation.
The Cipher class already allows you to perform public-key cryptography,
it's just that the SunJCE provider does not implement a
reversible asymmetric algorithm.

Jan

- Previous message: Charlie Lai: "Re: Java Security Exeption"
- Maybe in reply to: Batchelor, Steve: "Installing a new security Provider"