# Re: dynamic providers

Jan Luehe (luehe@laguna.eng.sun.com)
Thu, 30 Jul 1998 15:38:56 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: James Nicolson: "dynamic providers"
- Maybe in reply to: James Nicolson: "dynamic providers"

    Date: Thu, 30 Jul 1998 15:38:56 -0700 (PDT)

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

    Subject: Re: dynamic providers

    To: java-security@java.Sun.COM, nicolson@netscape.com

James:

> I previously asked about PKCS #11 support and was informed by Hemma that
> it was being considered but no work had yet been done. Since it is
> necessary for our software to support PKCS #11 tokens, we are currently
> working on a way to integrate this with JCA. The primary problem we are
> running up against is that Providers are static. That is, a Provider is
> represented by a class. What we would like is to, at start up, make a
> list of all the PKCS #11 tokens installed on the system, create a
> Provider for each one, and register each Provider. This entails
> creating and configuring Providers at run-time, which is not really
> possible if a Provider is a class. What we need is either for a
> Provider to be an object or for a Provider class to take some sort of
> constructor argument to allow it to be parameterized. For example, we
> could make a PKCS11Provider class that takes as a constructor argument
> the name of the PKCS #11 token that is being modeled.
>
> I understand that you haven't yet scheduled time to deal with PKCS #11,
> but I think this sort of run-time configuration of Providers is common
> (it also exists in CDSA, for example). Since the JCA crypto classes
> (signature, cipher, messagedigest) all get their instances from a
> provider, we can't use them if the Provider architecture doesn't work
> for us. Is there something we are missing, perhaps some way to pull
> this off? If not, I think that the Provider architecture will have to
> be changed before PKCS #11 can be supported.

I am afraid I don't understand your concerns.

How you construct your subclass of java.security.Provider
is entirely up to you. Your java.security.Provider subclass
could have a parameterized constructor, it's up to you.
Unfortunately, java.security.Provider extends java.util.Properties.
This means that you have to set up a list of properties, where
each property value is the name of the class that supplies
the implementation corresponding to the property key (the
algorithm name). This is the only static information required
in your provider.

You could construct your Provider subclass at runtime and then
register it dynamically with the Security object, which manages
all providers.

Please let me know if this does not answer your question.

Thanks,

Jan

- Previous message: James Nicolson: "dynamic providers"
- Maybe in reply to: James Nicolson: "dynamic providers"