I'm inclined to agree with the consensus. There may be situations
where you verify a signature and then pass the message through an
untrusted environment, in which case you might want to re-sign and
re-verify the message, but I suspect they will be rare. Consider
that this would effectively double the crypto overhead on verifiers,
and it really looks like making this a SHOULD is an expensive
solution to what will be for most people a non-problem. I would say
that it should be at most a MAY.
eric
--On December 3, 2007 10:00:45 AM -0800 "Murray S. Kucherawy"
<msk(_at_)sendmail(_dot_)com> wrote:
This came up both at the last IETF and at this one, so I thought it
worth opening up here once before I submit the draft to the area
director.
Should the normative text in the draft specify that this header
SHOULD be signed?
The point comes from someone who operates in an environment in
which he doesn't necessarily want to trust that the border MTAs are
properly removing forged A-R headers. This would mean there needs
to be a shared or distributed secret between the border MTAs where
the header is added and the clients where the header will be used.
It also means I'd either have to reference a header
signing/verifying mechanism or define one.
Some of the risk of this is mitigated by the AUTHRES ESMTP
extension draft, but the time to implement there is going to be
longer than the support for this header.
The hallway track at the last IETF and since was that the current
draft's Section 8.1 (especially the last paragraph) provide
sufficient discussion of this issue. I might change "posted" to
"posted or shared".
What are the list's opinions?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html