[systemd-devel] certificate and trust store feature for systemd

Thu May 26 11:25:26 UTC 2022

Don't we have ansible on modern systems to be managed like that?

I doubt we want API to manage keys for specific applications. Sure, we
may have simplify creation of self-signed certificates with key pair. We
may standardize generation of certificate request with a key, but I
doubt we want incompatible system reimplemented by systemd.

It would be nice to have a common way to do some operations, but we have
multiple crypto libraries on Linux. We certainly do not want throw all
other away and start using just single one.

I think it would be nice if you share first the motivation for your
request. What problem are you trying to solve? What tasks are difficult
now? In what software you need them solved?

I think keys can be stored in pkcs11 storage. But a common storage for
any application seems wrong, we want permissions separate for each app.
I don't think a copy Windows API is a way to go.

I think most services requires Let's Encrypt style refreshes of certs.
Sure, a good library for integration in existing software would help.
But please do not add yet another reimplementation to systemd. It
already does too many different things in single project.

Regards,
Petr

On 5/25/22 20:59, SCOTT FIELDS wrote:
>
> The only tools I know of that manage the files in /etc/pki are part of
> “ca-certificates” and they only manage the CAs, not general app
> specific public/private keys.
>
>  
>
> And even so, command line tools aren’t APIs.
>
>  
>
> The prime reason you want an actual API that’s widely available is it
> encourages other solution providers to leverage it.
>
>  
>
> Again, the CAPI/CNG API in Windows Is an example.
>
>  
>
> You can very easily manage all kinds of key management via a central
> API, and in turn, you can then leverage that infrastructure in other
> tools.
>
> What I would then like to see is an engine for OpenSSL be able to
> leverage this and then have access to the keychain infrastructure
> without the file management involved.
>
>  
>
> This is something you can do with OpenSSL on Windows via the CAPI
> engine (or other API solutions that have their own engine solution in
> OpenSSL), for instance.
>
>  
>
> Since most secure products in Linux use OpenSSL, this almost
> immediately would also give them access to a centrally managed keystore.
>
>  
>
> That’s what I would like to see.
>
>  
>
> *From:*Barry Scott <barry at barrys-emacs.org>
> *Sent:* Wednesday, May 25, 2022 1:30 PM
> *To:* SCOTT FIELDS <Scott.Fields at kyndryl.com>
> *Cc:* systemd-devel at lists.freedesktop.org
> *Subject:* [EXTERNAL] Re: [systemd-devel] certificate and trust store
> feature for systemd
>
>  
>
> On 25 May 2022, at 19:22, SCOTT FIELDS <Scott.Fields at kyndryl.com>
> wrote: If you’re referring to files in /etc/pki, that’s not a
> management API, like CAPI or CNG provides in Windows (and a like API
> in OSX). There are tools that you run
>
>  
>
>
>
>     On 25 May 2022, at 19:22, SCOTT FIELDS <Scott.Fields at kyndryl.com>
>     wrote:
>
>      
>
>     If you’re referring to files in /etc/pki, that’s not a management
>     API, like CAPI or CNG provides in Windows (and a like API in OSX).
>
>  
>
> There are tools that you run that manage the files. Sorry I do not
> have the details in front of me.
>
> The tools are the API at least for trust store from what I recall when
> I set it up.
>
>
>
>      
>
>     There’s a keychain solution in Gnome (GNOME/Keyring) but not
>     widely adopted that I’ve seen.
>
>  
>
> I use KDE and the kwallet is used in most apps I use. If there is an
> app in gnome that is not using the keyring
>
> then that a problem with the app surely, not the API?
>
>
>
>      
>
>     This just seems a good match to have available within systemd
>
>  
>
> I do not speak for systemd, just curious about why you think this is
> needed.
>
>  
>
> Barry
>
>  
>
>
>
>      
>
>     *From:* Barry Scott <barry at barrys-emacs.org> 
>     *Sent:* Wednesday, May 25, 2022 1:16 PM
>     *To:* SCOTT FIELDS <Scott.Fields at kyndryl.com>
>     *Cc:* systemd-devel at lists.freedesktop.org
>     *Subject:* [EXTERNAL] Re: [systemd-devel] certificate and trust
>     store feature for systemd
>
>      
>
>     On 25 May 2022, at 14:06, SCOTT FIELDS <Scott.Fields at kyndryl.com>
>     wrote: I apologize for the very general inquiry. Are there any
>     plans to have system natively support its own trust store for
>     items like CAs, x509 certs, passwords &
>
>      
>
>
>
>
>         On 25 May 2022, at 14:06, SCOTT FIELDS
>         <Scott.Fields at kyndryl.com> wrote:
>
>          
>
>         I apologize for the very general inquiry.
>
>          
>
>         Are there any plans to have system natively support its own
>         trust store for items like CAs, x509 certs, passwords &
>         truststores akin to the keychain in Windows and OS X?
>
>      
>
>     But these are solved problems on modern Linux systems aren't they?
>
>      
>
>     At least with RHEL and Fedora they have trust store and keychains.
>
>
>
>
>          
>
>         I still find the management of PKIs in /etc/pki to be problematic.
>
>      
>
>     For my home network I have my own DNS domain and CA setup. It was
>     easy to add the CA to
>
>     Fedora's trust store.
>
>
>
>
>          
>
>         Having this available as a core service within systemd using
>         like APIs either in (mostly deprecated) CAPI or the new CNG
>
>      
>
>     Barry
>
>
>
>
>          
>
>          
>
>         Scott Fields
>
>         IBM/Kyndryl
>
>         SRE – BNSF
>
>         817-593-5038 (BNSF)
>
>         scott.fields at kyndryl.com <mailto:scott.fields at kyndryl.com>
>
>         scott.fields at bnsf.com <mailto:scott.fields at bnsf.com>
>
>  
>
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220526/4e37ab7a/attachment-0001.htm>