It seems to me that the exchange between John and Charles
below captures the crux of the issue.
Option 1: If we agree with Charles (& Phill I guess) that
looking up SSP and then passing on the only-signed-with-B
message will be common practice then there seems to be a
sufficient reason to include the "I sign all with A"
statement or equivalent in SSP.
Option 2: If OTOH, we agree with John, that further processing
(after sig check & SSP lookup) SHOULD or MUST treat the
only-signed-with-B message as unsigned, with no code branching
on the presence of the putative B-sig, then the additional SSP
expressiveness is useless.
I don't see a rough consensus either way, though I would
guess I've seen a little more support for option 1 in the
last few days than for option 2.
Just to help me out, could you say which option you prefer?
Thanks,
Stephen.
PS: If you prefer some other option or would like to quibble
with my text above, feel free, but maybe change the subject.
Charles Lindsey wrote:
On Sun, 25 Feb 2007 22:09:06 -0000, John Levine <johnl(_at_)iecc(_dot_)com>
wrote:
Or I have a message that didn't have any good signatures. I can't
tell whether that was because it was unsigned, it had a good signature
that broke in transit, it had a good signature that I didn't know how
to verify, or it had a bogus signature applied by a bad guy. So, as a
receiver, this is all the same situation, it's unsigned. If you
believe that SSP can state "I sign everything", you might throw it
away if that's what the SSP says. Otherwise, what?
Eh? If it was unsigned, you know that.
If it was signed with an algorithm you couldn't verify, you know that,
If the signature was broken, you know that (but not why it was broken).
All those situations are to be classified as 'unsigned' (but more
detailed information is available to you if you want to use it).
So, being "unsigned", you consult the SSP, which maybe tells you "we
sign everything". You might then reject it regardless on that basis and
thus lose some genuine message simply because you couldn't verify the
algorithm in use; more likley, you would want to allow such cases
through (whilst also persuading your local geeks to implement the new
algorithm ASAP). But, in the example quoted (message signed only by
unverifiable algorithm B) you would then accept the bogus message. But
an SSP response of "we sign everything with both A and B" would allow
you to accept genuine messages from that site (because you can veriffy
algorithm A) but reject the bogus one.
How does a SSP list of signing algorithms provide any useful
information to a receiver? Unless I'm missing something rather
fundamental, it doesn't.
--Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html