[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John R Levine
Wearing, as usual, my receiver hat, I still don't see any
reason to be interested in random senders' opinions about the
relative merits of various algorithms.
Like I said before, let's say someone publishes SSP saying
sha256 is deprecated and rot13 is shiny and new. What should
I do with that info?
Assuming we agree that it's stupid and I should ignore it,
how am I supposed to tell stupid deprecation advice from
non-stupid deprecation advice?
I don't know who you think is saying that but it isn't me.
The sequence of events hypothesized is:
1) Sender determines that the existing algorithm is deprecated
2) In response to (1) sender prepares to support an additional signature
algorithm
3) In order to support (2) sender publishes an additional key record for the
new algorithm
4) Mallet starts sending bogus messages with forged signatures purporting to be
under the new key
5) Receivers that have not yet upgraded to support the new algorithm are unable
to determine that the messages with forged signatures are inconsistent with the
signer's policy.
The receiver is not required to accept the belief that the existing algorithm
is deprecated.
Again, the point is that if we are going to have a policy mechanism at all then
the policy mechanism must be designed in a way that prevents an attacker
circumventing it.
'I sign all messages' allows the receiver to draw useful conclusions if and
only if the receiver is capable of processing every single key record specified
by the signer.
'I sign all messages with a key record in group X' allows the receiver to draw
useful conclusions if and only if the receiver is capable of processing every
single key record specified by the signer *in group X*.
The first fails in the five year period one might expect to elapse while a new
algorithm is being deployed and an old one is phased out. The second does not.
The disagreement raised here really have nothing to do with the 1368 issue. The
objections being raised to changing SSP can all be made against SSP and the
concept of policy. If you don't get the 1368 objection its because you either
have a different idea of what policy for or you don't believe that there is a
point to policy.
It is axiomatic here that specifying a policy language will modify the
processing of messages as described in base and that policy will include
concepts that are out of scope for base. Otherwise we would be done.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html