Re: using sun.security.provider

David Brownell -- JavaSoft (db@doppio)
Mon, 14 Apr 1997 16:45:33 -0700

Date: Mon, 14 Apr 1997 16:45:33 -0700
From: db@doppio (David Brownell -- JavaSoft)
Message-Id: <199704142345.QAA25753@argon.eng.sun.com>
To: jmoreh@openhorizon.com
Subject: Re: using sun.security.provider

> From jmoreh@openhorizon.com Fri Apr 11 17:10:47 1997
> X-Sender: jmoreh@nitro.openhorizon.com
> Date: Fri, 11 Apr 1997 17:12:09 -0700
> To: David.Brownell@Eng
> From: Jahan Moreh <jmoreh@openhorizon.com>
> Subject: using sun.security.provider
> Cc: java-security@java, jmoreh@openhorizon.com
>
> David,
> acording to JDK documentation
>
> "the classes in sun.security.provider will be instantiated by the
> Java Security API if SUN us the requested service provider, or if no
> other service provider is specified"
>
> Does this mean that, if there are no other security service providers, the
> sun.security.provider is guaranteed to be in every one who implements the
> JDK? Or does this also fall into the sun.* vs. java.* packaging.

My understanding is that this falls into the "sun.*" vs "java.*" issues,
but I'm not really the one to deliver an authoritative answer on this
particular point.

The intent is clearly that the algorithms supported by JDK 1.1 be
available in all implementations of Java; they're exportable and
not subject to patent constraints, so that's not going to be hard
for any implementor. Those algorithms include SHA1/DSA signatures,
plus MD5 and SHA1 message digests.

- Dave

> Thanks
> Jahan Moreh
>
> -------------------------------------------------
> Jahan Moreh
> Senior Product Manager, Enterprise Security
> Open Horizon, Inc.
> tel: 310 476 3767
> fax: 310 476 7189
> email: jmoreh@openhorizon.com
>
> For additional information about Open Horizon
> please send email to info@openhorizon.com or
> visit our web site at http://www.openhorizon.com
>
>