An new suggestion for the wording without prior reading of the above texts to get a fresh view.
But in German ...

Die Struktur der Punkte unten ist wie folgt:

• Erster Punkt, ist eine direkte Antwort, die auch eine nicht fachlich versierte Person versteht.
  • Folgende Punkte sind für ein Tooltip. Zuerst ein weitere erklärender Text.
  • Danach dann Hinweise wie man mit dem Problem umgeht. (der Text "Was kann man tun" kann auch raus.)

Signaturprüfung

Ergebnisvarianten:

Zertifikat zur Signatur nicht vorhanden

• Die Signatur kann nicht geprüft werden, da das zugehörige Zertifikat nicht vorhanden ist. Den Daten kann nicht vertraut werden.
  • Das zum Prüfen der Daten notwendige Zertifikat des Absenders ist nicht in Ihrer Zertifikatsliste vorhanden.
  • Was kann man tun: Sie können den Absender bitten Ihnen das Zertifikat zukommen zu lassen; Gleichen Sie den Fingerabdruck des Zertifikats mit dem Absender ab und beglaubigen Sie das Zertifikat. Prüfen Sie danach die Daten+Signatur erneut.

Zertifikat ist vorhanden, aber ...

die Signatur passt nicht

• Daten und Signatur passen nicht zusammen. Den Daten kann nicht vertraut werden.
  • Die Daten oder die Signatur sind verändert worden. Dies kann zufällig (z.B. durch einen Übertragungsfehler) oder unabsichtlich (z.B. durch eine nachträgliche Änderung der Daten, evtl. auch durch einen Mail-Client) oder absichtlich (bewusste Manipulation) passieren.
  • Was kann man tun: Lassen Sie sich die Daten noch einmal zusenden.

dem Signaturzertifikat wird nicht vertraut

• Es kann nicht sichergestellt werden ob die Daten wirklich von dem Absender stammen, da dem Zertifikat mit dem die Daten signiert wurden nicht vertraut wird.
  • Da dem Zertifikat des Signierenden nicht vertraut wird, kann auch den Daten nicht vertraut werden. Technisch passen Signatur und Daten aber zusammen.
  • Was kann man tun: Vergleichen Sie den Fingerabdruck mit dem Sender und beglaubigen Sie das Zertifikat. Prüfen Sie danach die Daten+Signatur erneut.

die Signatur ist nicht VS konform

• Die Signatur wurde nicht VS konform erstellt. Damit dürfen keine Verschlusssachen signiert werden, es ist für nicht VS-konforme Nutzung aber in Ordnung.
  • Was kann man tun: Für eine VS konforme Kommunikation bitten Sie den Absender ein VS-konformes Zertifikat zu erstellen und ihnen zukommen zu lassen.

das Signaturzertifikat wurde zurückgerufen

• Es kann nicht sichergestellt werden ob die Daten wirklich von dem Absender stammen, da das Zertifikat zurückgerufen wurde.
  • Das Zertifikat könnte zurückgerufen worden sein, weil es kompromittiert wurde und ein Dritter dies nun nutzt. Den Daten kann daher nicht vertraut werden. Technisch passen Signatur und Daten aber zusammen.
  • Was kann man tun: Es könnte sein, dass Sie Daten zu einem Zeitpunkt bekommen haben, zu dem das Zertifikat noch gültig war. Wenn das sichergestellt ist können die Daten in Ordnung sein. Im Zweifelsfall kontaktieren Sie den Sender um die Situation zu klären und sich evtl. die Daten erneut, mit einem aktuellen Zertifikat signiert, zusenden zu lassen.

das Signaturzertifikat ist abgelaufen

• Den Daten kann nicht vertraut werden, da die Gültigkeit des Zertifikats abgelaufen ist.
  • Eventuell hat jemand Drittes Kontrolle über das Zertifikat und versendet gefälschte Daten.
  • Was kann man tun: Es könnte sein, dass Sie Daten zu einem Zeitpunkt bekommen haben, zu dem das Zertifikat noch OK war. Wenn das sichergestellt ist können die Daten in Ordnung sein. Kontaktieren Sie den Sender und bitten um ein aktuelles, verlängertes Zertifikat von ihm; damit können die Daten erneut prüfen. Sollte der Sender ein neues Zertifikat haben bitten Sie ihn die Daten damit signiert erneut zukommen zu lassen. Vergleichen Sie den Fingerabdruck des neuen Zertifikats mit dem Sender und beglaubigen Sie das Zertifikat. Nun können sie die Daten erneut prüfen.

