[security-dev 01140]: Re: 6840752: Provide out-of-the-box support for ECC algorithms

[Andrew John Hughes]

2009/8/28 Max (Weijun) Wang <Weijun.Wang at sun.com>:
> On Aug 28, 2009, at 10:17 PM, Andrew John Hughes wrote:
>
>> 2009/8/28 Max (Weijun) Wang <Weijun.Wang at sun.com>:
>>>
>>> On Aug 28, 2009, at 9:56 AM, Andrew John Hughes wrote:
>>>
>>>> 2009/8/28 Max (Weijun) Wang <Weijun.Wang at sun.com>:
>>>>>
>>>>> On Aug 27, 2009, at 9:52 PM, Andrew John Hughes wrote:
>>>>>
>>>>>> The problem is more the fact that it's an additional copy rather than
>>>>>> using the system installation, which means it has to be patched for
>>>>>> bugs and security fixes separately.  For IcedTea, I'll look at
>>>>>> providing and using the option of using the system NSS and will also
>>>>>> submit this for review here if there is interest in providing such an
>>>>>> option.
>>>>>
>>>>> Since Java security is already provider based, I guess you can simply
>>>>> write
>>>>> one provider named NSS and remove all other security.provider.<n> lines
>>>>> in
>>>>> jre/lib/security/java.security.
>>>>>
>>>>> Max
>>>>>
>>>>>
>>>>
>>>> Sounds like the JDK6 solution :)
>>>
>>> No, this is the real Java solution. :)
>>>
>>
>> ?
>
> I mean if you really want 100% "Fedora Crypto Consolidation" so that every
> app's crypto call goes to a single library, you need to create your own Java
> security provider to bridge JCA/JCE calls to this library and remove all the
> others.
>

Yeah I got that, but I think that's a much more long term goal! :)

What I'm immediately concerned about is not having a duplicate copy of
NSS replete with separate bugs in OpenJDK.

>>
>>>>
>>>> I think the simpler fix is to just provide an option for the calls to
>>>> the native code to use the system library rather than the included
>>>> copy (some of the new files appear to be verbatim copies of files from
>>>> NSS AFAICS).  But I need to look at this in more detail.
>>>
>>> This only redirects native calls to your centralized ones, but JRE
>>> includes
>>> a lot of pure Java providers. If they are still listed in the
>>> java.security
>>> file, your so called "Fedora Crypto Consolidation" is not 100% complete.
>>>
>>
>> It's not mine, and I was merely referencing that as to why using NSS
>> for ECC in the end was a good thing.
>
> OK. But that's a better thing (at least for Fedora).
>
> Max
>
>>
>>> Thanks
>>> Max
>>>
>>>>
>>>> Thanks,
>>>> --
>>>> Andrew :-)
>>>>
>>>> Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> Support Free Java!
>>>> Contribute to GNU Classpath and the OpenJDK
>>>> http://www.gnu.org/software/classpath
>>>> http://openjdk.java.net
>>>>
>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>>
>>>
>>
>>
>>
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8