Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 66.249.92.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JfpLNZP2uwvStbKiNImu1mbuxV345BWOvENiUqidGAY1V/nIZ8oFo64QIxSVh/az7XNG+F/sNyWEJXygTaxBSGH7hs0Kjbray6huM4w4VkVyuvfK7MY5whX3iz7yZdz9M114jdekccxgbeZ4eNLJ5ya8luvfV+umKw8eA6RCRiI=
Message-ID: <906dd82e0602150245g17638b8aqfb17837a6eb70ad0@mail.gmail.com>
Date: Wed, 15 Feb 2006 16:45:43 +0600
From: Mikhail Loenko <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] proposal to revisit componentization for security
 (was: Re: problems with security2)
In-Reply-To: <43F30139.1040004@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.com>
	 <43EC9E78.3080202@pobox.com>
	 <906dd82e0602100727r5526e9c0r9652936b533e1d2b@mail.gmail.com>
	 <43ECBCC0.1080606@gmail.com>
	 <906dd82e0602100848h49b1d54au15d900d90ee62540@mail.gmail.com>
	 <43F0B9E9.5000707@gmail.com>
	 <906dd82e0602132136t15b977f9l9bbe37df6fa17275@mail.gmail.com>
	 <43F1B7D3.9000204@gmail.com>
	 <906dd82e0602140327i1f13a90hed0459f7f72e2b5@mail.gmail.com>
	 <43F30139.1040004@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 compone=
nt,
but not only that. For example java.lang.Error and java.lang.Ecxeption do n=
ot
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 sam=
e
component.

What do you think?

Thanks,
Mikhail

On 2/15/06, Tim Ellison <t.p.ellison@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.p.ellison@gmail.com> wrote:
> >> 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 se=
curity.
> >>>>> (According to SUN general security includes also crypto architectur=
e)
> >>>> I wouldn't get too hung up about where Sun put it.  There is likely =
a
> >>>> different partitioning about where the architectural/semantic bounda=
ries
> >>>> 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 th=
e
> >>>> 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 J=
DK
> >>>> By process of exclusion - the other modules ('crypto', 'x-net' and
> >>>> 'jaas') are self-contained and can be removed without breaking any o=
ther
> >>>> 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.Call=
backHandler
> >>>
> >>> 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 module=
s
> >> 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.securit=
y
> >>>>>>> package) from general security
> >>>>>> Ok, so I can see this.
> >>>>>>
> >>>>>>> 2. unite crypto (java.security) and crypto extension (javax.crypt=
o)
> >>>>>> but this makes no sense to me.  Why would you want to unite JCE wi=
th
> >>>>>> 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 o=
f
> >>>>>> 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.
>