You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Loenko <ml...@gmail.com> on 2006/02/10 13:38:07 UTC
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Geir
Sounds like no one objects to the proposal itself, the discussion is about the
naming. Could you please approve/decline new componentization?
Thanks,
Mikhail
On 1/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Stepan Mishura wrote:
> >> Sounds dirty. How about security-x?
> >>
> >
> > Ok. I named it by analogy with x-net. Your variant works for me.
>
> x-net has the same issue for me. I figure that net-x is better too
> because it will sit next to net in a directory/IDE package tree, etc...
> (just like security-x near security)
>
> geir
>
> >
> > Thanks,
> > Stepan
> >
> >
> > On 1/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> Sounds dirty. How about security-x?
> >>
> >> Stepan Mishura wrote:
> >>> I agree with the proposal and I'm ready to start working on a patch for
> >>> splitting 'security2' into suggested components and integrating them
> >> with
> >>> the current build.
> >>>
> >>> Also I'd like to suggest a name for a new component: 'x-security'.
> >>>
> >>> Thanks,
> >>> Stepan Mishura
> >>> Intel Middleware Products Division
> >>>
> >>>
> >>>
> >>> On 1/19/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >>>> Hello
> >>>>
> >>>> Let's start a different thread for that.
> >>>>
> >>>> I suggest revisiting current componentization for security related
> >> parts.
> >>>> Now we have for example crypto architecture in security module but
> >>>> crypto extension in the crypto module.
> >>>>
> >>>> See natural components in the UserGuide
> >>>> http://java.sun.com/j2se/1.5.0/docs/guide/security/
> >>>>
> >>>> The proposal is to have 3 components:
> >>>> 1. general security & crypto
> >>>> 2. ssl
> >>>> 3. jaas
> >>>>
> >>>> The logical content of those components would be:
> >>>> 1.
> >>>> - General Security
> >>>> - Certification Path
> >>>> - JCE
> >>>>
> >>>> 2.
> >>>> - JSSE
> >>>>
> >>>> 3.
> >>>> - JAAS
> >>>> - JGSS
> >>>> - SASL
> >>>>
> >>>>
> >>>> Physical content of those components:
> >>>>
> >>>> 1.
> >>>> java.security
> >>>> javax.crypto
> >>>> javax.security.cert
> >>>> 2.
> >>>> javax.net
> >>>> 3.
> >>>> javax.security w/o javax.security.cert
> >>>> org.ietf
> >>>>
> >>>> Opinions?
> >>>>
> >>>> Thanks,
> >>>> Mikhail Loenko
> >>>> Intel Middleware Products Division
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
>
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Diego Mercado <me...@gmail.com>.
javax.crypto is an "exportable" package: it's defined as an extension
(JCE) that has key and parameters' export restrictions defined in
JAVA_HOME/lib/security/local_policy.jar and
JAVA_HOME/lib/security/US_export_policy.jar
If you don't define such restrictions its make sense to merge JCE with JCA.
Regards,
Diego
On 2/10/06, Tim Ellison <t....@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.
>
--
Diego
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Leo Simons <ma...@leosimons.com>.
/me points at stuff worth saving...
On Wed, Feb 15, 2006 at 10:23:53AM +0000, Tim Ellison wrote:
<thoughts on modularity among other things>
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> Sounds reasonable.
>
> Sure, I can make 'getInstance' functionality visible as an internal API.
>
> So we put classes that has many internal dependencies into the same component,
> but not only that. For example java.lang.Error and java.lang.Ecxeption do not
> have internal dependencies but we put them into the same component.
I agree, let's not split a package across multiple modules(*)
(*) the exception that proves the rule here is KERNEL, which does
contain package fragments. But KERNEL is special.
> Having internal dependency is not the only reasong to go into the same
> component. Other reasons could be belonging to the same package or having
> some semantical connection.
I agree.
> For example I'd put java.security.cert and javax.security.cert into the same
> component.
Sounds great. (In this case the 'x' is merely an artifact of Java's
history.)
> What do you think?
+1
Regards,
Tim
> On 2/15/06, Tim Ellison <t....@gmail.com> wrote:
>> Mikhail Loenko wrote:
>>> There is coupling.
>>> BTW... Could you give an example of "close" and "weak" coupling?
>> Sure. The goal is to define modules that represent functional units
>> whose implementation can be contained within the module as much as
>> possible. The measure of coupling is the number of internal-API
>> dependencies shared between two modules. (Internal-APIs are those that
>> Anton described, and that we are proposing to put into
>> org.apache.harmony.<module_name>.<whatever> packages and explicitly
>> export from the module.)
>>
>> For example, we have code like LUNI and NIO that require some
>> non-Java-API dependencies upon one another, but these are 'weakly'
>> coupled because they are coupled by a small number of 'internal APIs'.
>>
>> Where the code has a large number of implementation dependencies that
>> you would not want to export then that is an indication of close
>> coupling. So, for example, if we tried to separate java.io into its own
>> module we would have lots of impl dependencies between that module and
>> LUNI that would indicate poor modularity. Similarly trying to move the
>> NIO buffers impls out to a separate module to NIO would result in those
>> two modules being closely coupled.
>>
>>> The following two groups of classes use the same internal stuff:
>>> GROUP1 (use/provide inernal implementation of 'getInstance' ):
>> Can you make this visible as an internal API (e.g. exported factory type)?
>>
>>> java.security.AlgorithmParameterGenerator
>>> java.security.AlgorithmParameters
>>> java.security.KeyFactory
>>> java.security.KeyPairGenerator
>>> java.security.KeyStore
>>> java.security.KeyStoreSpi
>>> java.security.MessageDigest
>>> java.security.Provider
>>> java.security.SecureRandom
>>> java.security.Security
>>> java.security.Signature
>>> java.security.cert.CertPathBuilder
>>> java.security.cert.CertPathValidator
>>> java.security.cert.CertStore
>>> java.security.cert.CertificateFactory
>>> javax.crypto.Cipher
>>> javax.crypto.ExemptionMechanism
>>> javax.crypto.KeyAgreement
>>> javax.crypto.KeyGenerator
>>> javax.crypto.Mac
>>> javax.crypto.SecretKeyFactory
>>> javax.net.ssl.KeyManagerFactory
>>> javax.net.ssl.SSLContext
>>> javax.net.ssl.SSLServerSocketFactory
>>> javax.net.ssl.SSLSocketFactory
>>> javax.net.ssl.TrustManagerFactory
>>>
>>> GROUP2 (all use internal implementation of ASN.1):
>>
>> The ASN.1 code is a good example of an internal-API that we would want
>> to expose to other module developers.
>>
>> To be clear, we are not extending the Java API here, just making it
>> visible as a contract that replacements to <whatever module implements
>> it> must conform.
>>
>>> java.security.cert.PolicyQualifierInfo
>>> java.security.cert.TrustAnchor
>>> java.security.cert.X509CRLSelector
>>> java.security.cert.X509CertSelector
>>> javax.crypto.EncryptedPrivateKeyInfo
>>> javax.security.auth.kerberos.KerberosKey
>>> javax.security.auth.kerberos.KerberosTicket
>>>
>>> All other dependencies seem to be public ones.
>> Sounds good.
>>
>> Regards,
>> Tim
>>
>>
>>> On 2/14/06, Tim Ellison <t....@gmail.com> wrote:
>>>> Mikhail Loenko wrote:
>>>>> Tim
>>>>>
>>>>> On 2/13/06, Tim Ellison <t....@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....@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.
>>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Mikhail Loenko <ml...@gmail.com>.
Sounds reasonable.
Sure, I can make 'getInstance' functionality visible as an internal API.
So we put classes that has many internal dependencies into the same component,
but not only that. For example java.lang.Error and java.lang.Ecxeption do not
have internal dependencies but we put them into the same component.
Having internal dependency is not the only reasong to go into the same
component. Other reasons could be belonging to the same package or having
some semantical connection.
For example I'd put java.security.cert and javax.security.cert into the same
component.
What do you think?
Thanks,
Mikhail
On 2/15/06, Tim Ellison <t....@gmail.com> wrote:
> Mikhail Loenko wrote:
> > There is coupling.
> > BTW... Could you give an example of "close" and "weak" coupling?
>
> Sure. The goal is to define modules that represent functional units
> whose implementation can be contained within the module as much as
> possible. The measure of coupling is the number of internal-API
> dependencies shared between two modules. (Internal-APIs are those that
> Anton described, and that we are proposing to put into
> org.apache.harmony.<module_name>.<whatever> packages and explicitly
> export from the module.)
>
> For example, we have code like LUNI and NIO that require some
> non-Java-API dependencies upon one another, but these are 'weakly'
> coupled because they are coupled by a small number of 'internal APIs'.
>
> Where the code has a large number of implementation dependencies that
> you would not want to export then that is an indication of close
> coupling. So, for example, if we tried to separate java.io into its own
> module we would have lots of impl dependencies between that module and
> LUNI that would indicate poor modularity. Similarly trying to move the
> NIO buffers impls out to a separate module to NIO would result in those
> two modules being closely coupled.
>
> >
> > The following two groups of classes use the same internal stuff:
> > GROUP1 (use/provide inernal implementation of 'getInstance' ):
>
> Can you make this visible as an internal API (e.g. exported factory type)?
>
> > java.security.AlgorithmParameterGenerator
> > java.security.AlgorithmParameters
> > java.security.KeyFactory
> > java.security.KeyPairGenerator
> > java.security.KeyStore
> > java.security.KeyStoreSpi
> > java.security.MessageDigest
> > java.security.Provider
> > java.security.SecureRandom
> > java.security.Security
> > java.security.Signature
> > java.security.cert.CertPathBuilder
> > java.security.cert.CertPathValidator
> > java.security.cert.CertStore
> > java.security.cert.CertificateFactory
> > javax.crypto.Cipher
> > javax.crypto.ExemptionMechanism
> > javax.crypto.KeyAgreement
> > javax.crypto.KeyGenerator
> > javax.crypto.Mac
> > javax.crypto.SecretKeyFactory
> > javax.net.ssl.KeyManagerFactory
> > javax.net.ssl.SSLContext
> > javax.net.ssl.SSLServerSocketFactory
> > javax.net.ssl.SSLSocketFactory
> > javax.net.ssl.TrustManagerFactory
> >
> > GROUP2 (all use internal implementation of ASN.1):
>
>
> The ASN.1 code is a good example of an internal-API that we would want
> to expose to other module developers.
>
> To be clear, we are not extending the Java API here, just making it
> visible as a contract that replacements to <whatever module implements
> it> must conform.
>
> > java.security.cert.PolicyQualifierInfo
> > java.security.cert.TrustAnchor
> > java.security.cert.X509CRLSelector
> > java.security.cert.X509CertSelector
> > javax.crypto.EncryptedPrivateKeyInfo
> > javax.security.auth.kerberos.KerberosKey
> > javax.security.auth.kerberos.KerberosTicket
> >
> > All other dependencies seem to be public ones.
>
> Sounds good.
>
> Regards,
> Tim
>
>
> > On 2/14/06, Tim Ellison <t....@gmail.com> wrote:
> >> Mikhail Loenko wrote:
> >>> Tim
> >>>
> >>> On 2/13/06, Tim Ellison <t....@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....@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.
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> There is coupling.
> BTW... Could you give an example of "close" and "weak" coupling?
Sure. The goal is to define modules that represent functional units
whose implementation can be contained within the module as much as
possible. The measure of coupling is the number of internal-API
dependencies shared between two modules. (Internal-APIs are those that
Anton described, and that we are proposing to put into
org.apache.harmony.<module_name>.<whatever> packages and explicitly
export from the module.)
For example, we have code like LUNI and NIO that require some
non-Java-API dependencies upon one another, but these are 'weakly'
coupled because they are coupled by a small number of 'internal APIs'.
Where the code has a large number of implementation dependencies that
you would not want to export then that is an indication of close
coupling. So, for example, if we tried to separate java.io into its own
module we would have lots of impl dependencies between that module and
LUNI that would indicate poor modularity. Similarly trying to move the
NIO buffers impls out to a separate module to NIO would result in those
two modules being closely coupled.
>
> The following two groups of classes use the same internal stuff:
> GROUP1 (use/provide inernal implementation of 'getInstance' ):
Can you make this visible as an internal API (e.g. exported factory type)?
> java.security.AlgorithmParameterGenerator
> java.security.AlgorithmParameters
> java.security.KeyFactory
> java.security.KeyPairGenerator
> java.security.KeyStore
> java.security.KeyStoreSpi
> java.security.MessageDigest
> java.security.Provider
> java.security.SecureRandom
> java.security.Security
> java.security.Signature
> java.security.cert.CertPathBuilder
> java.security.cert.CertPathValidator
> java.security.cert.CertStore
> java.security.cert.CertificateFactory
> javax.crypto.Cipher
> javax.crypto.ExemptionMechanism
> javax.crypto.KeyAgreement
> javax.crypto.KeyGenerator
> javax.crypto.Mac
> javax.crypto.SecretKeyFactory
> javax.net.ssl.KeyManagerFactory
> javax.net.ssl.SSLContext
> javax.net.ssl.SSLServerSocketFactory
> javax.net.ssl.SSLSocketFactory
> javax.net.ssl.TrustManagerFactory
>
> GROUP2 (all use internal implementation of ASN.1):
The ASN.1 code is a good example of an internal-API that we would want
to expose to other module developers.
To be clear, we are not extending the Java API here, just making it
visible as a contract that replacements to <whatever module implements
it> must conform.
> java.security.cert.PolicyQualifierInfo
> java.security.cert.TrustAnchor
> java.security.cert.X509CRLSelector
> java.security.cert.X509CertSelector
> javax.crypto.EncryptedPrivateKeyInfo
> javax.security.auth.kerberos.KerberosKey
> javax.security.auth.kerberos.KerberosTicket
>
> All other dependencies seem to be public ones.
Sounds good.
Regards,
Tim
> On 2/14/06, Tim Ellison <t....@gmail.com> wrote:
>> Mikhail Loenko wrote:
>>> Tim
>>>
>>> On 2/13/06, Tim Ellison <t....@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....@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.
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Mikhail Loenko <ml...@gmail.com>.
There is coupling.
BTW... Could you give an example of "close" and "weak" coupling?
The following two groups of classes use the same internal stuff:
GROUP1 (use/provide inernal implementation of 'getInstance' ):
java.security.AlgorithmParameterGenerator
java.security.AlgorithmParameters
java.security.KeyFactory
java.security.KeyPairGenerator
java.security.KeyStore
java.security.KeyStoreSpi
java.security.MessageDigest
java.security.Provider
java.security.SecureRandom
java.security.Security
java.security.Signature
java.security.cert.CertPathBuilder
java.security.cert.CertPathValidator
java.security.cert.CertStore
java.security.cert.CertificateFactory
javax.crypto.Cipher
javax.crypto.ExemptionMechanism
javax.crypto.KeyAgreement
javax.crypto.KeyGenerator
javax.crypto.Mac
javax.crypto.SecretKeyFactory
javax.net.ssl.KeyManagerFactory
javax.net.ssl.SSLContext
javax.net.ssl.SSLServerSocketFactory
javax.net.ssl.SSLSocketFactory
javax.net.ssl.TrustManagerFactory
GROUP2 (all use internal implementation of ASN.1):
java.security.cert.PolicyQualifierInfo
java.security.cert.TrustAnchor
java.security.cert.X509CRLSelector
java.security.cert.X509CertSelector
javax.crypto.EncryptedPrivateKeyInfo
javax.security.auth.kerberos.KerberosKey
javax.security.auth.kerberos.KerberosTicket
All other dependencies seem to be public ones.
Thanks,
Mikhail
On 2/14/06, Tim Ellison <t....@gmail.com> wrote:
> Mikhail Loenko wrote:
> > Tim
> >
> > On 2/13/06, Tim Ellison <t....@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....@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.
>
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> Tim
>
> On 2/13/06, Tim Ellison <t....@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....@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.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Mikhail Loenko <ml...@gmail.com>.
Tim
On 2/13/06, Tim Ellison <t....@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.
Thanks,
Mikhail
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....@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.
>
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Tim Ellison <t....@gmail.com>.
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. 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....@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.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Mikhail Loenko <ml...@gmail.com>.
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'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....@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.
>
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Tim Ellison <t....@gmail.com>.
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.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Mikhail Loenko <ml...@gmail.com>.
x-net is a separate module according to both original and proposed
componentization.
What I'd like to propose is:
1. separate Authentication and Authorization stuff (javax.security
package) from general security
2. unite crypto (java.security) and crypto extension (javax.crypto)
It would make componentization more natural, see also my first posting
in this thread:
> >>>>> On 1/19/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >>>>>> Hello
> >>>>>>
> >>>>>> Let's start a different thread for that.
> >>>>>>
> >>>>>> I suggest revisiting current componentization for security related
> >>>> parts.
> >>>>>> Now we have for example crypto architecture in security module but
> >>>>>> crypto extension in the crypto module.
> >>>>>>
> >>>>>> See natural components in the UserGuide
> >>>>>> http://java.sun.com/j2se/1.5.0/docs/guide/security/
> >>>>>>
> >>>>>> The proposal is to have 3 components:
> >>>>>> 1. general security & crypto
> >>>>>> 2. ssl
> >>>>>> 3. jaas
> >>>>>>
> >>>>>> The logical content of those components would be:
> >>>>>> 1.
> >>>>>> - General Security
> >>>>>> - Certification Path
> >>>>>> - JCE
> >>>>>>
> >>>>>> 2.
> >>>>>> - JSSE
> >>>>>>
> >>>>>> 3.
> >>>>>> - JAAS
> >>>>>> - JGSS
> >>>>>> - SASL
> >>>>>>
> >>>>>>
> >>>>>> Physical content of those components:
> >>>>>>
> >>>>>> 1.
> >>>>>> java.security
> >>>>>> javax.crypto
> >>>>>> javax.security.cert
> >>>>>> 2.
> >>>>>> javax.net
> >>>>>> 3.
> >>>>>> javax.security w/o javax.security.cert
> >>>>>> org.ietf
> >>>>>>
> >>>>>> Opinions?
Thanks,
Mikhail.
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I don't understand. I did the breakout of x-net...
Mikhail Loenko wrote:
> Geir
>
> Sounds like no one objects to the proposal itself, the discussion is about the
> naming. Could you please approve/decline new componentization?
>
> Thanks,
> Mikhail
>
> On 1/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> Stepan Mishura wrote:
>>>> Sounds dirty. How about security-x?
>>>>
>>> Ok. I named it by analogy with x-net. Your variant works for me.
>> x-net has the same issue for me. I figure that net-x is better too
>> because it will sit next to net in a directory/IDE package tree, etc...
>> (just like security-x near security)
>>
>> geir
>>
>>> Thanks,
>>> Stepan
>>>
>>>
>>> On 1/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> Sounds dirty. How about security-x?
>>>>
>>>> Stepan Mishura wrote:
>>>>> I agree with the proposal and I'm ready to start working on a patch for
>>>>> splitting 'security2' into suggested components and integrating them
>>>> with
>>>>> the current build.
>>>>>
>>>>> Also I'd like to suggest a name for a new component: 'x-security'.
>>>>>
>>>>> Thanks,
>>>>> Stepan Mishura
>>>>> Intel Middleware Products Division
>>>>>
>>>>>
>>>>>
>>>>> On 1/19/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>>>> Hello
>>>>>>
>>>>>> Let's start a different thread for that.
>>>>>>
>>>>>> I suggest revisiting current componentization for security related
>>>> parts.
>>>>>> Now we have for example crypto architecture in security module but
>>>>>> crypto extension in the crypto module.
>>>>>>
>>>>>> See natural components in the UserGuide
>>>>>> http://java.sun.com/j2se/1.5.0/docs/guide/security/
>>>>>>
>>>>>> The proposal is to have 3 components:
>>>>>> 1. general security & crypto
>>>>>> 2. ssl
>>>>>> 3. jaas
>>>>>>
>>>>>> The logical content of those components would be:
>>>>>> 1.
>>>>>> - General Security
>>>>>> - Certification Path
>>>>>> - JCE
>>>>>>
>>>>>> 2.
>>>>>> - JSSE
>>>>>>
>>>>>> 3.
>>>>>> - JAAS
>>>>>> - JGSS
>>>>>> - SASL
>>>>>>
>>>>>>
>>>>>> Physical content of those components:
>>>>>>
>>>>>> 1.
>>>>>> java.security
>>>>>> javax.crypto
>>>>>> javax.security.cert
>>>>>> 2.
>>>>>> javax.net
>>>>>> 3.
>>>>>> javax.security w/o javax.security.cert
>>>>>> org.ietf
>>>>>>
>>>>>> Opinions?
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail Loenko
>>>>>> Intel Middleware Products Division
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>
>
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Posted by Mikhail Loenko <ml...@gmail.com>.
Tim,
The goal is to unite JCA and JCE (crypto and crypto extension).
JCA is a part of general security...
Another goal is to separate Authentication and Authorization stuff from
general security.
Thanks,
Mikhail
Re: [classlib] proposal to revisit componentization for security
(was: Re: problems with security2)
Posted by Tim Ellison <t....@gmail.com>.
Why would you put JCE and general security together?
Regards,
Tim
Mikhail Loenko wrote:
> Geir
>
> Sounds like no one objects to the proposal itself, the discussion is about the
> naming. Could you please approve/decline new componentization?
>
> Thanks,
> Mikhail
>
> On 1/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> Stepan Mishura wrote:
>>>> Sounds dirty. How about security-x?
>>>>
>>> Ok. I named it by analogy with x-net. Your variant works for me.
>> x-net has the same issue for me. I figure that net-x is better too
>> because it will sit next to net in a directory/IDE package tree, etc...
>> (just like security-x near security)
>>
>> geir
>>
>>> Thanks,
>>> Stepan
>>>
>>>
>>> On 1/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> Sounds dirty. How about security-x?
>>>>
>>>> Stepan Mishura wrote:
>>>>> I agree with the proposal and I'm ready to start working on a patch for
>>>>> splitting 'security2' into suggested components and integrating them
>>>> with
>>>>> the current build.
>>>>>
>>>>> Also I'd like to suggest a name for a new component: 'x-security'.
>>>>>
>>>>> Thanks,
>>>>> Stepan Mishura
>>>>> Intel Middleware Products Division
>>>>>
>>>>>
>>>>>
>>>>> On 1/19/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>>>> Hello
>>>>>>
>>>>>> Let's start a different thread for that.
>>>>>>
>>>>>> I suggest revisiting current componentization for security related
>>>> parts.
>>>>>> Now we have for example crypto architecture in security module but
>>>>>> crypto extension in the crypto module.
>>>>>>
>>>>>> See natural components in the UserGuide
>>>>>> http://java.sun.com/j2se/1.5.0/docs/guide/security/
>>>>>>
>>>>>> The proposal is to have 3 components:
>>>>>> 1. general security & crypto
>>>>>> 2. ssl
>>>>>> 3. jaas
>>>>>>
>>>>>> The logical content of those components would be:
>>>>>> 1.
>>>>>> - General Security
>>>>>> - Certification Path
>>>>>> - JCE
>>>>>>
>>>>>> 2.
>>>>>> - JSSE
>>>>>>
>>>>>> 3.
>>>>>> - JAAS
>>>>>> - JGSS
>>>>>> - SASL
>>>>>>
>>>>>>
>>>>>> Physical content of those components:
>>>>>>
>>>>>> 1.
>>>>>> java.security
>>>>>> javax.crypto
>>>>>> javax.security.cert
>>>>>> 2.
>>>>>> javax.net
>>>>>> 3.
>>>>>> javax.security w/o javax.security.cert
>>>>>> org.ietf
>>>>>>
>>>>>> Opinions?
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail Loenko
>>>>>> Intel Middleware Products Division
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.