Thanks for the detailed explanation. From this perspective a reasonable
refinement of RFC5751 would be to drop the verification of the FROM or
SENDER address? Messages would still be signed by a CA issued cert/private-
key.
This is already present in 5750. See Sec 3--MUAs MUST be able to handle certs
without an email address, and there's a SHOULD for optional processing when
there's a mismatch. I proposed in one of these thread forks that we could
update 5750 by making the "match" requirement a MAY/OPTIONAL and maybe
explicitly deprecate its use (though deprecation might wait for a further
future update), and promote the alternate processing to a MUST.
That's the smallest possible change and preserves compatibility (any MUA that
*can't* handle a cert w/o RFC822 address or provide alternate processing for a
mismatch is already non-conformant).
I'd also think it wise to expand on client behavior a bit in re: making
associations between keys and addresses, but I wouldn't want implementers to
take recommendations as gospel, so they probably belong in an Appendix or in
Security Considerations.
To make workable for people, the cert still ought to specify either an
email address, name or some other human comprehensible identity (e.g.
photo?) so that the recipient knows the cert belongs to the sender.
This is all stuff that at best belongs in an appendix, at best. Personally I
wouldn't want to go beyond the known security risks of handling first use or
when a key is changed. I'd like to see what implementers can come up with on
their own and am reluctant to constrain future solutions.
The
refinement would also need to address the issue of protecting the integrity
of the headers which the current comparison sort of does.
The matching requirement does nothing of the sort, but I take your meaning.
I've never been completely clear on why S/MIME signatures don't cover headers.
There may be a damn good reason.
-- T
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp