This is a cryptographically signed message in MIME format.
John Dennis wrote:
On Tue, 2005-04-19 at 14:53 -0700, Bob Relyea wrote:
So the world is even *MORE* complicated that this.
Yes, we're aware of this complication :-)
Only about half our packages use openssl to get their SSL
implementations. The other half uses NSS.
NSS store keys in in a keyX.db file and certs in certX.db. To make
matters worst, like openSSL apps,
NSS apps typically store their own copy of the database somewhere in the
user's profile.
We're not talking about user keys and certs, rather system services
specific to the host which have public and private keys and
certificates, the obvious examples are network services providing SSL
connections, but other examples exist.
directory is an NSS app. Not all NSS apps are clients.... You still need
to worry about it in the server space.
It's a little better if this isn't around to solve the user key issue,
though that needs to be clear given
some of the responses I saw to the proposal.
I agree we need to solve this problem, but I think we need to take a
step back and understand how
each application uses it's keys and certs. Just saying the keys and
certs live in a particular directory
is not sufficient.
I wish I had seen this discussion earlier. It appears to have completely
punted on applications that use NSS.
I'll confess I'm not that familar with NSS, but if NSS wants to store
things in a .db file, and even if multiple .db files need to live in the
same directory I don't see why /etc/keys or one of its subdirs wouldn't
meet that requirement (.db files are just simple files, right?)
If you just say the .db files live in /etc/keys, then yes. The proposal
sounded like you were splitting /etc/keys into
public an private partions (implying certs go into public and keys go
into private). If you are saying /etc/keys is a
'free-for-all' and that keys and certs are stored somewhere under
/etc/keys, then yes, NSS does not have a
problem (NSS servers may need to be coerhersed, but we're assume some
server corhersion anyway. Note that
this still doesn't get all your system utilities to share their keys and
certs (you still have to
converge formats, regularize exactly where and how to find and manage
keys and certs, etc.).
But once again, just to be clear, users are NOT going to be writing
their keys/certificates in /etc/keys. If a service wants to maintain a
database of per user keys/certificates in /etc/keys I don't see a
problem with that because its the service (running with proper
permissions) who is managing that data, not the user.
NSS isn't just fore users anymore;). Actually, like openSSL, NSS has
always been used in both clients
and servers. There are several new servers coming down the pike which
are NSS based. Leaving the
users out of the picture does simplify what you are trying to do, but
you still haven't ditched NSS as a
consideration yet.
bob
smime.p7s
Description: S/MIME Cryptographic Signature
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
|