Das Zertifikat ist in Ordnung und die Signaturprüfung erfolgreich

• Die Signaturprüfung ist erfolgreich.
  • Daten und Signatur passen zusammen und wurden erfolgreich geprüft.
  • Was kann man tun: Kontrollieren sie regelmäßig ob das Zertifikat des Senders noch aktuell ist um ein hohes Sicherheitsniveau aufrecht zu erhalten.

Ok, new try on the basis of Alexanders suggestion:

Note that here we do no longer use the gpg/gpgsm error messages in the texts, but we still link to the audit log which contains them.

The parts shown as list items are from the info/help which should be accessible via a button.
The button should be after the first sentence / part.

V-SUMMARY (!= summary now) it is meant to be: User-ID + creation date (with link to cert details)

Caevat: I did not include expiration of the signature (as opposed to expiration of the signature key), compare T8035.

Certificate for the signature is not available

The signature cannot be verified because the corresponding certificate is not available. The data cannot be trusted. [The signing certificate’s fingerprint is %1. | The signing certificate’s issuer is %1, the S/N is %2.]

• The signing certificate is not present in your certificate list, but it is needed to verify the data.
• What can be done: Ask the sender for the certificate or import it from a file or a keyserver. After import, verify the certificate’s fingerprint and then [certify it | trust its root certificate]. Then verify the data again.

Certificate is available, but ...

The signature does not match (“Bad signature”)

Data and signature do not match. The data cannot be trusted.
Signed by V-SUMMARY on %date+time.

• The data or the signature has been altered. This can happen accidentally (e.g. due to a transmission error), unintentionally (e.g. due to a subsequent change to the data, possibly by an email client), or intentionally (deliberate manipulation).
• What can be done: Ask the sender to resend the data.

The signature certificate has been revoked

It cannot be verified whether the data truly originates from the sender, as the signing certificate has been revoked.
Signed by V-SUMMARY on %date+time.

• The certificate may have been revoked because it was compromised and is now being used by a third party. The data can therefore not be trusted. Technically, signature and data match.
  1. case trusted:
• What can be done: It is possible that you received the data at a time when the certificate was still valid. If this is the case, the data may be valid. If in doubt, contact the signer to clarify the situation and, if necessary, ask them to resend the data with a current certificate.
  1. case not trusted:
• What can be done: Ask the sender to resend the data signed with a current certificate.

The signature certificate has expired

The data cannot be trusted because the signing certificate has expired.
Signed by V-SUMMARY on %date+time.

• It is possible that a third party has gained control of the certificate and is sending forged data.
• What can be done: If you received the data at a time when the certificate was still valid, the data may be ok. Contact the sender and ask them to provide the current, renewed certificate; then verify the data again. If the sender has a new certificate, ask them to send it and the data signed with this new certificate.

Anmerkung: Der Teil mit "Contract the sender" gefällt mir noch nicht.

The signing certificate is not trusted

It cannot be verified whether the data originates from the stated source, as the signing certificate is not trusted.
Signed by V-SUMMARY on %date+time.

• Since the signing certificate is not marked as verified, the data cannot be trusted to originate from the right source, either. Technically, signature and data match.
• What can be done: Verify the certificate’s [fingerprint and certify it | Root-CA fingerprint and trust it]. Then verify the data again.

The certificate is valid and the signature verification was successful

Signature verification was successful.
Signed by V-SUMMARY on %date+time.

• Data and signature match and have been verified.

Addition to all variants (with exception “no certificate”)

"The signature is %1" can expand to:
The signature is not VS-NfD compliant / NATO restricted compliant

The signature was not created in a VS-NfD compliant manner. It must not be used to sign classified information, but it is acceptable for non-classified use.
What can be done: For classified communication, ask the signer for a VS-NfD compliant certificate and that they use it for signing in the future.

The signature is VS-NfD compliant - Would need an other tooltip…

As %1 can contain “not”, different tooltips are difficult…
Maybe instead always the same text:

If the signature is not shown as VS-NfD compliant, it must not be used to sign classified information, but it is acceptable for non-classified use.
What can be done: For classified communication, ask the signer for a VS-NfD compliant certificate and that they use it for signing.

Some minor language suggestions for the texts in the comment above:

In T7786#218200, @ebo wrote:

• What can be done: Ask the sender for the certificate or import it from a file or a keyserver. After import, verify the certificate’s fingerprint and then [certify it | trust it’s root certificate]. Then verify the data again.

Typo: "it's" -> "its"

What can be done: Have the data sent to you again.

Suggestion: "Ask the sender to resend the data."

It cannot be verified if the data truly originates from the sender, as the signing certificate has been revoked.

"if" -> "whether" (more natural in indirect questions; same applies below)

It cannot be verified if the data originates from the apparent source, as the signing certificate is not trusted.

"if" -> "whether"

Contact the sender and ask them to provide the current, extended certificate; then verify the data again.

"extended" -> "renewed" (certificates are reissued, not extended); or: "a new, valid certificate"

For classified communication, ask the signer for a VS-NfD compliant certificate and data signed with it.

Suggestion: "For classified communication, ask the signer to resend the data signed with a VS-NfD compliant certificate." (applies to both occurrences)

Data and signature match and have been successfully verified.

"successfully verified" is redundant. Suggestion: "Data and signature match and have been verified."

Feel free to ignore any of the comments, these are just small things I noticed while reading through.

Thank you, I have adopted your suggestions in most places and edited my comment above accordingly.

In reaction to a comment by @timegrid I also changed one occurrence of "It is possible that" to avoid repetitive wording.

He had some more comments which I paste here, as I can't incorporate them right now / they may need discussion:

Don't we have the reason on hand for revoked certificates? Wouldn't it be helpful to display that?

I think showing the reason was only recently implemented on the gpg side and only in gnupg26: T7083: Show revocation reasons also with a standard -k listing

Why is there no “signed by” info for bad signatures?

I'd like to discuss how we can word it there, simply writing "Signed by" is not really correct, as we can not be sure in this case afaiu.

Expired: Would it be helpful to display the expiration date? It makes a difference whether it expired yesterday or years ago

I'm not sure if this is easily possible. @ikloecker?

not trusted: originates from the apparent source,

• “apparent” has a rather critical connotation for me—“seemingly/allegedly”
• I would find something like “from the stated/specified/provided source” more neutral

I do not agree on that, but "apparent" might not be ideal for a non-native speaker audience.

[...]

not trusted: originates from the apparent source,

• “apparent” has a rather critical connotation for me—“seemingly/allegedly”
• I would find something like “from the stated/specified/provided source” more neutral

I do not agree on that, but "apparent" might not be ideal for a non-native speaker audience.

I agree "apparent" is not ideal. It can read as skeptical or accusatory, especially for non-native speakers. "Stated source" would be more neutral and unambiguous.

ok, changed to "stated source" above.

Since the signing certificate is not marked as verified, the data cannot be trusted to originate from the right source, either. Technically, signature and data match.

I found this hard to read. Suggestion: "Technically, signature and data match, but the signing certificate is not marked as verified. The data cannot be trusted to originate from the stated source."

Bad signature:
I think it may still be useful to show the apparent cert/fingerprint, even if that should be worded carefully. Suggestion: "The signature claims to have been made by V-SUMMARY".

I have changed the places where tfry made suggestions and made some additional changes and pasted this into the description. There still need to be made some more changes.

• Certificate not available:
  • "What can be done:" suggest removing the sentence about verifying the (root) certificate. Users will be prompted for that on import, or when re-verifying the signature, anyway.
  • *Alternatively* suggest rewording case SMIME: "Ask the sender for the certificate or import it from a file or a keyserver. If the corresponding root certificate is not yet known, verify and trust it. Then verify the data again."

