PKI 10.4 CMC Shared Token

Overview

Update: this feature has been implemented and documented in PKI 10.5 CMC Shared Token.

Note, this area has not yet been implemented at time of writing. Please consider this a high-level design.

In prior releases, areas where shared secrets are needed were done with a dummy class SharedSecret, which implements ISharedToken, where a hardcoded string testing was returned. In this release, a real class will be written to respond to the getSharedToken(…​) method of the ISharedToken class. CMC features that will take advantage of the new ISharedToken class include:

• IdentifyProofV2

• popLinkWitnessV2

• revokeRequest

Framework

RFC5272 does not dictate how the shared secret provision should be implemented. For 10.4, while we will provide a default implementation, we will continue the tradition of allowing the flexibility for sites to implement their own mechanism by making the shared secret provision a Java Plugin framework, much like how the existing authentication, authorization, and many other mechanisms are provided in the current system.

Repository

By default, we use CA’s internal LDAP repository for storing uid/sharedToken information. The LDAP instance will be configurable so that an external LDAP system could be used. The configuration will be much like like LDAP-based authentication plugin is configured.

Protection

Like many other areas that require protection of the directory entries, mechanism much like the KRA’s key archival/recovery mechanism will be used to encrypt/decrypt the shared secrets stored in the repository. The mechanism involves generation of a symmetric key that is used to encrypt the shared secrete, a system-wide certificate that is used to encrypt the per-entry symmetric key. Each repository entry will contain at the minimum (userID, symm-encrypted-sharedSecret, system-cert-encrypted-symm). Retrieval of the entry is based on the usrID provided through the relevant CMC requests id_cmc_identification control.

One-Time Use Provision

One-Time use can be configured so that sites can choose to disallow a shared secret being reused.

Set Up

In the first release of this implementation, administrators are expected to:

• use auxiliary mechanism to generate the shared secrets

• Use any LDAP mechanisms to store the secret into corresponding user entries

  • this could be done by enhancing pki-user

• Use any site-approved method to communicate the shared secrets to their intended users.

Future

In the future, we should improve on usability.