harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Date Tue, 14 Feb 2006 10:58:27 GMT
Mikhail Loenko wrote:
> Tim
> 
> On 2/13/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Mikhail Loenko wrote:
>>> It looks good but it is not clear where would you put certification stuff.
>>> According to SUN's guide it is splitted between JSSE and general security.
>>> (According to SUN general security includes also crypto architecture)
>> I wouldn't get too hung up about where Sun put it.  There is likely a
>> different partitioning about where the architectural/semantic boundaries
>> are best placed, and how we componentize the implementation.
>>
>> Looking into this a bit more, the certificate management
>> (java.security.cert.*) code should likely go in 'general security'.
>>
>> It is mostly instinct behind the decision, but that was formed by the
>> following reasoning:
>>
>> Historical - JCE, JSSE and JAAS used to be optional packages for the JDK
>> at a time when the certificate management code was included in the JDK
>> By process of exclusion - the other modules ('crypto', 'x-net' and
>> 'jaas') are self-contained and can be removed without breaking any other
>> APIs.
> 
> That was in the past. In 1.5 for example
>     java.security.KeyStore.SecretKeyEntry.getSecretKey()
> returns
>     javax.crypto.SecretKey
> 
> Method
>     java.security.AuthProvider.login()
> takes  arguments
>     javax.security.auth.Subject and javax.security.auth.callback.CallbackHandler
> 
> Another example
>     java.net.SecureCacheResponse.getPeerPrincipal()
> throws
>     javax.net.ssl.SSLPeerUnverifiedException
> 
> So, none of the components is self-contained.

Right, but these are all public type dependencies, for sure the modules
will have many dependencies on other modules' public types.
Do you see a close coupling of the implementation types too?

Regards,
Tim

> Removing certificate management would break APIs in java.util.jar
>> and java.security so it doesn't make sense to separate it from them.
>>
>> US Export Control office is less interested in digital
>> signing/verification than they are in the cryptography and secure
>> communications packages.  Keeping them pluggable makes sense.
>>
>> Perhaps we should name the 'jaas' package 'auth'.  JAAS may be a
>> protected trademark.  The org.ietf.jgss package may belong in 'auth' as
>> well.
>>
>> Regards,
>> Tim
>>
>>> I'd rather put it  into crypto (or maybe into x-net) - all of them use
>>> service-provider architecture. What do you think?
>>>
>>> Thanks,
>>> Mikhail
>>>
>>> On 2/10/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>> Mikhail Loenko wrote:
>>>>> What I'd like to propose is:
>>>>>
>>>>> 1. separate Authentication and Authorization stuff (javax.security
>>>>> package) from general security
>>>> Ok, so I can see this.
>>>>
>>>>> 2. unite crypto (java.security) and crypto extension (javax.crypto)
>>>> but this makes no sense to me.  Why would you want to unite JCE with
>>>> general security?  There is no close coupling afaict.
>>>>
>>>> How about
>>>>  - general security
>>>>  - crypto
>>>>  - x-net
>>>>  - jaas
>>>>
>>>> there may be good reason to want to replace crypto independently of
>>>> general security.  Am I missing something?
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>> --
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message