My point was that your altered syntax has widened the possibility of
attacks based on human factors.
I don't see how that is true.
I see I'm going to have to spell it out in mind-numbing detail.
Consider a site that does thorough verification of email addresses, such
that all BATV addresses are known to be valid and only appear on messages
sent by the address's owner. Say that whether BATV is used is configurable
per user. (This is similar to the deployment I am working on.) The victim
has BATV turned on and the attacker has it turned off, so the attacker can
use untagged return paths. The recipient knows a bit about BATV and
assumes that a message with a return-path address that is tagged is
actually from the aparrent sender.
So if the recipient gets a message starting
Return-Path: <batv=VALIDBATVTAG/victim(_at_)domain>
they correctly infer that the message was sent by victim.
However if they get a message starting
Return-Path: <attacker+ACTUALLYALOCALPARTSUFFIX/victim(_at_)domain>
and carelessly fail to eyeball the start of the address, they might
not notice that the message was from attacker not victim.
This is a minor human factors problem, but it's still a security
consideration.
The rationale is to allow multiple signatures to co-exist and allow
signatures of possibly multiple data parts, etc.
That's obvious from your original message. What I mean by a rationale
is an explanation for why is this desirable.
Disirable: scalable extendable syntax (?)
Or can you rephrase it so I understand what you're asking?
In what situations would you put more than one signature in an address?
What problems does this solve that aren't solved by a single signature?
How is it scalable when there's only 64 characters available? What
extensibility advantages does it provide that aren't provided by BATV's
tagging scheme naming system?
You mentioned signatures of body parts. I think a better solution would be
to include the complicated details of the message data signature in the
message data itself, and to improve BATV's resistance to spoofing with a
tagging scheme that includes only a digest of the message data signature.
This ties the return path to a specific message while keeping it simple
and concise and relatively isolated from the complexity or choice of
message data signature specification.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING
MODERATE.