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:
Publication of the user's public key within the DNS, which is periodically requested by the TelHosting Provider for encrypting data
Access to private data via the Tel-Proxy service
Encryption of the SO API password
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.
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:
represents a valid PKCS#12 PFX PDU
contains a single public key, and the algorithm of the key is supported
does not contain unencrypted private keys
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.
To operate with public and private keys, a client application needs to:
Complete the authentication procedure, see Client Initialization.
Log into the SO system using the SO ID and API password retrieved at the previous step.
Call the getKey method to retrieve private and public keys as necessary.