[Top] [All Lists]

Re: [ietf-smtp] [pkix] why you shouldn't even try to canonicalize local parts

2016-03-14 08:50:56
I feel like all this discussion is missing the essential issue, i.e.: the CA 
certifies the address (effectively once relative to the # of emails) but it's 
the recipient has to do the match (on every message).  Sender MUA  
configuration, on-demand certificates, etc.--these things don't address the 
real problem.

It also seems clear from this discussion how hard this problem is, because 
local-part usage is locally defined and therefore complex and unknowable.  
We're all just guessing how local-part is used.  Because of this no attempt to 
canonicalize local-part or somehow signal in the certificate how matching is 
done is going to catch all the cases, or be able to mutate fast enough to keep 
up with problems.

It would be simpler, all things considered, to take a page from Johnny 2 and 
SSH and simply remove the problem.  IOW, it's time to punt.  ;)

I propose rewriting 5750 Sec 3 and deprecate the use of email addresses in 
S/MIME certificates *entirely*.  We'd add to Sec 3 instructions for MUAs to:

- Treat an email signature as a valid signature if the MUA has associated that 
signature's public key [1] with the From: or Sender: address.   Call this the 
"valid if expected" rule.

- Require the MUA to associate a public key with an email address the first 
time it receives a signed email, ideally with an explicit user acknowledgement. 
  The "record on first use" rule.

- Require MUAs to notify users of a security problem when an email from any 
address arrives with a signature by any other public key than the one expected. 
  The "notify on broken expectations" rule.

I'd also propose adding an optional procedure for key-rollover notification, by 
which the MUA will replace an existing association between and address and a 
public key, for example by defining a key-rollover message that's signed by 
both the old and key keys.  (This would be optional because it places 
requirements on sender PKIs that can't be met in all cases; e.g., my DoD PKI 
signing key is on a smartcard, and I lose access to old signing keys when a new 
signing key is issued.) 

A security note in Sec 5 would be needed to cover risks of and recommendations 
defend to against key introduction and key rollover attacks.  E.g., displaying 
the email address, cert Subject CN or DN, Issuer Subject CN, and possibly some 
interesting extensions (e.g., directory attributes, maybe private extensions, 
and the like) might provide context for the user decision.

This concept has the benefit of being conceptually simple, demonstrably secure, 
relatively intuitive (read Johnny 2, and plenty of user experience with key 
continuity management in SSH), backward-compatible, and future-proof.  In re: 
backward compatibility:  Sec 3 para 2 already requires MUAs to manage this case 
(supporting certs without an email address is a MUST)--this change simply makes 
it the primary rather than alternate case--so MUAs that conform to the new spec 
would be able to exchange S/MIME email with MUAs conformant to the old spec.   
In re: future proofing, changes in certificate formats, extensions, email 
messaging specs, &etc. would have no impact.  It also makes the currently 
implicit S/MIME signaling path as explicit, removing ambiguity, which is a good 
thing.  Lastly, it lets the MUA provide meaningful automation--managing address 
books is something MUAs already do really really well.

This proposal still leaves the door open for common directories; e.g., the 
"Valid if expected" rule holds if the MUA consults a CA directory using the 
From: address, and the directory returns the public key that signed the email.

Email address matching can remain as an alternative, probably as a MAY clause, 
with associated warnings about making life harder for yourself.

-- T
[1] I'm intentionally using "public key" here because I think generalizing 
S/MIME to include PGP keying is a good idea, so we should get into the habit.  
ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>