harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Loenko <mloe...@gmail.com>
Subject Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Date Tue, 14 Feb 2006 05:36:21 GMT
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.

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.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.
>

Mime
View raw message