User Synchronization for Encryption (USE)

Retarus Email Encryption includes the management of encryption users and their S/MIME or PGP keys. In case of any changes (new users etc.), Retarus can be informed manually by the customer via Support ticket and handles the required steps in the background, which is a time-consuming process that can be a cause for delay and a source of mistake (e.g., names spelled differently).

This manual describes the possibilities and functionalities of User Synchronization for Encryption (USE), the steps to implement them, as well as detailed specifications (for example of the required structure for an import file).

Overview/general functionality

With User Synchronization for Encryption (USE), Retarus offers an alternative way of automating the
following tasks:

• Import of encryption users and assignment to groups (to apply the same policies/rules for the group)

• Creation and synchronization of S/MIME (SwissSign) and PGP keys

• Administration of customer-individual encryption policies (rules)

Checklist for initial implementation

After the encryption workshop takes place, the agreed options will be implemented on Retarus’ side.
Questions to be clarified:

• PGP or S/MIME certificates?

• Key length and validity time (default: 4096 bit / 1 year)

• Are certificates ordered via Retarus or are they bought externally and must be imported (including
  a passphrase)?

• Certificate renewal (Watchdog) desired or not? If yes, use fully automated or semi-automated
  (unchained/chained) mode?

• Single user state or aggregated state?

• Limit for maximum number of generated certificates?

• Customer admin email address for list of users to be synchronized (half-automated process),
  certificates (if created by Retarus) and reports.

Import of encryption users and assignment to groups

The encryption users of a tenant can be arranged in groups and rules can be applied to these groups.

Key target states

The key target states represent the desired final state. If a user (single person or team address etc.)
should have a certificate, the target state ‘1’ must be sent. It will be synchronized: if there is no certificate
present, it will be generated. If there is already a certificate, nothing happens.

Key import

It’s possible to import private keys (for signature, instead of creating them via USE) and public keys (to
encrypt and check signatures).

Import of public keys

The public keys must be uploaded to the implemented directory on the SFTP share. During the sync they
will be imported to our crypto solution.

Import of private keys

The private keys must be uploaded to the implemented directory on the SFTP share. During the sync they
will be imported to our crypto solution. Please note that for private keys also the passphrase has to be
synced via USE import file.

Creation and synchronization of S/MIME (SwissSign) keys

S/MIME keys can be created and then certified by SwissSign. They can also be revoked. Distinctions between team and personal certificates are possible.

Please be aware that every certificate creation is a billable transaction.

Automatic vs. semi-automatic mode

Certificate creations could be performed either in automatic mode or in semiautomatic mode.

• Automatic mode: The certificates are created instantly within the synchronization cycle.

• Semi-automatic mode: A CSV file containing human-readable instructions for the creation will be created (instead of instant fully automatic certificate creation during the sync cycle) and sent to a defined (admins) email address. This CSV could be checked on customers side and forwarded to the Retarus service desk. After the customer has sent this semi-automatic created file to the service desk it will be manually imported into the crypto appliance on the Retarus side and batch processed.

Automatic renewal of expiring S/MIME (SwissSign) certificates / USE WatchDog

S/MIME certificates that are going to expire can be renewed automatically using a pre-implemented buffer time (default 48 hrs.) to avoid disruption. If the buffer is reached, a follow-up certificate is created automatically. This could also be done in semi-automatic mode (see above).

Please be aware that every certificate creation is a billable transaction.

The Watchdog module monitors the certificate validity. It can run in “chained” or in “unchained” mode.

• Chained Mode: If there is an entry in the list and a previous certificate, a certificate will automatically be created/renewed.

• Unchained Mode: Even if there is no previous certificate (but an entry in the list), a certificate will be created (for the first time).

Initial creation and synchronization of S/MIME (SwissSign) and PGP keys

An initial sync must be performed to create all the required keys and certificates.

Creation and synchronization of PGP keys

PGP keys can be created and deleted via synchronization. The key length can be chosen (1024, 2048 or 4096 bit).

Administration of rules

