# The SUN provider

Svensson, Claes (Claes.Svensson@promotor.telia.se)
Fri, 13 Jun 1997 11:56:28 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: John Dono: "Educational Use of Java Development Kit"
- Previous message: Jesus Maria Rodriguez Presedo: "JCE-1.1"

    From: "Svensson, Claes" <Claes.Svensson@promotor.telia.se>

    To: "'java-security@web2.javasoft.com'" <java-security@web2.javasoft.com>

    Subject: The SUN provider

    Date: Fri, 13 Jun 1997 11:56:28 +0200

Hi,

I work at Telia in Sweden. We are developing a provider for the Java
Security API
that supports the swedish SEIS Electronic ID standard and Telias
infrastructure
for certificate and key distribution.

The provider will supply RSA for digital signatures. Telia can deliver
private RSA keys
stored in smartcards or at floppy diskettes (encoded according to PKCS
#8). In the initial
phase we will focus on key diskettes because smartcards cannot be
reached in 100% Java.

The provider will retreive x509v3 certificates from Telia X.500
directory. The certificates will
be retreived using LDAP.

We would also like to offer authenticity and confidentiality. We plan to
achieve this
through a Java SSL implementation.

Q1: Does it sound like a reasonable solution? Any opinions?

Q2: SUNs provider has support for x509v1 handling and PKCS #8 decoding.
Is that code
free for commercial usage or will we have to develop such
functionality ourselves?
If it is not free, how much will it cost?

Q3: Is there a Java SSL implementation in development? (Preferably
non-US.)

Q4: There is a Smartcard API in development. Will the API somehow
overcome the Java-
serialport/smartcard problems or will it only be an API to be used
by Java applications
that execute *on* the smartcard?

It is sad to see that Netscape does not support SUNs JSAPI. I can buy
their arguments
for developing a code signing technology that supports their existing
certificate infrastructure.
But I cannot see the reason for not supporting the
"java.security.*"-classes that makes it
possible for third party providers to implement additional cryptograhy
providers. We plan
to circumvent this by supplying the "java.security.*"-classes in our
software distribution
and we hope that Netscape will soon supply the classes themselves.

Q5: Is this a possible/reasonable solution?

Thank you for your help!

Claes Svensson
claes.c.svensson@telia.se

- Next message: John Dono: "Educational Use of Java Development Kit"
- Previous message: Jesus Maria Rodriguez Presedo: "JCE-1.1"