> I need to think about this some. I think you're right, but not for the
> reasons you set out. I think the functional difference comes from what
> a bad signature can tell us about the traffic channel itself -- not what
> it tells us about the traffic.
Throwing this out right now -- let's see just how bad of an idea it is:
We're already thinking about three icons representing PAI, Privacy,
Authenticity and Identity. Well, God loves a good mnemonic, so let's
add one additional letter: R, for Reliability.
My goal here is to avoid the use-case of having to put a red X over the
Authenticity and Identity icons just because a signature doesn't check
out. Doing that is unhelpful and wrong. The vast majority of the time
a bad signature means a transient error that doesn't affect the
semantics of the message, and red Xs over the icons for Authenticity and
Identity give people exactly the wrong message -- it leads people into
panic rather than "huh, that's odd."
So my new proposal: add the letter R. If there's a bad signature, the
Reliability icon indicates that *the message really needs to be
checked*. If the signature is good, the icon indicates all is well.
So. PAIR, not PAI.
The different states would be (with 'C', 'G', and 'X' denoting
full-color, grayed, and Xed):
+---------+-------+----------+------+
| Privacy | Auth. | Identity | Rel. |
+---------+-------+----------+------+
| C | C | C | C | (1)
| C | C | C | G | (2)
| C | C | C | X | (3)
| C | C | G | C | (4)
| C | C | G | G | (2)
| C | C | G | X | (3)
| C | C | X | C | (5)
| C | C | X | G | (2)
| C | C | X | X | (3)
| C | G | C | C | (6)
| C | G | C | G | (2)
| C | G | C | X | (3)
| C | G | G | C | (7)
| C | G | G | G | (2)
| C | G | G | X | (8)
| C | G | X | C | (9)
| C | G | X | G | (2)
| C | G | X | X | (3)
| C | X | C | C | (10)
| C | X | C | X | (10)
| C | X | C | G | (10)
| C | X | G | C | (10)
| C | X | G | G | (10)
| C | X | G | X | (10)
| C | X | X | C | (10)
| C | X | X | G | (10)
| C | X | X | X | (10)
| G | C | C | C | (11)
| G | C | C | G | (2)
| G | C | C | X | (3)
| G | C | G | C | (12)
| G | C | G | G | (2)
| G | C | G | X | (3)
| G | C | X | C | (13)
| G | C | X | G | (2)
| G | C | X | X | (3)
| G | G | C | C | (6)
| G | G | C | G | (2)
| G | G | C | X | (3)
| G | G | G | C | (14)
| G | G | G | G | (2)
| G | G | G | X | (15)
| G | G | X | C | (9)
| G | G | X | G | (2)
| G | G | X | X | (3)
| G | X | C | C | (10)
| G | X | C | X | (10)
| G | X | C | G | (10)
| G | X | G | C | (10)
| G | X | G | G | (10)
| G | X | G | X | (10)
| G | X | X | C | (10)
| G | X | X | G | (10)
| G | X | X | X | (10)
| X | X | X | G | (16)
| X | - | - | - | (17)
(1) This is the gold standard.
(2) This can't happen. Reliability is yes-or-no; there's no gray state.
(3) This can't happen. Reliability X implies Auth/ID G.
(4) Encrypted, good sig, unvalidated certificate
(5) Encrypted, good sig, but comes from someone other than the email
address on the message
(6) This can't happen. Auth G implies Identity G.
(7) Encrypted, no signature, no identity validation, no problems
(8) Encrypted, bad signature, identity can't be validated, problem
(9) This can't happen. No signature means identity can't be tested.
(10) This can't happen. There is no Authenticity X any more. Only C
and G states exist.
(11) Signed by a validated certificate, but no encryption.
(12) Signed by a non-validated certificate, but no encryption
(13) Correct signature from someone other than the sender of the email.
No encryption.
(14) No encryption, no signature. Sent totally plaintext.
(15) Plaintext with a bad signature
(16) Decryption failed. Nothing else could be checked.
(17) No other Privacy X possibilities exist.
Now you guys see why I put my foot down and refused to consider more
than trinary states. :) These state charts get *real* complicated,
*real* fast.
So, the logic goes:
Set P, A, I, R = G, G, G, C
If decryption fails:
Set P to X
Return P, A, I, R. # bail out and stop processing
Else if decryption succeeds:
P gets set to C.
Else: # the message wasn't encrypted
P gets set to G.
If signature is bad:
R gets set to X.
A gets set to G.
I gets set to G.
End processing.
If signature is good:
A gets set to C
If email addr on signing certificate matches sender:
If signing certificate is validated:
Set A, I, R to C, C, C.
Return P, A, I, R.
Else:
Set A, I, R to C, G, C.
Return P, A, I, R.
Else:
Set A, I, R to C, X, C
Return P, A, I, R
Else: # if there's no signature
Set A, I, R to G, G, C
Return P, A, I, R.
... How does this look?
Remember, guys, the more complicated our states become the harder it is
for Patrick and Nico to implement them correctly. For this reason I'm
going to be *really* *really* reluctant to smile on proposals to make
this more complicated. I think this should be the upper limit of our
complexity -- I'd prefer to see less.
_______________________________________________
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
