[haiku-development] Re: RFC: password roster API
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 29 Jan 2011 16:45:13 +0100
On 2011-01-29 at 15:50:43 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> > On 2011-01-28 at 19:52:51 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > > wrote:
> > [ ... ]
> > > > While the primary purpose should be for passwords, the Mac OS X
> > > > Keychain at least also supports certificates.
> > > I'm not yet sure what would be the objective to put those there,
> > > since
> > > the access to certificates is usually not restricted. It is
> > > security
> > > related, and could be managed by the same application, but I don't
> > > really think that BKeyStore would be the right place for it.
> > I think the point is that these would be *client* certificates, which
> > usually come with a passphrase that you need to provide before they
> > can be
> > accessed.
>
> That would make some sense, and it should be no problem to store those
> using the (suggested) BKeyStore. But at least the Mac OS X keychain API
> allows to store data like certificates unencrypted.
Ah, ok. Most browsers do the same with client certificates (you need to
give the passphrase once when importing the certificate). I guess one could
argue that such a unencrypted client certificate is the (to be protected)
token which is required to gain access to some service. So, it could just
be handled exactly like a password. But I'm not sure that this could be
implemented easily, as most of the infrastructure (e.g. applications using
openssl) would need to be hacked somewhat in order to support fetching
their certificates from the key-store instead of a file.
Personally, I would leave certificates out of the key-store for now (and
just provide support for their passphrases).
cheers,
Oliver
Other related posts:
