No, that is not what I am proposing.
The discussion here is about a REQUIREMENT. How the requirement is achieved is
not the issue at this point.
Of course since everyone seems to skip straight to the implementation, think up
a daft way to do it and then object to the complexity of the scheme I am not
proposing we have spent six months discussing what is the most trivial, easy to
implement scheme you can imagine that actually works.
The policy record does not directly reference the signing algorithm, all that
information remains in the key record. All that you get in the policy record is
a statement 'there is always a key record that has a selector that looks like
this' or 'there is always one like this and one like that'.
Lets hold off on the implementation though as Steve will no doubt remind us is
the basic idea at this point. This means that we only discuss whether it is a
valid requirement. The cost of implementation is not the issue at this point.
________________________________
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Tuesday, February 27, 2007 6:19 PM
To: John Levine
Cc: ietf-dkim(_at_)mipassoc(_dot_)org;
paul(_dot_)hoffman(_at_)domain-assurance(_dot_)org
Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade
andDowngrade Attacks
If you mean to just require that and not actually list the algorithms,
the verifier would have no way of determining what algorithms the signer uses,
without a list of all its selector names.
If you mean to list the algorithms, isn't that what Phill is proposing?
-Jim
John Levine wrote:
Every protocol with algorithm agility but not a fixed
list of "MUST
implement" algorithms has this issue.
Is there any reason that SSP couldn't require that anyone who
makes a
statement that he signs messages must sign with all the
signature algs
he supports?
This would be an SSP MUST, not a DKIM MUST.
R's,
John
_______________________________________________
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