• Certificate expired:
  • suggest splitting "What can be done:" into two distinct wordings:
    • SMIME: "It is possible that you received the data at a time when the certificate was still valid. If this is the case, the data may be valid. If in doubt, contact the signer to clarify the situation and, if necessary, ask them to resend the data with a current certificate." (same wording as for revoked)
    • *PGP is logically two possible conditions (update available/expired for good), I suggest reordering those for clarity: "It is possible that the signer has extended their certificate. You might search for an update of the certificate on a keyserver or ask the sender to provide the renewed certificate, then verify the data again. If the certificate has not been renewed, but you received the data at a time when it was still valid, the data may be ok. If in doubt, contact the signer to clarify the situation and, if necessary, ask them to resend the data with a current certificate."

Good plan, the reordering of the PGP case makes the logic much clearer.

A few suggestions on the wording:

[...]

If the corresponding root certificate is not yet known...

"not yet known" is a bit awkward. Suggestion: "If the corresponding root certificate is not trusted yet, verify and trust it."

You might search for an update of the certificate...

"You might" is too tentative for an action suggestion. Suggestion: "You can search for an updated certificate on a keyserver, or ask the sender to provide the renewed certificate. Then verify the data again."

• Certificate expired:

[...]

"It is possible that the signer has extended their certificate. You might search for an update of the certificate on a keyserver or ask the sender to provide the renewed certificate, then verify the data again. If the certificate has not been renewed, but you received the data at a time when it was still valid, the data may be ok. If in doubt, contact the signer to clarify the situation and, if necessary, ask them to resend the data with a current certificate."

I think, "the data may be ok" is too informal for UI text. Suggestion: "the data may still be valid."
Also, the sentence is easier to read when split: "If the certificate has not been renewed and you received the data while it was still valid, the data may still be valid."

sorry, I already incooperated tfry's comment into the text in the description field and changed it in the process. And I kept "ok" because otherwise it would have been "valid" twice, which felt worse for me. See the description.

I think the case "The signature certificate has been revoked" should also use

The signature claims to be from V-SUMMARY and dated %date+time.

The case "The signature certificate has been revoked + in case trusted" doesn't exist. In my test verifying a good signature with a revoked certificate that was fully trusted before the revocation gpg prints

gpg: Signature made Mi 07 Jan 2026 11:27:24 CET
gpg:                using EDDSA key BD05F2F741051D331567C2617967963A07F223E4
gpg: Good signature from "t7790-revoked-with-trust-signature" [unknown]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: No reason specified
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

Exactly the same messages are printed if the certificate wasn't fully trusted before the revocation.

We have

Data and signature do not match. The data cannot be trusted.

It cannot be verified whether the data truly originates from the sender, as the signing certificate has been revoked.

The data cannot be trusted because the signing certificate has expired.

It cannot be verified whether the data originates from the stated source, as the signing certificate is not trusted.

I think the first and the third message should be unified, i.e. either

The data cannot be trusted because REASON

or

REASON. The data cannot be trusted.

The first variant has the advantage that it puts the focus on the (non-)trust before explaining why. The second variant has the advantage that it has two separate sentences/statements which is easier to understand ("Einfache Sprache").

In fact, I think all four messages should be unified. In all four cases the data cannot be trusted. In the latter three cases the data cannot be trusted because "the signing certificate has been revoked / has expired / is not trusted". Different reasons but (I think) identical assessment. I also think that the second and fourth message is way to complicated with two subclauses.

I'm torn between the format of the first message and that of the third message. I like the third message because the "because" clearly communicates the reason. I like the first message because of it's simplicity but maybe for some people it's not clear that the second statement follows from the first statement. And the important part of the message "cannot be trusted" is at the end of the message.

I don't think we can get away with something like

The data cannot be trusted. Data and signature do not match.

Maybe

The data cannot be trusted. Reason: Data and signature do not match.

Yes. The "Reason:" is a bit ugly, but it avoids a subclause and might therefore be easier to digest.

In the case "The certificate is valid and the signature verification was successful" the proposal

Signature verification was successful.

is a bit weak for my taste because technically the "signature verification" is always "successful" unless the signature is bad or unless it cannot be verified (e.g. because the signing certificate is not available). I'm missing a statement about the validity/trustworthiness of the signing certificate. And I'm wondering if we want a clear statement like "The data can be trusted." or if we want to avoid such a statement for liability reasons.

