Possible explanation text for the user regarding the background of the question (probably to long):

Answering "Yes" means that you are the only owner of this key, it sets the trust in it's certifications and its validity to "ultimate".
"No" means that other people have access to this key, it sets the trust in it's certifications to "unknown". To use the key, certify it with your own key an thereby set the validity to "full".

Shorter version:

"Yes" means that you are the only owner of this secret key.
"No" means that other people have access to this secret key. To use it, certify it with your own.

Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?

In T7502#198141, @ebo wrote:

Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?

I guess the import of a (subkey) will be an update of the already existing certificate. I'm not sure if we bother the users with questions when a certificate was updated or if we only ask them questions when a new certificate was imported.

Background of my "reminder" comment: we were discussing to establish a sane workflow for sharing keys. Which is quite commonly done e.g. for functional mail addresses, but usually people seem to share the whole secret key which is not advisable. We would want people to only share subkeys for that purpose.
It was the case that somebody gets a subkey for such an "offline" primary for the first time which I was thinking of.

And yes, we should only ask questions for new primary keys, be they on- or offline keys.

So the better phrasing would probably be: Should the question on importing a certificate be different in case of importing a certificate for an offline primary key including private subkeys?

"Exclusive user" sounds a bit odd and could still be misinterpreted. A native speaker would probably say "Are you the sole user of this secret key?“ or (even better and shorter) "Are you the only user of this secret key?"

German version: "Sind Sie der alleinige Nutzer dieses geheimen Schlüssels?" oder "Sind Sie die einzige Person, die diesen geheimen Schlüssel nutzt?"

HTH :)

Also, we should not forget the context of the whole dialog in the window. So we get the wording right, especially regarding key / certificate.

Current status of deliberations (the numbers are for reference only):

1. You have imported a certificate with fingerprint XXX and user IDs ABC.
2. Are you the only user of its secret key?
3. If this secret key is shared with somebody, you should certify it with your own key.
4. Yes / No

1. needs a singular/plural differentiation, its currently always plural.
2. The explanation should maybe better be left out, as it probably makes the meaning of Yes/No unclear. In that case the following certifications window might be a surprise.
3. is one button less than currently, as the "cancel" button does not make sense IMHO. Ok, it could do the same as No but without bringing up a follow up certification window…

Here are some ideas:

1. I agree, the software needs to distinguish between singular and plural. :) Here are some ideas for the dialog:

Singular:

You have imported a certificate with fingerprint XXX and User ID ABC.
A certificate with fingerprint XXX and User ID ABC has been imported.
Successfully imported certificate: Fingerprint XXX, User ID ABC.

Plural:

You have imported multiple certificates with fingerprints XXX and User IDs ABC.
Certificates with fingerprints XXX and User IDs ABC have been imported.
Successfully imported certificates: Fingerprints XXX, User IDs ABC.

Unless we have to start with "You have...", the "Successfully imported" phrasing is nice, because it avoids subject-verb agreement issues and it keeps the structure the same for both cases, making localization and UI implementation easier. Also, it's short and direct (in case space is limited). Many other applications use this style for notifications and status messages, e.g. "Download complete", "Update installed", etc.

2. please note that it should be "this secret key", not "its".

If the explanation in the dialog makes the Yes/No choices unclear, it might be better to leave it out or refine the wording to be more explicit. Maybe we can improve clarity:

Option 1: Keep the question, clarify the buttons:

Question:
"Are you the only user of this secret key?"

Buttons:

Yes, I am the only owner
No, others also use this key

This way, users don't have to guess what "Yes" or "No" actually mean.

Option 2: add a short in-dialog explanation:

Question:
"Are you the only person who uses this secret key?"

Explanation (small text below the question):
"If others also use this key, you need to certify it with your own key."

Buttons:

Yes
No

3. I agree, the "Cancel" button may be redundant because it doesn’t offer a meaningful alternative to "No." If the user selects "No," the system already prompts him/her to certify the key, which is the expected next step. If "Cancel" does the same as "No" but just skips the follow-up window, it might be unnecessary.

Singular:

You have imported a certificate with secret key. 
Fingerprint: XXX
User ID: ABC

Are you the only user of this secret key?

Yes, I am the only user / No, others also use this key

Plural:

You have imported a certificate with secret key. 
Fingerprint: XXX
User IDs:  
             * ABC
             * DEF

Are you the only user of this secret key?
Yes, I am the only user / No, others also use this key

You have imported a certificate with secret key.

-> with a secret key

Is this wording / layout okay?

I have added additional vertical spacing where I think it improves readability.

I have not removed the Cancel button because you will be asked this question multiple times if you import a bunch of secret keys. The Cancel button is the way to stop the series of questions.

The text is exactly as discussed and I'm OK with the layout, too.

If the user clicks the "No, others also use this key" button they get the following dialog

I'm open for suggestions to improve the text.

The texts are based on the suggestion above and on the texts that are shown by the dialog that's shown if a single public OpenPGP key is imported. For comparison:

How about changing the text after sentence two simply to:

In order to use this shared secret key it needs to be certified.

Certification means that you have checked the fingerprint against a trusted source.

or

Before certification you need to check its fingerprint against a trusted source.

One could possibly add something like:

If it exists, check your internal secure operations manual for more information.

But I would prefer the first sentence only, to keep it short. We can hardly cover all possibilities how one could do that…

I'm okay with omitting the list of suggestions for shared secret keys. The person distributing the key should have told the recipients how to import and certify them properly.

