Title: Allow admin to decide if PGP or S/MIME is to be preferred if both are active.
What is your original issue/pain point you want to solve?
You cannot overcome Zammads default behavior to prefer S/MIME over PGP should both integrations be active. If you e.g. want to be able to receive S/MIME content with the option to verify it, you would have to manually switch to PGP all the time if that’s your preferred way to sign emails.
Which are one or two concrete situations where this problem hurts the most?
Having the agent to remember and actively change to PGP in any single article they send via mail to the customer.
Why is it not solvable with the Zammad standard?
It’s a hardcoded prefered option
if @securityTypeShown()
@$('.js-securityType[data-type="PGP"]').removeClass('btn--active')
@$('.js-securityType[data-type="S/MIME"]').addClass('btn--active') # S/MIME is preferred type
@$('.js-securityType').show()
What is your expectation/what do you want to achieve?
A (maybe group based) option that defaults to S/MIME but allows admins to actually switch it to PGP so that the default favored S/MIME setting can be overruled.
Your Zammad environment:
Average concurrent agent count: 10
Average tickets a day: 50
What roles/people are involved: Agents and Admins
Anything else which you think is useful to understand your use case:
This currently works as designed but in some scenarios you might want to have power over this “external decision”.
Context:
opened 12:09PM - 23 Jun 23 UTC
closed 07:31PM - 25 Jul 23 UTC
enhancement
admin area
integration
frontend
mail processing
pgp
### Summary (What)
Currently, Zammad is not able to use Pretty Good Privacy (PG… P) to sign, encrypt, and decrypt emails.
#### Example Use Cases
A secure company wants to use PGP to communicate with their customers, because of sensitive content.
Also, the usage of S/MIME and PGP together is important for supporting both ways for different outside usage (customers who use S/MIME and some who use PGP).
### Intended Outcome
PGP should be usable in Zammad for signing, encrypting, and decrypting emails.
On the integration page, an administrator can
- see and manage existing keys
- trust/untrust keys
- delete keys
- upload new public and private keys
- change the default behavior of signing and encrypting for groups
- check the logs for the most recent signing, encrypting, and decrypting operations.
In the ticket create/detail view screen, a user can
- select if S/MIME or PGP should be used for signing and encrypting.
- see in the article meta information if S/MIME or PGP is used.
### How it will work
#### PGP Integration
The PGP integration needs to be enabled in `System` > `Integrations`.
An administrator can perform the following operations in the GUI:
- Upload new public keys
- Upload new private keys
- Remove existing keys
In addition to this, the default behavior of signing/encrypting for the existing groups can be specified on a group basis. S/MIME is the more important one, this means if S/MIME and PGP are enabled + usable, we prefer to use S/MIME.
Furthermore, to be able to check if signing/encrypting is working fine or to even debug some issues with signing/encrypting, the recent logs can be used.

#### Ticket Creation/Detail View
The ticket creation and detail view screens are extended to support the PGP integration.
During writing a new email, the well-known `Security` field is shown (if PGP and/or S/MIME are enabled).
This field is displayed as a switch and it can be decided which security method should be used. Furthermore, it is possible to turn off signing/encrypting.

The article information in the ticket detail view screen is enriched with information:
- Used security method
- Encrypted
- Signed
Errors that happened during signing/encrypting are shown there as well.

### Implementation Details
Our PGP implementation is based on [RFC 3156](https://www.rfc-editor.org/rfc/rfc3156).
#### PGP REST API
- During the upload of a key, we are parsing the key information and save it to the database.
- This makes our life easier and removes the need of calling GnuPG every time (performance).
- Information to be saved:
- Fingerprint
- Expiry date
- UIDs (mail addresses)
- Passphrase (for private keys)
- Keys need to be validated during upload.
- Duplicates need to be checked.
- The used domain needs to be checked.
#### In Clarification: Recipient Alias Configuration
- We are going to add a new checkbox to the uploading of private keys to determine if a key is used as a `catch-all` key for the domain specified in the key.
- This checkbox is controlled by a new hidden setting in Zammad (similar to [Thunderbird](https://support.mozilla.org/de/kb/openpgp-recipient-alias-configuration)).
#### Ticket Creation/Detail View
- The switch for S/MIME or PGP in the ticket creation/detail view is only shown if S/MIME **and** PGP are enabled.
- If S/MIME and PGP are not configured, there is no `Security` section shown at all.
- If an administrator does not care about trusted keys, there is a new setting for handling keys as trusted by default.
#### Encrypt/Sign
- Smart checking for the expiry date of a key
- Use case: Key 1 is about to expire in 3 days, a new key is already uploaded
- The mechanism to sign/encrypt should detect which key was uploaded last and use it if the identity (mail address) is the same
#### Documentation
- Public key servers are not supported, please use API to import keys
```[tasklist]
### Tasks
- [ ] https://github.com/zammad/coordination-scrum/issues/60
- [ ] https://github.com/zammad/coordination-scrum/issues/59
- [ ] https://github.com/zammad/coordination-scrum/issues/55
- [ ] https://github.com/zammad/coordination-scrum/issues/56
- [ ] https://github.com/zammad/coordination-scrum/issues/57
- [ ] https://github.com/zammad/coordination-scrum/issues/58
- [ ] https://github.com/zammad/coordination-scrum/issues/61
- [ ] https://github.com/zammad/coordination-scrum/issues/63
```
Thank you and have fun.