Key Store

The system provides the ability to store a public/private key pair for each user, be it a guest user or a full member. The use of the store is manifold and allows:

The TelHosting Provider or client applications periodically request the public key for encrypting data for the associated Reader. The public key, if it exists, is published in the DNS. For that purpose, a domain name is associated with each user, named "key location". This domain name is considered to be constant over the lifetime of the account. While the domain name might be derived from the user's data, clients shall make no assumptions on the mapping, as it may change over time.

Key Format

The key is stored in the RKEY record (type 57 as defined in DNS parameters document), described in the current draft at IETF. In addition to the public key itself, a TXT record containing the user's current user name is published. It uses the same owner name as the resource record of the public key.

The key data is expected to be in the PKCS#12 format. It is stored as is in the key store. However, the store may perform validation of the given data, which tests whether the data:

The store also contains the point in time of the last update (made by an update or create operation). Client programs can use this information to determine whether key data is in sync with the SO data, and which version of data is outdated. Finally, the store contains the hash of the public key, which is retained even if the key itself has been deleted from the SO system. This way, the client application within the client initialization API can recognize the key pair that has been used for the encryption.

Using this API

To operate with public and private keys, a client application needs to:

  1. Complete the authentication procedure, see Client Initialization.

  2. Log into the SO system using the SO ID and API password retrieved at the previous step.

  3. Call the getKey method to retrieve private and public keys as necessary.