Bug 426152
| Summary: | Review Request: openCryptoki - An open-source PKCS#11 implementation | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kent Yoder <key> |
| Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | fedora-package-review, mschmidt, notting, rcritten, rrelyea |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-11-05 15:43:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 394941 | ||
|
Description
Kent Yoder
2007-12-18 20:40:04 UTC
How does this relate to NSS's PKCS#11 support? NSS should be able to use openCryptoki as a PKCS#11 provider. For instance today you can go into firefox, Edit > Preferences > Advanced > Security > Security Devices, and add openCryptoki as a provider. This then funnels the crypto and certificate and key storage through openCryptoki. If you enable the TPM token, all your certificates will be protected by the TPM at rest. openCryptoki is also the gateway to s390 hardware crypto, so there you'd get hardware acceleration. Kent Why would we want to funnel all crypto and certificates through a non-NSS mechanism? It wouldn't be a non-NSS mechanism, just a different provider. By default, NSS contains a software-only PKCS#11 implementation it uses internally. openCryptoki is just another implementation of the APIs NSS is using to interface to this internal implementation to store certificates and do crypto. You might want to do this for the reasons I mentioned earlier, to get hardware acceleration or take advantage of secure keys in the TPM or other hardware. This is not the only use of PKCS#11 by the way, the Java JCE interfaces to PKCS#11 as well. As far as I know, NSS doesn't ship a library exposing its PKCS#11 APIs for other software packages to take advantage of, so without openCryptoki the JCE could not be hardware accelerated. I guess the question is, is openCryptoki an add-on or a "competitor"? If I'm understanding correctly, it's an add-on. It sounds like openCryptoki provides a pkcs#11 abstraction layer for certain hardware, allowing it to be used with other applications that can talk to pkcs#11 APIs. NSS can do so. NSS offers a tool "modutil" which can be used to load an external pkcs#11 module into a set of user preferences (the cert dbs). The binding will be recorded in file secmod.db which is stored next to your key3.db and cert8.db Yep, I would consider it an add-on. Different PKCS#11 implementations will support different sets of hardware, so many can co-exist. I'm a bit confused by this ticket. The last comment was made last year, there doesn't seem to be any actual package to review, and the only reference is to another ticket which nobody can actually look at. Well, its been another four months and nobody has stepped up to clear up the confusion. I'm just going to close this. I've submitted another openCryptoki review request (with an actual package). See bug 512954. *** This bug has been marked as a duplicate of bug 512954 *** |