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 <[EMAIL PROTECTED]> wrote:
> Mikhail Loenko wrote:
> > Tim
> >
> > On 2/13/06, Tim Ellison <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
> >>>> IBM Java technology centre, UK.
> >>>>
> >> --
> >>
> >> Tim Ellison ([EMAIL PROTECTED])
> >> IBM Java technology centre, UK.
> >>
> >
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