The ruleset can be administered via synchronization using the USE rule notation. This allows you to
describe the target status of the ruleset in an easy, human-readable way.

Reporting

There are two different types of reports which may be sent to different target email addresses:

• Sync report

• S/MIME transactional report

Sync report

The sync report reflects all actions that were performed within the sync. Also, the errors that may have occurred. If a .ruleimport file was uploaded, the rendered result could be attached to the report email.

The report reflects every line in the input file with a prefix that indicates whether an action took place.

If a key target state ‘0’ is given and there is no active certificate, no action is needed. This case is indicated by the prefix ‘(%)’.

If a key target state ‘1’ is given and there is no active certificate, the creation is needed and performed. This case is indicated by the prefix ‘(+)’.

If a key target state ‘’ is given and there is an active certificate, the revocation is needed and performed. This case is indicated by the prefix ‘(-)’.

S/MIME transactional report

For the S/MIME transactions (creating/revoking certificates) there is also a dedicated report which is sent
out via mail to a configured email address. The created certificates may be attached in a zip file.

Pushback functionality

As an alternative or addition to receiving the reports via email, they may also be stored on the SFTP share
to be collected.

Combination of functionalities & USE cases

All functionalities described above can be combined individually to reflect your requirements and use cases. This section shows exemplary use cases; of course, other combinations of the USE functionalities are possible as well.

The general process is always the same:

1. A USE import file (and / or a ruleimport file) is created by the customer (see Nr. 13) and uploaded to the Retarus SFTP share.

2. The USE import file (and, if present, the ruleimport file) is preprocessed and checked for semantic errors on the Retarus side. If parsing errors are occurring, the process will be aborted, and an error report sent out to the configured mail address. The error report specifies the exact lines, where errors are found.

3. If the import files have passed the prechecks and the preprocessing, the described tasks are done:

   1. Syncing PGP keys (if PGP states are included)

      1. if a key is wanted, but not there, then the key will be created.

      2. if no key is wanted, but there is one present, it will be deleted.

      3. if no delta is there between the target state and the current state, nothing will be done.

   2. Syncing S/MIME keys (if S/MIME states are included)

      1. if a key is wanted, but not there, then the key and the certificate will be created.

      2. if no key and certificate is wanted, but there is one present, the certificate will be revoked.

      3. if no delta is there between the target state and the current state, nothing will be
         done.

      4. If certificates are created, they will be zipped and attached to a special S/MIME transaction mail, which is sent to the customer-configured mail address, including a list of their serial numbers and other entities.

   3. Syncing groups

      1. Group states have to be ‘full state’, that means - the mentioned group will only contain listed entries after the sync. If ‘example_group’ is listed in the USE import file with ‘alice@example.org’ and ‘bob@example.org’ then the result is that ‘example_group’ contains these two entries after the sync.

   4. Syncing ruleset

      1. The ruleset could be configured in a separate file (see Nr. 13) using USE rule notation and also uploaded to the Retarus SFTP share.

4. After the sync is done, the report is created and sent out to the customers configured mail address. The uploaded import files are also attached to the report mail. If configured, the resulting (report and maybe created certificates) files are uploaded to the SFTP share in the ‘return’ directory to get picked up by the customer. If the customer is not deleting them after picking them up, they will be deleted after 30 days.

Full automation: All modules + SwissSign + WatchDog

• The users should be synced in 12 predefined groups.

• 500 users should have a SwissSign certificate.

• A security mechanism should avoid that more than 1000 S/MIME certificates are live.

  • Joiners and leavers should be synced. Partial Sync means: if a new key is needed, the keystate will be transmitted one time.

• During the sync, the key is created and the keystate saved in the swisssign-users config, so that the WatchDog can renew it in his running cycles, if the certificate expires in default time of 48h. The entry in the swisssign-users config will be removed by the customer via keystate if the certificate is not needed anymore.

• After the certificate creation part of the sync, a report about the created keys is sent to the configured email address. This report contains the serial numbers of the created SwissSign certificates and attaches the certificates in a zip file.

• All SwissSign keys, that are created within the USE syncs, are stored in an archive.