So with the above suggestions the full text would be

You have imported a shared secret key.

In order to use this shared secret key you should certify it. Certification means that you check the fingerprint against a trusted source.

Do you wish to start this process now?

Note that I have changed "have checked the fingerprint" back to "check the fingerprint". For me checking the fingerprint is an essential part of the certification and not something you have done some time before the certification. And I don't want to deviate too much from the text that we use when importing normal public keys (except for good reasons like avoiding passive forms).

How about "Certification includes that you check the fingerprint against a trusted source."? "Means" seems wrong to me. @hej, please comment

I tend to agree with keeping it short and close to the wording we use for normal public key imports.

For me, "Certification means that you check the fingerprint against a trusted source." reads clearer than "includes". "Includes" sounds a bit optional, while checking the fingerprint is really the core of what certification is about.

I also wouldn't move the fingerprint check to a separate "before certification" step. In practice, checking the fingerprint is an essential part of the certification process itself, so keeping it together feels more accurate and consistent with the other dialog.

And I’m fine with omitting the list of suggestions here. If a shared secret key is distributed properly, recipients should already know how they are expected to verify it.

So the proposed shorter version works well for me.

So ok, go ahead Ingo with your plan in https://dev.gnupg.org/T7502#213972

with Gpg4win-5.0.2-beta2:

The new texts for the import secret key dialog are OK.

But the certification dialog which should open after choosing "No" is missing. I only get the "detailed import" info window. Maybe the relevant commits are not in the build? But the commit-id listed for Kleo in versioninfo.txt is 782c464a9801d6189e3d3be494922f42857bd26c from yesterday, so it everything should be there…

Debugview shows:

1	0.000000	1712	kleopatra.exe	org.kde.pim.kleopatra: handleOwnerTrust Skipping non-OpenPGP import
2	0.000917	1712	kleopatra.exe	org.kde.pim.kleopatra: getSingleOpenPGPImport returns null because no import result is import of a single OpenPGP key

So it seems Kleopatra wrongly assumes a multiple key import.

The case above shows the case where the public key for the imported secret key was in the keyring beforehand.
We'll assume that this is something which would probably not occur in real life and don't explicitly handle this.

Other cases:

1. Import regular keypair (with primary)
   • Mark-own-certificate window comes up (Yes/No)
   • Detailed results of importing […] (OK, ListImported, AuditLog)

2. Import team key without group flag (= no primary key)
   • Mark Own Certificate -> No, others also use this key
   • Certify new certificate? (You have imported an new certificate (public key)) -> Certify
   • regular Certify Certificate dialog

2b) Import team key without group flag - Without deleting the trustdb between tests

• Mark Own Certificate -> No, others also use this key
• Detailed results of importing […] (OK, ListImported, AuditLog)

3. Import team key without group flag
   • Mark Own Certificate -> Yes
   • Certify new certificate? (You have imported an new certificate (public key)) -> Certify
   • regular Certify Certificate dialog

3b) Import team key without group flag - Without deleting the trustdb between tests

• Mark Own Certificate -> Yes
• Detailed results of importing […] (OK, ListImported, AuditLog)

4. Import team key with group flag
   • Certify shared secret key? -> Cancel

5. Import team key with group flag
   • Certify shared secret key? -> Yes
   • regular Certify Certificate dialog

Q1: Does showing the "Detailed results of importing" make sense for the above cases? One could argue that we could remove it for all single imports where any dialog is shown.

Q2: For 2 and 3 "Certify new certificate? You have imported an new certificate (public key) […]" is not strictly correct, this could be confusing. Maybe we could use the "Certify shared secret key?" instead and change it a bit to make it fit this case too? How about starting with:
"You have imported a shared secret key / a key without primary part." And then leave out the "shared" in the second sentence and in the window title.

Q3: Would you make the text in "Certify shared secret key?" wrap?

this comment was intended for T7581, moved it to there.

In T7502#214891, @ebo wrote:

Q1: Does showing the "Detailed results of importing" make sense for the above cases? One could argue that we could remove it for all single imports where any dialog is shown.

I was wondering about the opposite and have changed it locally already to show the detailed results at least if one doesn't click Certify. I'm undecided.

In T7502#214891, @ebo wrote:

Q2: For 2 and 3 "Certify new certificate? You have imported an new certificate (public key) […]" is not strictly correct, this could be confusing. Maybe we could use the "Certify shared secret key?" instead and change it a bit to make it fit this case too? How about starting with:
"You have imported a shared secret key / a key without primary part." And then leave out the "shared" in the second sentence and in the window title.

Ah, I understand. Because the user clicked "No, others also use this key" we know that it's a shared key. I guess we could improve this, but please in a separate ticket with a mock-up of your suggestions for the text. Please think about the translators ;-) and don't add loads of texts with small variations. I would prefer to keep one text for normal keys and one for team keys.

In T7502#214891, @ebo wrote:

Q3: Would you make the text in "Certify shared secret key?" wrap?

No. I've looked at it but it's impossible without adding hard-coded line breaks (as done in the text for public keys) which make the text look really bad if for a translation the second line is longer than the first one. I've explicitly refrained from adding hard-coded line breaks. The message box windows enable word wrapping when the window gets wider than 50 % of the screen width. In our case the window takes a bit less than 50 % of the screen width.

We could try to get an option into KMessageBox to enable word wrapping.

I've created the ticket above for Q2, we need to discuss how to follow up Q1 and Q3 next week.