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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp