Jump to: navigation, search


(Redirected from V3/PKCS11 in LDAP)

Name: V4/PKCS11 in LDAP
Incomplete.png Pending review
Last updated: 2015-05-5 by Mkosek


Store cryptographic objects (public and private keys, certificates) in LDAP for use by PKCS#11 soft-token module.

Use Cases

The PKCS#11 module can be plugged into various applications and provide the data to them:



The data is organized into subtrees, each representing a token in the PKCS#11 module. Access control is handled by ACIs on per-token and per-object level.

Object classes:

  • Private key - private key as per PKCS#11 spec
  • Public key - public key as per PKCS#11 spec
  • Certificate - X.509 certificate as per PKCS#11 spec
  • Trust - NSS vendor-specific trust object

The LDAP schema design is on separate page.


  • cn=DNSSEC
    • private key and public key objects
    • read and write access for IPA DNS masters, read access to public keys for everyone
  • cn=CA Certificates
    • certificate and trust objects
    • read access for everyone, write access for IPA masters
  • cn=User Keys
    • private key and certificate objects
    • read and write access to individual objects for their owner

How applications interact with PKCS#11

  • BIND v9.10b1 - File:Bind.v9.10.ltrace.pkcs11 functions.log File:Bind.v9.10.ltrace.log
    • uses digest, sign, verify, keygen and RNG functions
    • does not persist any objects
    • searches objects by CKA_CLASS, CKA_KEY_TYPE, CKA_ID, CKA_LABEL, CKA_TOKEN
  • OpenDNSSEC
    • uses digest, sign, keygen and RNG functions
    • persists private key objects with CKA_LABEL, CKA_ID, CKA_KEY_TYPE, CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_TOKEN, CKA_PRIVATE, CKA_EXTRACTABLE and key-type specific attributes
    • persists public key objects with CKA_LABEL, CKA_ID, CKA_KEY_TYPE, CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_TOKEN and key-type specific attributes
    • searches objects by CKA_CLASS, CKA_ID
    • utility "ods-hsmutil test" can test given PKCS#11 module
  • p11-kit
    • proxies function calls to external PKCS#11 module
    • does not persist any objects
  • NSS
  • OpenSSH
    • uses sign functions
    • does not persist any objects
    • searches objects by CKA_CLASS, CKA_ID, CKA_SIGN

The PKCS#11 module needs to provide cryptographic functions, either by re-using existing solution (e.g. SoftHSM) or by implementing a thin layer on top of NSS cryptographic functions.




Feature Management





Major configuration options and enablement




Updates and Upgrades

FreeIPA is going to have Vault suitable for key material storage. There was an proposal to use this Vault as private-key storage for PKCS#11 module instead of plain LDAP.

This idea was postponed because Vault implementation will take some time. For now we need to support private-keys stored in LDAP. To be future-proof, we have to have upgrade path from plain LDAP to Vault.

Please see discussion on freeipa-devel (it was focused on private keys used for DNSSEC).

There are two basic approaches:

  • (a radical one) One-shot migration:
    • Upon replica-upgrade, convert all private keys from LDAP to Vault and replace all private keys in LDAP with a reference to Vault.
    • Old clients will no longer see private keys over PKCS#11 so clients need to be upgraded.
    • This is feasible only if set of clients is very limited, e.g. only DNSSEC machinery (BIND + OpenDNSSEC) running on IPA replicas.
  • (a conservative one) Use configuration information from LDAP (e.g. in cn=etc or so) to detect if some old replicas/clients are still in the topology and run auxiliary daemon for LDAP<->Vault synchronization.



External Impact

The objects will be accessed mainly through the PKCS#11 module. The PKCS#11 module will use SSSD as backend.

Backup and Restore


Test Plan


RFE Author

Jan Cholasta