where 'o where to store certificates and keys

[Bob Relyea]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3340 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20050419/c41ef079/attachment.bin>