Great feedback! Regarding the "claims to be" I could imagine using that for signatures by revoked keys too, but then additionally expired ones should to use it also, and the untrusted certificates, too, I guess. And as Werner does not like it, anyway, I'll stay with "Signed by" atm.

In the description of this ticket, I removed the differentiation between trusted and not trusted in the revoked case and merged the info message.

For the primary messages I went for the "The data cannot be trusted. Reason: …" phrasing.
I made some changes to the info texts, too.
I do not really like the info for expired "It is possible that a third party has gained control of the certificate." because I don not think this more likely for an expired than an not expired certificate. And the 3rd party would extend it anyway if they obtained it. Suggestions?

I haven't changed the success message, but I expanded the info text for it. If you have a suggestion *without* saying "The data can be trusted" (which we don't want to do), I'd like to hear it. Maybe "positive" instead of "successful? Or ~"The signature verification has confirmed that the signature is valid."? Or maybe we could add the info text to the regular message in this case?

In T7786#219362, @ebo wrote:

I do not really like the info for expired "It is possible that a third party has gained control of the certificate." because I don not think this more likely for an expired than an not expired certificate. And the 3rd party would extend it anyway if they obtained it. Suggestions?

How about dropping that sentence entirely and replacing it with: "The signing certificate has passed its validity date. The signer may have renewed it or issued a new certificate."

I haven't changed the success message, but I expanded the info text for it. If you have a suggestion *without* saying "The data can be trusted" (which we don't want to do), I'd like to hear it. Maybe "positive" instead of "successful? Or ~"The signature verification has confirmed that the signature is valid."? Or maybe we could add the info text to the regular message in this case?

I'd leave "successful" and keep the info text as is:
"Data and signature match and the certificate is valid and trusted" already says everything without claiming "the data can be trusted." That seems like the right balance.

I do not really like the info for expired "It is possible that a third party has gained control of the certificate." because I don not think this more likely for an expired than an not expired certificate. And the 3rd party would extend it anyway if they obtained it. Suggestions?

Alternative:

• You have no information if the signers certificate is still save to use. The data can therefore not be trusted. Technically, signature and data match.

I haven't changed the success message, but I expanded the info text for it. If you have a suggestion *without* saying "The data can be trusted" (which we don't want to do), I'd like to hear it. Maybe "positive" instead of "successful? Or ~"The signature verification has confirmed that the signature is valid."? Or maybe we could add the info text to the regular message in this case?

I am fine with the current wording. An "positive" alternative could be:

Positive signature verification.
Signed by V-SUMMARY on %date+time.

• Data and signature match and have been successfully verified.
• The signers certificate is valid and trusted.

After some discussion with Alexander and further thoughts I'd like to change the text in the description as follows, if there are no objections.

Info in case expired:

• The signing certificate has expired, preventing verification of whether the certificate—and thus the data—is trustworthy. Technically, signature and data match.

But now this info is missing from the revoked case, so I suggest changing the info message there to:

• The certificate may have been revoked because it was compromised and it might now be used by a third party. Verification of whether the certificate—and thus the data—is trustworthy is therefore not possible. Technically, signature and data match.

And for the success message put everything in the message, no info box:

Signature verification was successful: Data and signature match and the certificate is valid and trusted.

After some feedback, the first expiration info paragraph is now:

For an expired certificate, it cannot be evaluated whether it, and thus the data, can be trusted. Technically, signature and data match.

Another iteration for the expired certificates. The first sentence is simplified and the possible conclusion moved to the first part:

• For an expired certificate, it cannot be evaluated whether the certificate can be trusted. Therefore the data cannot be trusted. Technically, signature and data match. If the certificate was valid and trusted when you received the data, the data is likely still valid.
• What can be done: You can look for an updated certificate on a keyserver, or ask the sender for it, then verify the data again after importing the certificate. If the sender issued an entirely new certificate instead, you might ask them to resend the data signed with the current certificate.

I'll probably remove the last sentence entirely. This is not something you usually do or need to do.