Bugzilla

The initial public key trust management from bug 1626683 requires an explicit opt in, before a key is used for sending encrypted email.

Magnus is worried this might be too complicated for most people, and suggests that we should automatically trust it. Could we improve that?

If Alice sees a public key for Bob's email address for the very first time (Alice has never before seen any other public key for Bob's address), then we could accept it automatically as "unverified", without explicit opt-in.

If we did (and assuming our default configuration allows to encrypt using unverified keys), then Alice could immediately send encrypted email to Bob, without confirming/accepting Bob's key.

This has another consequence, though.

If receiving a signed email from Bob is the first event in which we learn about Bob's (allegedly owned) key, we'd also have to treat it as "unverified".

The received signed message would then be shown as "good signature from unverified identity". (In contrast, with the initial work from bug 1626683, we'd treat the key as "undecided" and the signed message would be shown with "questionable signature".)

Do we think that's reasonable?

I'd personally prefer to treat it as "undecided". Only if the user clicks the signature, sees the undecided status, and the user deliberately changes it to "yes, accepted (unverified)".

I suggest that we postpone the decision, and try to collect more arguments for one or the other default behavior.

The initial public key trust management from bug 1626683 requires an explicit opt in, before a key is used for sending encrypted email.

Magnus is worried this might be too complicated for most people, and suggests that we should automatically accept it. Could we improve that?

If Alice sees a public key for Bob's email address for the very first time (Alice has never before seen any other public key for Bob's address), then we could accept it automatically as "unverified", without explicit opt-in.

If we did (and assuming our default configuration allows to encrypt using unverified keys), then Alice could immediately send encrypted email to Bob, without confirming/accepting Bob's key.

This has another consequence, though.

If receiving a signed email from Bob is the first event in which we learn about Bob's (allegedly owned) key, we'd also have to treat it as "unverified".

The received signed message would then be shown as "good signature from unverified identity". (In contrast, with the initial work from bug 1626683, we'd treat the key as "undecided" and the signed message would be shown with "questionable signature".)

Do we think that's reasonable?

I'd personally prefer to treat it as "undecided". Only if the user clicks the signature, sees the undecided status, and the user deliberately changes it to "yes, accepted (unverified)".

I suggest that we postpone the decision, and try to collect more arguments for one or the other default behavior.

The initial public key trust management from bug 1626683 requires an explicit opt in, before a key is used for sending encrypted email.

Magnus is worried this might be too complicated for most people, and suggests that we should automatically accept it. Could we improve that?
[edit: changed "automatically trust" to "automatically accept"]

If Alice sees a public key for Bob's email address for the very first time (Alice has never before seen any other public key for Bob's address), then we could accept it automatically as "unverified", without explicit opt-in.

If we did (and assuming our default configuration allows to encrypt using unverified keys), then Alice could immediately send encrypted email to Bob, without confirming/accepting Bob's key.

This has another consequence, though.

If receiving a signed email from Bob is the first event in which we learn about Bob's (allegedly owned) key, we'd also have to treat it as "unverified".

The received signed message would then be shown as "good signature from unverified identity". (In contrast, with the initial work from bug 1626683, we'd treat the key as "undecided" and the signed message would be shown with "questionable signature".)

Do we think that's reasonable?

I'd personally prefer to treat it as "undecided". Only if the user clicks the signature, sees the undecided status, and the user deliberately changes it to "yes, accepted (unverified)".

I suggest that we postpone the decision, and try to collect more arguments for one or the other default behavior.

The initial public key trust management from bug 1626683 requires an explicit opt in, before a key is used for sending encrypted email.

Magnus is worried this might be too complicated for most people, and suggests that we should automatically accept it. Could we improve that?
[edit: changed "automatically trust" to "automatically accept"]

If Alice sees a public key for Bob's email address for the very first time (Alice has never before seen any other public key for Bob's address), then we could accept it automatically as "unverified", without explicit opt-in.

If we did (and assuming our default configuration allows to encrypt using unverified keys), then Alice could immediately send encrypted email to Bob, without confirming/accepting Bob's key.

This has another consequence, though.

If receiving a signed email from Bob is the first event in which we learn about Bob's (allegedly owned) key, we'd also have to treat it as "unverified".

The received signed message would then be shown as "good signature from unverified identity". (In contrast, with the initial work from bug 1626683, we'd treat the key as "undecided" and the signed message would be shown with "questionable signature".)

Do we think that's reasonable?

I'd personally prefer to treat it as "undecided". The user could click the signature, sees the undecided status, and be required to deliberately change it to "yes, accepted (unverified)", to use the key.

I suggest that we postpone the decision, and try to collect more arguments for one or the other default behavior.