[Top] [All Lists]

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

2016-03-22 13:30:11
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-

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.

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

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