# Re: SSL API update?

David Brownell (db@Eng)
Mon, 01 Feb 1999 15:45:42 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jan Luehe: "Re: policy files and java plug-in for 1.2"
- Previous message: David Taylor: "Re: SSL API update?"
- Maybe in reply to: David Taylor: "SSL API update?"

    Date: Mon, 01 Feb 1999 15:45:42 -0800

    From: David Brownell <db@Eng>

    To: DavidTaylor@forge.com.au

    Subject: Re: SSL API update?

David Taylor wrote:
>
> > Or to put it differently -- private key management (associated
> > with user authentication, e.g. logon) and trust management are
> > not specific to SSL; there should be separate APIs for those.
> >
> > It's good if they're standard extensions ("javax.*") but that's
> > not a requirement for many purposes.
> >
> > The same issue comes up for servers who authenticate themselves,
> > and for letting clients trust the server authentication ... it's
> > really not possible to use an SSL package without such APIs!
>
> So the idea you're working towards is to separate the trust management
> API from the SSL API?

That's the way the SSL API was architected, yes. Though how
that will evolve in the future, I couldn't say -- I've not been
running those shows for quite some time now.

> The application acting as a server in an SSL conversation would need to
> register it's public key/certificate using some different API that the
> SSL implementation would call upon to get that public key/certificate if
> necessary.
>
> Likewise, the application acting as a client in an SSL conversation
> would register it's public key/certificate using the trust API and the
> SSL implementation would make the call into it if it needed to send a
> client certificate.

The trust management has more to do with saying which certificate
chains are trusted for which purposes, and then there's also that
critical need for secure access to the private keys.

For "{client,server} in an SSL conversation", I think one
should be able to substitute any other type of security
aware application ... e.g. "S/MIME reader", "S/MIME signer",
"developer code signing tool", "E-Commerce Messaging Server",
"Certificate Authority", etc.

Whether this stuff is controlled by an application or is part
of the environment in which it runs is another story though.
There are good reasons to avoid making applications care about
things they classicaly don't do correctly!

- Dave

> Is that where you're headed?
>
> Regards,
> David Taylor
> Forge Research.

- Next message: Jan Luehe: "Re: policy files and java plug-in for 1.2"
- Previous message: David Taylor: "Re: SSL API update?"
- Maybe in reply to: David Taylor: "SSL API update?"