Thursday, September 1, 2011

Viewer for Certificate and Key files

So a lot of the work I do doesn't have any user interface. The best user interface is no user interface, well one that isn't needed. But recently I've been working some tools to view the plethora of certificate and key formats out there. So I couldn't resist blogging about this, because I get to use screenshots, heh.

The NLnet Foundation has been sponsoring Collabora to do some smart card work, and this is part of that. This work is part of the GCR library, and is merged into gnome-keyring master.

Here's a certificate viewer showing a certificate:


Details can then be expanded:



And here's what a key looks like.



When the file is locked (like a PKCS#12 file) it can be unlocked like this video shows. It also shows the appalling state of affairs with hundreds of certificate authoritities, dubious and otherwise.



In the next release, we'll have an "Import" button in the bottom right corner, so that the certificates and keys being viewed can be imported and used into common locations. Hopefully we'll also get able to view PGP keys in files (before importing them).

The widgets you see displaying the certificates can be used by any application from the GCR library. 


4 comments:

  1. Any advice to application authors who are stuck using NSS directly and would like to migrate their certificates so they can start using all this fancy new UI and the GTls APIs? :)

    ReplyDelete
  2. It's really easy to start integrating, and I'd like to work with you to help get these bits done :)

    Some ideas:

    * To use the certificate widget, you just use the
    GcrCertificateWidget [1]. You have to feed it a
    GcrCertificate [2], which is an easy to implement
    interface. Or just use GcrSimpleCertificate [3].

    * To use keys or anchor certificates from
    Gnome Keyring you just plug it the p11-kit proxy
    module into NSS [4]. There's an API in NSS
    for adding a PKCS#11 provider (without it being
    in the configs). And we could write some code
    that automatically adds that module in using
    SECMOD_AddNewModule and SECMOD_IsModulePresent.

    * In the next release of seahorse we'll probably
    implement editing the ~/.pki NSS certificate
    database via PKCS#11. Since seahorse will
    support PKCS#11 it's easy to manage certificates
    and keys in any database.

    This way Evolution won't necessarily have to
    carry around a certificate management interface.

    * Using the GTLS APIs for SMTP and IMAP sounds
    really cool, although it's a lot of work.
    I don't think you want to abstract away NSS
    completely though, since not much else has
    S/MIME support at that level.

    * Hopefully one day soon someone will have time to
    write an NSS backend for GIO TLS. We've tried to
    design it in such a way that it would be
    possible.

    Perhaps with what we learn integrating Evolution into things we could come up with a small GCR+NSS shim that would contain the common code for seamlessly gluing NSS apps into the system.

    [1] http://developer.gnome.org/gcr/unstable/gcr-GcrCertificateWidget.html
    [2] http://developer.gnome.org/gcr/unstable/gcr-GcrCertificate.html
    [3] http://developer.gnome.org/gcr/unstable/GcrSimpleCertificate.html
    [4] https://live.gnome.org/CryptoGlue/Integration

    ReplyDelete
  3. Better NSS integration in GNOME would be nice, but I'm also open to just flat out moving certificates to GnuTLS (if that's possible, and GnuTLS is ready for us) since that seems to be the favored security library in GNOME.

    I'm rather illiterate about this stuff, I just know I want to offload it elsewhere. Our code is old and redundant and starting to smell funny. :)

    ReplyDelete
  4. Heh. But NSS is probably the best solution for what Evolution is trying to do, by which I mean S/MIME.

    I don't think that there's a favored security library in GNOME (for better or worse). There's various reasons that different projects want to use different libraries. That's why GIO TLS exists, to allow a single way to access multiple crypto libraries.

    And that's why this CryptoGlue stuff exists, to allow those crypto libraries to act consistently.

    BTW, The only other S/MIME implementation I've looked at is gpgsm, and that has an different way of doing things and is harder to integrate.

    ReplyDelete