• 100 users have PGP keys, which are synced. The keys have various key lengths and validity time. The default is set to 4096bit / 1 year.

• A rule sync applies rules on the groups, single domains or single email addresses. The rules are delivered in separate ruleimport files and are stated in USE Rule declaration notation.

  • The current live rule set shall be represented in the report email.

Automation with included manual checks: S/MIME + WatchDog + Semi-automatic mode

• 500 users are supposed to have an S/MIME (SwissSign) certificate. The target states are transmitted every day, as a dump of the AD/LDAP system (full sync).

• During the sync, the keys, which are not present or are expiring within the configured buffer time, will be created and the key state saved in the SwissSign users config, so the WatchDog can 'renew' it in his running cycles if the certificate expires within the configured buffer time.
  The entry in the SwissSign users config will be removed by the customer via key state if the
  certificate is not needed anymore.

• For compliance reasons, full automation shall be avoided, so the SwissSign certificates are not created during the sync. Instead of creation, a CSV import file will be created and sent to the configured email address. The administrator (on customers end) checks the file and forwards it via email to Retarus support.

  • This causes a (chargeable) support ticket.

  • The CSV file will be imported manually by Retarus and batch-processed.

• The WatchDog also sends out this CSV import file instead of directly creating the certificates.

External source for S/MIME certificates and import for Retarus Email Encryption

• The keys/certificates are created/bought separately by the customer and shall be used by Retarus, so they must be imported via USE sync.

• Therefore, the keys are uploaded to the SFTP share in a configured sub-directory.

• A default passphrase is configured this passphrase will be used first in every cycle.

• A list of passphrases is filled via sync. Every key could have its own import passphrase. The passphrase will be tried out, iterating over the list.

Automated synchronization of groups, but manual user management

• Encryption users shall be synchronized in 12 predefined groups.

• Certificate creations, imports and rule adjustments are done via (chargeable) support ticket.

S/MIME + SFTP Pushback

• Full sync means the following: if a key is needed, the keystate will be transmitted every time. If not, the state (keystate=0) is also transmitted.

• If a synchronized key is not present or expiries within the configurated buffer time, it will be renewed (created).

• After the certificate creation part of the sync, a report about the created keys is sent to the configured email address.

  • The report contains the serial numbers of the created S/MIME (SwissSign) certificates
    and attaches the certificates in a zip file.

  • In addition, the report and zip file are stored on the SFTP share in the pushback directory.

• All SwissSign keys created within the USE sync runs are stored in an archive.

Automated S/MIME certificate renewal only: WatchDog “stand-alone”

• A full USE stack is not wanted.

• To avoid manual efforts in certificate creation and delays in the supply chain, the WatchDog is set up to run every day.

• The SwissSign users config could be administrated via (chargeable) ticket.

• If a new key pair and certificate shall be created, the dataset must be inserted into the SwissSign users config and the WatchDog will create it in his next cycle (if unchained mode is configured). This could also be processed in semi-automatic mode.

Import files

Specification of import files

The uploaded import file has to be named with the suffix .useimport.

Example
12345TE_use_import_2022-06-01_1600.useimport

The file name should be unique for every import.

The import file will be deleted from the SFTP host after processing.

For personal SwissSign Certificates the primary name (e.g., John) has to be transmitted in a separate value than the last name (e.g., Doe). This can be seen in the sample below.

The contained data of the import file must be structured as follows:
identifier:emailaddress;sub-identifier-01:value;sub-identifier-02:value;subidentifier-
0n:value;sub-identifier-0n:value

Identifiers

Identifier - example use

Example - import file

Ruleimport file

The rules anatomy is splitted into multiple parts. The single fields are separated by semicolon. The 1st field contains the ‘from’ information and the 2nd field the ‘to’ information. This could be an exact senders/recipients address or a group. All further fields contain the options that could be used.

Example of a .ruleimport file

Upload of the import files

The UTF-8 encoded import files have to be uploaded to the SFTP server 94.199.89.100 using your given
credentials into the use directory.